History log of /system/bt/btcore/src/module.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
3a44a7a4f6b2dec169097152739d7fdd38482b72 26-Apr-2016 Pavlin Radoslavov <pavlin@google.com> Fix issues during cleanup stage of the Bluetooth stack

* Moved free-ing of bta_av_cb timers from the init function
to the cleanup stage.
* Changed the usage of btif_jni_disassociate() so it is called
synchronously. Its previous usage was complicated -
the function was called asynchronously on a different thread,
and we had to wait on a future for its completion.
* Renamed function btif_shutdown_bluetooth() to
btif_cleanup_bluetooth() to represent better its purpose.
Similarly, bte_main_shutdown() is renamed to bte_main_cleanup()

Also:
* Removed function btif_init_fail(), because it is not used.
* Updated an error log message inside function
btif_in_execute_service_request() so the log information
is accurate and more useful.
* Updated the log messages related to the lifecycle of a module
in btcore/src/module.c

Bug: 26982349
Change-Id: Icd6f159d993bdb9c8ef09bfb5b1386b3d6ea4ff2
/system/bt/btcore/src/module.c
69b9e7c735c94ed9c4f3cad47be8f679bcad2e6b 19-Apr-2016 Manu Viswanadhan <manuv@codeaurora.org> Fix FD leak caused by module wrapper thread

Use Case: Repeated BT ON/OFF

Failure: FD leak is observed with ON/OFF stress test
which eventually leads to crash due to unavailability
of FDs.

Steps:
BT ON/OFF.

Root Cause: During cleanup the module wrapper thread is
stopped but the resources are not freed, leading to FD leak.

Fix: Cleanup the module wrapper thread properly so that there
are no resource leaks.

Bug: 28312228
Change-Id: I4de2fba9c98a0e4ae73315759ec6bc8bf273948e
/system/bt/btcore/src/module.c
b5754d2fdfce8acba35ac8a03aae2ab88152dc6b 01-Mar-2016 Srinu Jella <sjella@codeaurora.org> Enable debug logs for bluetooth process threads, modules

Use case: Debug enhancement for bluetooth threads,
modules

- Most of the bluetooth process threads,modules uses
APIs provided from the OSI layer.

- This patch enables the debug logs to know when the
thread, module is created and exited.

- This would be useful while debugging the ON/OFF,
ANR issues.

Bug: 27852645
Change-Id: I17f4f583d2c431725a8c44c586b29980b4bdab3f
/system/bt/btcore/src/module.c
db554581079863974af8e1289646f5deea6fc044 26-Jun-2015 Marie Janssen <jamuraa@google.com> build: Update osi log functions, use consistently

Update the LOG_* functions to take a tag argument which makes them more
consistent with the Android Log.*(TAG, s) common syntax and removes
some #define-dependency with osi/include/log.h.

Also update to never use Android log functions directly.

Also contains minor cleanup of some header includes.

Bug: 21569831
Change-Id: If07385cafbea062232ecdbc7c673f908d5ef8921
/system/bt/btcore/src/module.c
03583e8f3161836f2bef56f59a6f7bb2db25e61f 19-May-2015 Zach Johnson <zachoverflow@google.com> Build the shared library with --whole-archive

For stack static libraries, use LOCAL_WHOLE_STATIC_LIBRARIES
to ensure they get --whole-archive applied to them.

This means module symbols in static libraries won't be
removed by the linker and dlsym will find them.

This patch also removes the code hacks we needed to
trick the linker into including the module symbols in
the final shared library.

Change-Id: I2463d0e6fb38f1e75c8293179cf9d4ca33eda84e
/system/bt/btcore/src/module.c
40412562707ee3f1fa104c4332bc6247880040a3 19-May-2015 Andre Eisenbach <eisenbach@google.com> Include osi_module reference in module_init funcion

This prevents a crash-loop if the module is stripped by the linker.

Change-Id: I7a3f0349cb62a9e73e003707c1f48ec0a6de7f67
/system/bt/btcore/src/module.c
d1e2206a9e0798e01dc18d7c7309d19f74fca9a9 02-Apr-2015 Etan Cohen <etancohen@google.com> Fix dlsym change/failure by hard-coding internal module references.

Should be reverted once permanent solution for dlsym change merged.

Change-Id: I2c0843875f88c8c56899b60246907af12d29fb0c
/system/bt/btcore/src/module.c
f8027005333c88a2f097cfd70d15c3d54c7764ae 12-Mar-2015 Chris Manton <cmanton@google.com> Demote, cleanup and extend observed logging
/system/bt/btcore/src/module.c
95b74f252f534ec757aab1fc08e086e02b2cfe8d 12-Mar-2015 Sharvil Nanavati <sharvil@google.com> Use fully qualified path for btcore includes.
/system/bt/btcore/src/module.c
0f9b91e150e153229235c163861198e23600e636 12-Mar-2015 Sharvil Nanavati <sharvil@google.com> Use fully qualified path for OSI includes.
/system/bt/btcore/src/module.c
05d0366413bedc16b4189b9e74395fe4b11ba41a 05-Nov-2014 Zach Johnson <zachoverflow@google.com> Add a hash function for bluetooth addresses

Also includes simple tests for it + disambiguates
including hash_function.h throughout the stack.
/system/bt/btcore/src/module.c
aa3a0114b6f018d0dd296d5bdb113d2f881cbc51 05-Nov-2014 Zach Johnson <zachoverflow@google.com> Add key equality function option for hash_map

This will allow us to do deeper equality on things like
bluetooth addresses where the actual pointers are different
but the values of the bluetooth addresses are the same.
/system/bt/btcore/src/module.c
44802768c447ab480d4227b3a852a97d923b816d 24-Dec-2014 Sharvil Nanavati <sharvil@google.com> Add platform-independent logging macros to OSI.

These macros should replace ALOG* and the various trace macros
used throughout bluedroid. This change eliminates all uses of the
ALOG* macros in favor of the new ones.
/system/bt/btcore/src/module.c
3c511e667e593c8ea594ca24b1d7712214245863 29-Sep-2014 Zach Johnson <zachoverflow@google.com> Add temporary callbacked wrapper for module startup

When all is said and done with the module conversions, all lifecycle functions
will run on the lifecycle managment thread, which can be blocked while waiting
for futures.

This CL means new modules can depend on that fact during start_up, alllowing
newly converted modules to be spliced into the existing startup callback madness
without having to sacrifice clean implementation.

We can add other callbacked lifecycle function variants as necessary.
/system/bt/btcore/src/module.c
72f308ee6d3983ae2c0d67be3de2451f2dd72dcb 23-Sep-2014 Zach Johnson <zachoverflow@google.com> First pass at implementing modules

This first step creates the notion of a module and corresponding
lifecycle functions, with helpers to simplify working with them.

Once everything is converted over to this module format, then we
can make the stack manager automagically find the correct order for
init/start_up/shut_down/clean_up
/system/bt/btcore/src/module.c