Before this change, "Success" is returned after all data is streamed,
around 7.5 seconds for Megacity.
After this change, "Success" is returned in about 1.5 seconds, before
streaming finishes.
BUG: 151676293
Test: manual
Change-Id: Ifda7de48da8e82623c99ae0194f70cb162fd72fa
Currently the server often quits before installation finishes. As a
result, there is no difference in the commandline output between a
successful installation and a failed one.
Let adb client wait till installation fails or succeeds by parsing the
output from the inc-server process.
Test: $ adb install --incremental ~/Downloads/base.apk
Test: Performing Incremental Install
Test: Serving...
Test: All files should be loaded. Notifying the device.
Test: Failure [INSTALL_PARSE_FAILED_NOT_APK: Failed to parse /data/app/vmdl749343150.tmp/base.apk: Failed to load asset path /data/app/vmdl749343150.tmp/base.apk]
Test: Install command complete (ms: 91 total, 0 apk prep, 91 install)
BUG: b/150865433
Change-Id: Ie33505f9cc08fc6d60ad4a5d709526e7aa9a0ad1
Kill processes and make sure the phone recovers. This adds a basic level
of testing, but it could be improved by:
- trying to kill all running processes on the device
- improving metrics for 'recovery'
Bug: 148236233
Test: init_kill_services_test
Change-Id: I8aaca7bf4bb0be588decf741d1f6e1c5787cea84
libbase doesn't have to rely on dlopen/dlsym to use liblog's new symbols
when it is built for __ANDROID_SDK_VERSION__ > 29.
Bug: 150860940
Test: TARGET_BUILD_APPS="com.android.adbd com.android.resolv" m
objdump -T ...shared_com.android.resolv/libbase.so | grep LIBLOG_R
=> should be none because resolv apex is targeting 29
objdump -T ...shared_com.android.adbd/libbase.so | grep LIBLOG_R
=> should list all new symbols because adbd apex is targeting R
objdump -T ...shared/libbase.so | grep LIBLOG_R
=> should list all new symbols
Change-Id: I7f7f16510d7637cd380fe35ea9ff3e804f38851d
am skip reason: Change-Id I1f928f519ae2c75aeedb74b70d513743e86bcf2b with SHA-1 4bb500fa9a is in history
Change-Id: I865a88b0590d57d72bc82bb8b381376c07993bce
Add the std::map implementation to be used later in zip64 format.
Also move the entry map classes to a separate file to make the hierarchy
clear.
Test: unittests pass
Change-Id: I74d95f53207cc8ca871b955e2a15c184d5497833
1) Rename __android_logger_data to __android_log_message and rename
__android_log_write_logger_data to
__android_log_write_log_message. Move the const char* message
argument into __android_log_message.
2) Add @param, @return, and "Available since API level 30." to the
documentation of new functions.
3) Document that the user defined aborter should but may not abort.
4) Document the line separation is the responsibility of the log
function provided to __android_log_set_logger().
Bug: 150898477
Test: build, liblog and libbase unit tests
Change-Id: I07c41011ef25b3e7cc4943f3f1e240a2f6aa2802
Since new files can be introduced to /metadata after the initial
restorecon, we need to skip hashing.
Bug: 150907679
Test: rollback, ls -lZ /metadata/ota
Change-Id: I1f928f519ae2c75aeedb74b70d513743e86bcf2b
Merged-In: I1f928f519ae2c75aeedb74b70d513743e86bcf2b
am skip reason: Change-Id Ice773436e85d3bf636bb0a892f3f6002bdf996b6 with SHA-1 802864c782 is in history
Change-Id: I5d9baa362fe10e66c7043f47aff86ce6d63e83a0
We were ending up with multiple copies of the proto runtime in the
recovery image, when we need zero.
Before:
784K recovery/root/system/lib64/libadbd_services.so
832K recovery/root/system/lib64/libadbd.so
After:
360K recovery/root/system/lib64/libadbd_services.so
344K recovery/root/system/lib64/libadbd.so
Bug: http://b/150317254
Test: treehugger
Change-Id: I39fbb3959128994f0de2ae0ea47dbc0800c516fe
We want to ignore SIGPIPE within init, but if we use SIG_IGN, that
would be inherited by child processes through exec(), which we do not
want to have happen. We instead set up a real signal handler with a
no-op handler function, that will ignore SIGPIPE within init, but will
not be inherited across exec().
This fixes c29c2baa69 ("init: Add support for native service
registration with lmkd"), when SIG_IGN was introduced.
Note that we caught this issue before shipping a release with that
change, so the major motivation here is to not cause a behavior change
in init.
Bug: 151581751
Test: children of init that don't explicitly block SIGPIPE exit when
sent SIGPIPE
Test: children of init that do explicitly block SIGPIPE do not exit
when sent SIGPIPE
Test: init does not exit when sent SIGPIPE
Test: init exits when sent SIGABRT
Change-Id: Ieda8555fd03836bcd672a422fe673a8369ad9beb
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.
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
A previous version of this change was reverted and added locks around
all service operations and allowed the property thread to spawn
services directly. This was complex due to the fact that this code
was not designed to be multi-threaded. It was reverted due to
apparent issues during reboot. This change keeps a queue of processes
pending control messages, which it will then handle in the future. It
is less flexible but safer.
Bug: 146877356
Bug: 148236233
Bug: 150863651
Bug: 151251827
Test: multiple reboot tests, safely restarting hwservicemanager
Merged-In: Ice773436e85d3bf636bb0a892f3f6002bdf996b6
Change-Id: Ice773436e85d3bf636bb0a892f3f6002bdf996b6
(cherry picked from commit 802864c782)
This is apparently causing problems with reboot.
This reverts commit d2dab830d3.
Bug: 150863651
Test: build
Merged-In: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
create new profiles to allowing thawing and freezing back the freezer
cgroup
Bug: 151225245
Test: Manually verified that using the SetTaskProfiles method on the
profiles thaws and freezes back the freezer cgroup.
Change-Id: I7f3e193ebe79b49c1f6ac52b6138ff4ec26fc570
am skip reason: Change-Id Ia5f32579a8dcf62d700d974c7f4e3c65647f3b8b with SHA-1 f6abdf6e0d is in history
Change-Id: Id8977e85ca282f029babf366881a283d64329967
