Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 407b000f authored by Jiyong Park's avatar Jiyong Park
Browse files

apexd is started much earlier to create loopback devices 

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
parent ea353cab

rootdir/init.rc

+6 −2
Original line number Diff line number Diff line
@@ -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