adb remount and snapshot-based updates use ImageManager in first-stage
init. This creates status files, which need to be labelled.
Bug: 148834619
Test: manual test
Change-Id: I72949fca2889f9e5612049844a78bf9355b48797
Simplify and fix the algorithm.
For consecutive functions (eg [10,20] [20,30]) without
padding in between, the old algorithm would drop FDEs.
Test: libunwindstack_test
Change-Id: Ie886922bec262fb64d4b2ecf01c2961d0652dcdb
This broke because two CLs touching the Android.bp file both
independently passed presubmit, but failed when combined.
Clean up a misindentation while we're at it.
Bug: http://b/150032367
Test: mma in system/core/adb
Change-Id: I091ef9dec806c767ffb21a5fd73b2bb37ab29ff9
Add a BM_log_verbose_overhead test that measure the overhead of
writing a log message that will not be printed due to verbosity
levels. This was optimized in R to not format the log messages before
checking if they will be logged.
Results with R:
BM_log_verbose_overhead_null_mean 159 ns 159 ns 100
BM_log_verbose_overhead_null_median 159 ns 159 ns 100
BM_log_verbose_overhead_null_stddev 0.568 ns 0.464 ns 100
Results with Q:
M_log_verbose_overhead_null_mean 601 ns 600 ns 100
BM_log_verbose_overhead_null_median 601 ns 600 ns 100
BM_log_verbose_overhead_null_stddev 2.40 ns 2.23 ns 100
This benchmark shows liblog's overhead when not printing a log message
to be nearly ~4x faster than with Q.
Test: run this benchmark
Change-Id: I09a60e61bf064330bf15a9d0a946acf16e777a6d
These buffers are immediately written into with *printf() and are in
the hot path, so do not initialize them. This saves ~70ns off of each
log message, which is ~14% of the overhead within
__android_log_print() when writing to a no-op logger.
Test: liblog benchmarks
Change-Id: I2b898e72c75b57bc63fee565b49a4e00e377ed1a
Bug: 111434128
Test: This is the test
Change-Id: I97e4d4ed6318de34a62b60144e790142d00e1629
Exempt-From-Owner-Approval: missed adding it in previous CL.
Without this, the caller is likely to assume that their buffer is
fully usable, which clang's analyzer doesn't believe is the case.
Another option is to set `*size` to nonzero.
Caught by the static analyzer:
system/core/adb/client/incremental_server.cpp:111:31: warning: 1st
function call argument is an uninitialized value
[clang-analyzer-core.CallAndMessage]
Bug: None
Test: TreeHugger
Change-Id: Ib844aa4ab3ebb297ca8f6f4289bbe3212275275b
This command will be sent by adbd to notify the client that the
connection will be over TLS.
When client connects, it will send the CNXN packet, as usual. If the
server connection has TLS enabled, it will send the A_STLS packet
(regardless of whether auth is required). At this point, the client's
only valid response is to send a A_STLS packet. Once both sides have
exchanged the A_STLS packet, both will start the TLS handshake.
If auth is required, then the client will receive a CertificateRequest
with a list of known public keys (SHA256 hash) that it can use in its
certificate. Otherwise, the list will be empty and the client can assume
that either any key will work, or none will work.
If the handshake was successful, the server will send the CNXN packet
and the usual adb protocol is resumed over TLS. If the handshake failed,
both sides will disconnect, as there's no point to retry because the
server's known keys have already been communicated.
Bug: 111434128
Test: WIP; will add to adb_test.py/adb_device.py.
Enable wireless debugging in the Settings, then 'adb connect
<ip>:<port>'. Connection should succeed if key is in keystore. Used
wireshark to check for packet encryption.
Change-Id: I3d60647491c6c6b92297e4f628707a6457fa9420
Bug: 111434128, 119493510, 119494503
Test: Enable wireless debugging in Settings UI, click "pair with pairing code"
to generate pairing code.
On client, 'adb pair <ip_address>', enter pairing code at prompt and hit
enter. Pairing should complete.
'adb logcat'.
Change-Id: I86527bd3fc52e30a8e08ec5843dc3e100abf91fa
Exempt-From-Owner-Approval: approved already
If a USB device descriptor has zero length it is invalid and iteration
should stop otherwise the code iterating will go into an infinite loop.
Bug: 149986186
Test: attach bad USB device with invalid descriptor length 0 then attach
a good USB device and ensure it is recognized properly
Change-Id: I7571a6357bdc13af221cf8be01eba16f5bc976a3
This is in preparation of doing what we did for SharedRefBase (hiding
operator new) so that clients can't accidentally construct
shared_ptr/unique_ptr or any other alternative memory management scheme
which would conflict with RefBase. You can see what ultimately happened
to SharedRefBase in frameworks/native CL
10d9ddf2e3da3ba3a425fb8396aaaec728e5fbdb.
The goal for this:
- promote use of 'sp<T>::make' over 'sp<T> .. = new T'
- make 'operator new' a private member of RefBase
Bug: 138956784
Test: libutils_test
Change-Id: I47f4d28edbf7534730c7b6fb1de748dd60f34e11
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
