[android-porting] Android Boot time reduction

[Ashu]

Hi, We are working on Android boot time reduction.
We use OMAP3430 Board as our Hardware. Android version is 1.6 Donut.

We used bootchart to visualize boot pattern. From it, we found that
following things take bulk of time.

1.Zygote process. It actually do the proloading of java classes that
takes @23 secs for its completion.

2. Package manager service.
In logcat output, we can see that Package manager scans 4 dirs,
/system/app,
/system/framework,
/data/app,
/data/app-private.

And it takes nearly 11-12 sec to scan packages as shown below from
logcat output.





I/PackageManager( 827): Got library android.test.runner in /system/
framework/android.test.runner.jar
I/PackageManager( 827): Got library com.android.im.plugin in /system/
framework/com.android.im.plugin.jar
W/PackageManager( 827): Running ENG build: no pre-dexopt!
D/dalvikvm( 827): GC freed 6111 objects / 272568 bytes in 72ms
D/PackageManager( 827): Scanning app dir /system/framework
V/PackageParser( 827): android:backupAgent =
com.android.internal.backup.SystemBackupAgent from android
+com.android.internal.backup.SystemBackupAgent
D/PackageManager( 827): Scanning app dir /system/app
V/PackageParser( 827): android:backupAgent =
com.android.providers.settings.SettingsBackupAgent from
com.android.providers.settings+SettingsBackupAgent
D/dalvikvm( 827): GC freed 3717 objects / 212000 bytes in 67ms
V/PackageParser( 827): android:backupAgent =
com.android.inputmethod.latin.LatinIMEBackupAgent from
com.android.inputmethod.latin+LatinIMEBackupAgent
E/PackageManager( 827): Package com.svox.pico has mismatched uid:
10014 on disk, 10015 in settings; read messages:
E/PackageManager( 827): Read completed successfully: 35 packages, 5
shared uids
E/PackageManager( 827): Package android.tts has mismatched uid: 10015
on disk, 10016 in settings
I/PackageManager( 827): /system/app/SubscribedFeedsProvider.apk
changed; collecting certs
E/PackageManager( 827): Package com.android.providers.subscribedfeeds
requires unavailable shared library com.google.android.gtalkservice;
ignoring!
W/PackageParser( 827): Intent filter for activity
ActivityIntentInfo{439d7c88 com.android.camera.ReviewImage} defines no
actions
D/PackageManager( 827): Scanning app dir /data/app
D/dalvikvm( 827): GC freed 5647 objects / 350752 bytes in 73ms
I/PackageParser( 827): Impliciting adding
android.permission.WRITE_EXTERNAL_STORAGE to old pkg
com.avaw.luklukpro
I/PackageParser( 827): Impliciting adding
android.permission.WRITE_EXTERNAL_STORAGE to old pkg org.iii.ro.iiivpa
I/PackageParser( 827): Impliciting adding
android.permission.READ_PHONE_STATE to old pkg org.iii.ro.iiivpa
E/PackageManager( 827): Package org.iii.ro.iiivpa has mismatched uid:
10016 on disk, 10014 in settings
D/PackageManager( 827): Scanning app dir /data/app-private
I/PackageManager( 827): Time to scan packages: 11.632 seconds


My question is
1. How can we reduce this scan time?
2. Is there any other way/approach to reduce android boot time? I
don't want to reduce android kernel boot time, it is short anyway.



If this is not the right forum to ask this , please redirect me to
correct place.

Thanks in Advance.




--
unsubscribe: android-porti...@googlegroups.com
website: http://groups.google.com/group/android-porting

[Dianne Hackborn]

There is no trivial way to reduce either of those.  The zygote class preloading is essential for good performance of the system after boot.  The package scan can in theory do some caching of its results after first boot, but this is a lot of work and has the potential to introduce serious bugs if the state gets out of sync (we've seen devices ship in the field with subtle bugs in this area probably because they were trying to do such optimizations).

Also the numbers you quote are pretty large.  For example, a myTouch booting Android takes about 11 seconds in zygote preloading and 7.5 seconds to scan packages.  If your hardware is that significantly slower than a myTouch, you may be trimming functionality out of the platform and perhaps you can reduce the class preload set (although you need to be extremely careful when doing so to not break the performance of the system) or remove unneeded .apks.

Fwiw, on Nexus One class hardware class preloading takes 2.5 seconds and package scanning 2 seconds. :}

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Deva R]

As Dianne mentioned, its more appropriate to profile regular boot time, and not the factory reset boot, the very very first boot of a phone, which's a special for many modules..

[Rakesh Kumar]

Hi,
    Please correct me if I am wrong. Can we reduce the booting time by writing the code in assembly which copies the kernel and file system of android to memory.

Thanks & Regards
Rakesh

[ashutosh deshmukh]

Hi ,

 

We are actually working on regular boot time optimization only. The stats & logcat output that I share was for regular boot of Android on OMAP3430.

 

So the stats does not represent the factory reset boot, the very very first boot of phone.

 

The very very first boot on OMAP 3430 Board takes even longer, @85 sec for scanning dirs.

Ashutosh A Deshmukh
Cranes Software International Ltd.
Mobile:9985264283 (Hyderabad)

[Chen Yang]

Cool! Would you like to share some insights on what makes the preloading and scan so efficient on Nexus One? Fast CPU + fast flash? Which one is more important? Or both?
Thanks.
--
Chen

[Tim Bird]

On 05/12/2010 06:33 AM, ashutosh deshmukh wrote:
> Hi ,
> �
> We are actually working on regular boot time optimization only. The
> stats & logcat output that I share was for regular boot of Android on
> OMAP3430.
> �
> So the stats does not represent�the factory reset boot, the very very
> first boot of phone.
> �
> The very very first boot on OMAP 3430 Board takes even longer, @85 sec
> for scanning dirs.

I'm also looking at boot time optimizations on an OMAP. In my
case it's a 3530, running at 600 MHZ, and I'm getting numbers
similar to yours. But I'm doing crufty stuff like using an
NFS root filesystem - so my numbers are probably pretty bogus.
But I still don't see how the Nexus One would be getting only
2 seconds apiece for these operations. (I have one, maybe
I'll have to do a comparison myself.)

I'm very interested in optimizing the class preloading and
scanning, as I had previously identified these as problem
areas. Maybe we can compare notes?

Dianne mentioned that some others had tried to optimize these
phases, and possibly ended up causing bugs. Does anyone have
experience with this that they can share?
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================

[Ashu]

Our development environment also uses NFS root filesystem & we use u-
boot to load the kernel Image.

The average boot time on OMAP 3430 with Android 1.6 SDK is 1 min 18
sec.

The average boot time on OMAP 3430 with Android 2.1 SDK is 1 min 30
sec.

We are also trying to explore areas of booting phase other than 1.
Pre loading & 2. Scanning for boot time reduction purpose.

Any pointers/hints will be highly appreciated.

[Dianne Hackborn]

On Wed, May 12, 2010 at 7:40 AM, Chen Yang <sunse...@gmail.com> wrote:

Cool! Would you like to share some insights on what makes the preloading and scan so efficient on Nexus One? Fast CPU + fast flash? Which one is more important? Or both?

There is nothing so special about the Nexus One in this regard.  It is the newer Qualcomm with actually relatively slow internal flash.

An alternative question would be what is making your board so slow. :}  You might want to do some CPU and storage tests on it to see if there is an issue there.

And note that my numbers for the myTouch -- which I would consider to be pretty much low-end Android hardware for these things -- are better than your numbers.  Maybe for package scanning that could be explained by you having a lot more .apks pre-installed on your device...  but with you taking over 2x as long to do class preloading, I think you have a problem somewhere.

[Tim Bird]

On 05/14/2010 12:02 PM, Dianne Hackborn wrote:
> On Wed, May 12, 2010 at 7:40 AM, Chen Yang <sunse...@gmail.com
> <mailto:sunse...@gmail.com>> wrote:
>
> Cool! Would you like to share some insights on what makes the
> preloading and scan so efficient on Nexus One? Fast CPU + fast
> flash? Which one is more important? Or both?
>
>
> There is nothing so special about the Nexus One in this regard. �It is
> the newer Qualcomm with actually relatively slow internal flash.
>
> An alternative question would be what is making your board so slow. :}
> �You might want to do some CPU and storage tests on it to see if there
> is an issue there.
>
> And note that my numbers for the myTouch -- which I would consider to be
> pretty much low-end Android hardware for these things -- are better than
> your numbers. �Maybe for package scanning that could be explained by you
> having a lot more .apks pre-installed on your device... �but with you
> taking over 2x as long to do class preloading, I think you have a
> problem somewhere.

Dianne,

Thanks very much. This is helpful.

You don't happen to have a bootchart for the myTouch lying around
do you? If not, no bother. But if you have one and could share it,
it would be helpful to compare with what I'm getting on an OMAP
EVM board.

I presume you-all get bootcharts as a standard part of your
builds and testing, since you built it into 'init'.

For others looking at boot time issues, I put some
instructions for using it on Android, as well as a
bootchart from the ADP1, here:
http://elinux.org/Using_Bootchart_on_Android

IMHO, it would be useful, if people have measurements from other
devices or platforms, if we could collect more and post them there.

Thanks,
-- Tim

P.S. Lest I hear cries of hypocrisy, I'll try to get one
for an OMAP EVM running eclair up on the site Real Soon Now... :-)

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================

[Chen Yang]

Dianne:
Thanks a lot! Very helpful.
--
Chen

[Chen Yang]

It would also be interesting to look at the log dumped by logcat with a fresh rebooted nexus one. Would someone share here? Thanks.
--
Chen

[Dianne Hackborn]

Sorry I don't have a boot chart handy.  Most of what I look at is the time to the various log events representing key points during system boot.

Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Akash Choudhari]

Hi Tim,

I have measured much better numbers on our Zoom platform. From what I
remember, it was less than 1 minute for the whole boot, upto Wallpaper

- Akash

[Rakesh Kumar]

Hi ,
     Anyone achieved any success in this case?

Thanks
Rocky

[Rakesh Kumar]

Please give me some pointers for reducing Android boot time.

Thanks & Regards
Rocky