ACPR/android_system_core
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

apexd is started much earlier to create loopback devices

Browse source 
This change fixes the problem that apexd is delaying the entire boot
sequence while waiting for the loopback devices to be created. The delay
was as big as 50 ms per a loopback device.

With this change, apexd is started much earlier: from "on post-fs-data"
to "on init". When it is first started, it scans /system/apex to
determine the number of APEXes and creates that number of loopback
devices priori. Since then it enters into the binder loop.

When the data partition is mounted, init lets apexd to initiate the
apexd boot sequence where APEXes in /data is scanned, verified, and
activated. Since the creation of the loopback devices were requested far
before, it is very likely that dev nodes for the devices are ready at
this moment (even if not, this isn't a lose).

Bug: 123404717
Bug: 123772265
Test: compare boot times.
init_zygote_START_TIME_avg is improved from 2831ms to 2622ms on blueline
Change-Id: I12450cee44aa4d17a11def62261c2f82d3f2c718
This commit is contained in:
Jiyong Park 2019-02-02 19:45:23 +09:00
parent ea353cab91
commit 407b000fe4
1 changed files with 6 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
rootdir/init.rc
View file

@ -277,6 +277,10 @@ on init
# Start logd before any other services run to ensure we capture all of their logs.
start logd
# Start apexd as soon as we can
start apexd
# Start essential services.
start servicemanager
start hwservicemanager
@ -412,8 +416,8 @@ on post-fs-data
mkdir /data/bootchart 0755 shell shell
bootchart start
# Start apexd as soon as we can
start apexd
# /data/apex is now available. Let apexd to scan and activate APEXes.
setprop apexd.data.status ready
# Avoid predictable entropy pool. Carry over entropy from previous boot.
copy /data/system/entropy.dat /dev/urandom