| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Change-Id: Iecf1e2258da012bdac69a4f57d38b12a272e3edd
|
| |
|
|
|
|
|
| |
Includes support for BTSnoop logging in memory.
Bug: 18508263
Change-Id: I175da528cbcdc00d40622647d518a74210cfe6fd
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These patches will allow us to compile the whole AOSP with clang/llvm
before all the following problems are fixed.
* Suppress warnings on unused variables.
* Remove unused static variables.
* Use only gcc to compile code that requires gcc atomic functions.
They should be converted to standard atomic functions later.
* Suppress warnings on redefined typedefs.
BUG: 20765701
Change-Id: I19bc0a256c19502fabcabd1ca158637a8b5741a2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implementation introduces the notion of a 'slice'. A slice is
simply a sub-buffer of the original buffer. Slices refer to their
parent buffer so no memory is copied and slice creation becomes an
O(1) operation. Although I'm introducing a new concept, in practice,
a slice is indistinguishable from a buffer (they share a type and
all operations).
I expect slices to be used heavily during packet construction. For
example, an RFCOMM implementation would request a buffer from the
L2CAP layer (which may in turn request a buffer from the HCI layer).
The L2CAP layer would reserve some space in the buffer for its header
and return a slice to the RFCOMM layer.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Arrays are useful for storing a collection of small objects where
linked list node allocations would be a lot of overhead. They are
also useful for random access through the container. Lastly, this
implementation assumes copy semantics which are intentionally
different from list's reference semantics (since objects are assumed
to be smaller).
The current interface is intentionally sparse.
|
| |
|
|
|
|
| |
Allocation test harness included relatively local
header allocation_tracker.h. Change to include
absolute header location from bluedroid root.
|
| |
|
|
|
|
| |
Freeing now happens implicitly upon await, and immediate
futures will allow a uniform usage pattern for calls
that are async and calls that are not.
|
| |
|
|
|
| |
This will be useful when signaling success/fail during individual
asynchronous steps of stack start up and shut down.
|
| |
|
|
|
|
|
| |
Refactor the hci layer to use it.
The timer wrapper allows you to specify the duration, etc at construction time
rather than at start time, making some usage patterns of alarm more convenient.
|
| |
|
|
|
| |
Provides an interface to track memory allocations, and assert
bad things like double frees don't happen.
|
| | |
|
| |
|
|
| |
Somewhere along the way it got lost
|
| | |
|
| |
|
|
| |
This improves the test writing experience for tests that rely on alarm code.
|
| | |
|
| |
|
|
| |
This will be useful at layer boundaries.
|
| | |
|
| |
|
|
|
|
|
| |
This socket implementation is limited to TCP server sockets and
provides no mechanism to connect to a remote host. It's primarily
intended to be used to interface with debugging tools. It's designed
to work seamlessly with the reactor (event-driven) model.
|
| | |
|
| |
|
|
| |
Change-Id: I5fa21b48506e4d1d65da4b8bedbbf39e03dad559
|
| |
|
|
|
|
|
| |
So far it's a thin shim around pthreads which allows setting thread
name and querying tids from any thread.
Change-Id: Id156f662778806a54a8a302be424ee051fac4710
|
| |
|
|
|
|
|
|
| |
This code will form the basis of most select-based event loops in
bluedroid. It provides a thread-safe abort routine and a separation
between the dispatcher and event handler code.
Change-Id: I6f1c033d18f045ba273187dab607c209dfe32d30
|
| |
|
|
|
|
|
|
|
| |
There are currently multiple INI parsers in bluedroid and they're
special-purpose for the task at hand even though they parse the
same format. This implementation is general-purpose, loosely coupled
with the rest of bluedroid, and has unit tests to verify behaviour.
Change-Id: I61caf416cc16d76b871cbf04f333c26894ab3fef
|
| |
|
|
| |
Change-Id: Ifad7605d0b6e1a57f4767f9de1bed7e99284ded7
|
|
|
Change-Id: Ifffd6f9eabee482a81b326c9cf8d06163aede0f4
|