system_core/init, branch replicant-10

reboot: allow opting-in to fastbootd

2020-03-07T13:05:16+00:00

Change-Id: Iaf5eb813e848ef05b1b455ebfe3643f4a8b4f80d

Merge tag 'android-10.0.0_r31' into lineage-17.1-android-10.0.0_r31

2020-03-07T12:42:13+00:00

Android 10.0.0 release 31

* tag 'android-10.0.0_r31':
  Store crashing process name in sysprop
  Allowing /avb/q-developer-gsi.avbpubkey for DSU
  Adding the AVB public key for Q-Developer-GSI
  FlattenableUtils::align memsets

Change-Id: Ia9d79894d1a390669031842f83c1bba3d185e9b2

init: only provide control message results for devices launching > Q

2020-01-13T17:28:41+00:00

This is a behavior change and may have unintended consequences,
especially in Java, where failed property sets create exceptions.
Therefore, we only provide this new behavior to devices launching > Q.

Bug: 137070994
Test: build
Change-Id: If0b44aedc5c887ea6ea16dd3ec551ac2bf793cef
(cherry picked from commit 5310db82b012131242f723742e02426abcf1c684)

Ignore class_{reset|start}_post_data on non-updatable APEX.

2020-01-13T15:43:31+00:00

For devices that use FDE and don't support updatable APEXes, don't
stop and restart all processes - there is no need and it only increases
boot time for these devices.

Additionally, some daemons have never been restarted in the past, and
restarting them exposes certain issues.

Bug: 137251597
Bug: 136777273
Bug: 135627804
Test: verified manually w/ ro.updatable.apex=false
Change-Id: I9590f2c2cdfab0a49f39846896460305d44221ee
(cherry picked from commit 728586f5b23d830b1d14c61abcf85cd72dc95412)

Reland^2: "init: run property service in a thread"

2020-01-13T15:43:12+00:00

It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command.  This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.

This change has init run property service in a thread, which
eliminates the above issue.

This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.

Reland: during reboot, init stops processing property_changed messages
from property service, since it will not act on these anyway.  This
had an unexpected effect of causing future property_set calls to block
indefinitely, since the buffer between init and property_service was
filling up and the send() call from property_service would then
block.  This change has init tell property_service to stop sending it
property_changed messages once reboot begins.

Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I26902708e8be788caa6dbcf4b6d2968d90962785
(cherry picked from commit 1ab3dfcab469198114c4bb4a3914c6b64b891f72)

init: add error handling in control message

2020-01-13T15:42:59+00:00

Bug: 133432022
Test: boot
Test: setprop ctl.interface_restart android.hardware.power@1.0::IPower/default success
Test: setprop ctl.interface_restart android.hardware.power@1.0::IPower/abc fail
Change-Id: I66342b2723eb01022fb4e0d98f0b6ffc2752bcac
(cherry picked from commit 5f01d3af77d420c0bd0688e86ceb9c7772c1c76a)

init: simplify async restorecon

2020-01-13T15:42:38+00:00

In the future, property service may run in its own thread or process,
which means that PropertyChildReap() needs to be refactored to not run
as part of the init signal handler.

The new method spawns a new thread that handles the queue of paths
that require restorecon. It then communicates back to property service
via android::base::SetProperty(). Property service distinguishes the
thread from other callers of SetProperty() by checking the pid in the
credentials for the socket connection, thus avoiding dependencies on
the rest of init.

The new method also drops the genericness, since restorecon is the
only function that we should ever need to run asynchronously

Test: async restorecon works, including with queued requests
Change-Id: I2ca00459969e77b1820776dac23d0a0d974e330b
(cherry picked from commit fe8154175c411b0dba6bbc881cf9dfe501be74c5)

init: handle getpeercon() errors

2020-01-13T15:42:25+00:00

Though unlikely, it is possible for getpeercon() to fail.  This change
adds code to handle this case gracefully.

Bug: 130209483
Test: boots, properties are set
Change-Id: I3b3fb76b2312a5cbc87c0da2a044be3ddf8aa400
(cherry picked from commit 7f160af14246e8819839e1693496c7e2f304a7b8)

init: set up SelinuxAuditCallback() earlier

2020-01-13T15:42:11+00:00

The setup of SelinuxAuditCallback() was happening after property files
are loaded, and now that these property files can trigger audits, the
audit messages did not contain all of the correct information.  This
change moves the setup of SelinuxAuditCallback() to immediately before
the property area is initialized, to ensure that this can not happen
again.

Bug: 130979265
Test: audits work early
Change-Id: I9eb43269317c74e041626ee7b2bb7fea49250e09
(cherry picked from commit 2f113ad1e147fdf26e74e42ccf130184440dc4ea)

ueventd: make parallel restorecon functionality optional

2020-01-04T13:49:13+00:00

5aa6197d5f387579ff04c330001840d6988e825f added the ability to
parallelize restorecon to speed up boot for devices that have not
completely moved to genfscon.  This parallel restorecon happens after
the parallel ueventd handling.

This causes a performance regression for devices that have moved to
genfscon, since previously, the restorecon() was done in the main
ueventd thread in parallel with the uevent handlers.

I also tried to run the fully parallelized restorecon in parallel with
the uevent handlers, but that did not make any change to the cold boot
time, likely due to the additional overhead of parallelizing the work.

Bug: 140458170
Test: blueline coldboot time returns to pre-regression time.
Change-Id: I3cd6a869cc9b62792466813d94ad6c69834e854e