am skip reason: Change-Id If6c9e291f2471b96a752dc6e76e3e63458b71391 with SHA-1 bbb16022c7 is in history
Change-Id: Iad2c0a8ae42bf1b7864ad5b57b8a53937952ce4f
* changes:
Revert "init: handle property service callbacks asynchronously"
Revert "Stop & Resume property service when switching to bootstrap namespace"
This is apparently causing problems with reboot.
This reverts commit 7205c62933.
Bug: 150863651
Test: build
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
The current implementation of the hashtable uses less memory than
a std::map. As most of the zip files we encountered don't use the zip64
extension, we should keep the current implementation. And the interface
adds the flexibility for us to switch to std::map for zip64 format.
Bug: 150900468
Test: unit tests pass
Change-Id: Ifd008785c9ff416a27049f9e0c54d9eef985bd85
In case multiple threads try to reference this variable while it is
being set, it should be atomic so that all threads always see a valid
value.
Bug: 150898477
Test: liblog, libbase unit tests
Merged-In: If6c9e291f2471b96a752dc6e76e3e63458b71391
Change-Id: If6c9e291f2471b96a752dc6e76e3e63458b71391
(cherry picked from commit bbb16022c7)
Replace the original on demand start mechanism with the new dynamic
AIDL service infrastructure to resolve a possible race condition.
Bug: 149130673
Test: gsi_tool status
Merged-In: Ia5f32579a8dcf62d700d974c7f4e3c65647f3b8b
Change-Id: Ia5f32579a8dcf62d700d974c7f4e3c65647f3b8b
Previously, we were waiting for the other end to respond after every
file sent, which results in massive slowdown when there's any amount of
latency on the transport.
This improves performance on a cuttlefish instance with ~7ms RTT from:
system/: 2037 files pushed, 0 skipped. 2.8 MB/s (762803979 bytes in 262.964s)
to:
system/: 2037 files pushed, 0 skipped. 11.9 MB/s (762803979 bytes in 61.278s)
Bug: https://issuetracker.google.com/150827486
Test: ./test_device.py
Change-Id: I3a0c893faa5d455cc6ccbc86915a17e1b5abbfbe
(cherry picked from commit 64ff82ba68)
libbase is a popular library that is used by many APEXes either directly
or transitively. It is being used by several Mainline modules that were
launched with Q, in which case everything in the APEX - including
libbase - shouldn't use new APIs that are added post Q, i.e. R.
libbase however is using a few new R symbols from liblog, and this is
preventing those Q-launching Mainline modules that are built in R source
tree from being installed to Q devices.
Fortunately, the dependencies to the new R symbols are guarded with a
flag; when the existence of the symbols are not guaranteed, it uses
dlsym. This change fixes the aforementioned problem by turning on the
flag also when libbase is built for an APEX.
Bug: 149569129
Test: TARGET_BUILD_APPS=com.android.media
vendor/google/build/build_mainline_modules.sh
adb install --staged out/dist/mainline_modules_arm64/com.android.media.apex
adb reboot
The APEX is installed and mediaextractor process doesn't crash
Change-Id: I44b5ec028850613cb45fc3e792f43cd8e87cfd00
When libbacktrace.a is statically lined to somewhere, that library had
to add libasync_safe.a to static_libs because libbacktrace.a has
references to libasync_safe.a. But libbacktace depending on
libasync_safe is an implementation detail of libbacktrace, and therefore
its client shouldn't be affected by it.
Fixing this by doing the whole static link to libasync_safe to
libbacktrace.a so that the former is included in libbacktrace.a
Bug: 149569129
Test: m
Change-Id: If7366a240bc945dda9944fe7c111e10d328165bb
am skip reason: Change-Id I0c78818962e1db91b556e523c418db28f7d78fae with SHA-1 44ae546061 is in history
Change-Id: I59f64c1d252937fc6978809203f486aed60e3e52
