- late start of zygote_secondary leads into occasional
1 second wait for starting system service.
- Early start secondary zygote so that there is no additional
wait.
bug: 37508384
Test: python packages/services/Car/tools/bootanalyze/bootanalyze.py -r -c packages/services/Car/tools/bootanalyze/config.yaml -n 100 -f -e 16 -w 30
Change-Id: I2e4eb0b59a9a8417b56a72fe2de6fa2a6e1ab0a2
The new changes to slotselect() call makes it try to find the
"slot" config before trying "slot_suffix" and that causes fs_mgr to
print the needless error and spam the kernel logs for no reason.
Remove the print.
Test: Builds for sailfish
Change-Id: I020575d70f4cd6e137e82c127b5d5234d709d0e3
Signed-off-by: Sandeep Patil <sspatil@google.com>
The gTest should not be able to set ro.device_owner, either as a unit
test or a CTS test. The CTS test should not be able to set
persist.logd.security, the gTest may as it is run on userdebug with
root, so check if we are root to discern expectations.
Test: gTest liblog-unit-tests --gtest_filter=liblog.__security
Test: cts-tradefed run cts-dev -a armeabi-v7a -m CtsLiblogTestCases -t liblog#__security
Bug: 36480230
Change-Id: I1da88aae34da4e2fca8dd88d740eeb879d9c65bb
libutils headers are only used by the implementation of libbase,
and should not be exported to everything that uses libbase headers.
Test: m -j
Change-Id: I76f248908f649e3a3c91cd3e84d629a0049939ef
When device goes offline, user usually has to manually replug the
usb device. This patch tries to solve two offline situations, all
because when adb on host is killed, the adbd on device is not notified.
1. When adb server is killed while pushing a large file to device,
the device is still reading the unfinished large message. So the
device thinks of the CNXN message as part of the previous unfinished
message, so it doesn't reply and the device is in offline state.
The solution is to add a write_msg_lock in atransport struct. And it
kicks the transport only after sending a whole message. By kicking
all transports before exit, we ensure that we don't write part of
a message to any device. So next time we start adb server, the device
should be waiting for a new message.
2. When adb server is killed while pulling a large file from device,
the device is still trying to send the unfinished large message. So
adb on host usually reads data with EOVERFLOW error. This is because
adb on host is reading less than one packet sent from device.
The solution is to use buffered read on host. The max packet size
of bulk transactions in USB 3.0 is 1024 bytes. By preparing an at least
1024 bytes buffer when reading, EOVERFLOW no longer occurs. And teach
adb host to ignore wrong messages.
To be safe, this patch doesn't change any logic on device.
Bug: http://b/32952319
Test: run python -m unittest -q test_device.DeviceOfflineTest
Test: on linux/mac/windows with bullhead, ryu.
Change-Id: Ib149d30028a62a6f03857b8a95ab5a1d6e9b9c4e
Add more detail about logcat.blocking_clear test failure
Test: gTest logcat-unit-test --gtest_filter=logcat.blocking_clear
Bug: 37483775
Change-Id: I6555c13593781a1278d9106e66c2dec6009a2215
Switch to a reader writer lock for the Element List lock. Also setup
for a reader writer lock for the Times list, but continue to use a
mutex where rdlock() and wrlock() are the same implementation for now.
This should improve general reader performance and prevent blocking of
other reader operations or exit by a single hung logd.reader.per
thread. For example, a full length logcat of an empty buffer (eg:
crash log buffer) will hold a lock while the iterator scans the entire
list.
Test: gTest liblog-unit-tests, logd-unit-tests, logcat-unit-tests
Bug: 37378309
Bug: 37483775
Change-Id: If5723ff4a978e17d828a75321e8f0ba91d4a09e0
KillProcessGroup can return -1 without errno set, which produces error
messages like this:
init: Sending signal 15 to service 'vold' (pid 1806) process group...
init: failed to kill 2 processes for processgroup 1806
init: killProcessGroup(0, 1806, 15) failed: Success
Test: boot and reboot hikey.
Change-Id: I51f242da234daee84795a3fbdffe9ad1f4567140
Signed-off-by: William Roberts <william.c.roberts@intel.com>
- init will only keep animation related services as shutdown critical.
- external component like system server can start shutdown animation.
bug: 37500823
Test: reboot
Change-Id: Ief328306eba7e3b15402ae27e6236767095f508c
In the past, I had thought it didn't make sense to have multiple
Action classes with identical triggers within ActionManager::actions_,
and opted to instead combine these into a single action. In theory,
it should reduce memory overhead as only one copy of the triggers
needs to be stored.
In practice, this ends up not being a good idea.
Most importantly, given a file with the below three sections in this
same order:
on boot
setprop a b
on boot && property:true=true
setprop c d
on boot
setprop e f
Assuming that property 'true' == 'true', when the `boot` event
happens, the order of the setprop commands will actually be:
setprop a b
setprop e f
setprop c d
instead of the more intuitive order of:
setprop a b
setprop c d
setprop e f
This is a mistake and this CL fixes it. It also documents this order.
Secondly, with a given 'Action' now spanning multiple files, in order
to keep track of which file a command is run from, the 'Command'
itself needs to store this. Ironically to the original intention,
this increases total ram usage. This change now only stores the file
name in each 'Action' instead of each 'Command'. All in all this is a
negligible trade off of ram usage.
Thirdly, this requires a bunch of extra code and assumptions that
don't help anything else. In particular it forces to keep property triggers
sorted for easy comparison, which I'm using an std::map for currently,
but that is not the best data structure to contain them.
Lastly, I added the filename and line number to the 'processing
action' LOG(INFO) message.
Test: Boot bullhead, observe above changes
Test: Boot sailfish, observe no change in boot time
Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
Two changes were merged at the same time that conflicted.
Test: builds
(cherry picked from commit 72b9d28423)
Merged-In: Ia6c730804cd5a3b2655e6d69b8e4f346d198dabb
Change-Id: Ia6c730804cd5a3b2655e6d69b8e4f346d198dabb
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 33241851
Test: build and flash internal marlin
Test: m -j libsync
Test: build with BOARD_VNDK_VERSION := current
(cherry picked from commit d0b26edf30)
Merged-In: I5b23d2c1f41b842e5a9b7ea257921133b80c3f98
Change-Id: I5b23d2c1f41b842e5a9b7ea257921133b80c3f98
Added todo once usages are fixed.
Bug: 33241851
Test: things with -Werror now compile in VNDK
(cherry picked from commit 81626e48cb)
Merged-In: I6c4a148dca4d4710912fe62a8854cb8077651701
Change-Id: I6c4a148dca4d4710912fe62a8854cb8077651701
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 33241851
Test: build and flash internal marlin
Test: m -j libbase
Test: build with BOARD_VNDK_VERSION := current
(cherry picked from commit c28517f956)
Merged-In: I720a00deada4e62628e6fbc4ac830265de9c669f
Change-Id: I720a00deada4e62628e6fbc4ac830265de9c669f
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 36426473
Bug: 36079834
Test: m -j libcutils
Test: attempt to compile with BOARD_VNDK_VERSION := current
Test: (sanity) boot internal marlin
(cherry picked from commit 9610c548a8)
Merged-In: I76f9b28ef08a26d84d1365881e00696cc1dcfe5d
Change-Id: I76f9b28ef08a26d84d1365881e00696cc1dcfe5d
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 33241851
Test: build and flash internal marlin
Test: m -j libbacktrace
Test: build with BOARD_VNDK_VERSION := current
(cherry picked from commit 4c0e956c76)
Merged-In: Idab4880e011416ebc40b225205c30fb5ed8661db
Change-Id: Idab4880e011416ebc40b225205c30fb5ed8661db
Test: can include headers in other soong modules
Bug: 33241851
(cherry picked from commit 8f56c1ecd7)
Merged-In: Ie3d11d1559f5aae46125695fd1f3a63da8e429ae
Change-Id: Ie3d11d1559f5aae46125695fd1f3a63da8e429ae
Logspan down to the millisecond. Show a percentage if trimmed by
Chatty messages, a subspan from the newest to the newest chatty in
the log buffer. Sniff stats.add(elem), stats.subtract(elem) and
stats.dropped(elem) to generate the logspan data.
Test: gTest liblog-unit-tests, logd-unit-tests and logcat-unit-tests
Test: manual check Logspan statistics for being in range, added
temporary internal instrumentation to confirm expectations.
Bug: 37254265
Change-Id: I09c0d9375d5580315543c747b37976f9eeb9e408
Replace stats.add(elem) + stats.subtract(elem) with a new more
efficient method stats.addTotal(elem).
Test: gTest liblog-unit-test, logd-unit-tests and logcat-unit-tests
Bug: 37254265
Change-Id: I2b3c2ac44209772b38f383ae46fe6c4422b542cf
If the input file isn't a multiple of block_size, count the trailing
bit as a block in the output, otherwise bootloader will try to write
past the last declared block in the sparse file.
Test: Run sparse_test
Bug: 37339998
Change-Id: Iec143107d15795c6a6f4d3ea7b7515f6f16adcae
ro.logd.kernel, ro.config.low_ram, ro.logd.timestamp and ro.debuggable
need to be retrieved prior to logd start in order for the service to
behave in a configured manner. Other essential services are also
dependent on these system properties as well, so it just makes sense
to pick them all up first in 'on fs'.
Test: smoke test
Bug: 37425809
Change-Id: I33ad185f397ee527ed3c84cc2bcb40ff8ca785b5
- Do not use -f if it was cleanly shutdown.
- For unclean shutdown or other operation failures like
mount, tune2fs failure, run full check.
- Still old image will run full check once in 5 reboots
while new image will not run full check unless something
fails.
- Add retry for final mount. If mount fails once, run full fsck
once and try again.
bug: 32246772
bug: 35366616
Test: many reboots
Change-Id: I86949732ffe1955636ac179d553c91e52910f73e
When BOOL_DEFAULT_FLAG_ENG and/or BOOL_DEFAULT_FLAG_SVELTE is set for
flags parameter in __android_logger_property_get_bool, they can not be
overridden by a supplied property value. Reset these two flags if
there is something in the specified property.
Test: gTest liblog-unit-tests, logcat-unit-tests and logd-unit-tests
Bug: 37425809
Change-Id: I5fc2d727e8c30bc1e781f8b365f44ec62dd36b4d
Helpful instrumentation to determine who is waiting for logger data.
Test: manual
Bug: 37274132
Bug: 37378309
Change-Id: I14fb1d9d15ae413930121048b770852359f06682
Treehugger Robot