Date
1 - 6 of 6
[PROPOSAL] Android boot time improvements
|
artemi.ivanov@cogentembedded.com
; Summary: Android boot time improvements
; Proposer: Artemi Ivanov == Description == Android boot time could be dramatically improved by leveraging checkpoints/snapshots approaches (might be sufficient for variety of products/use cases), on the other side it would be great to study deeper if Android cold boot speed could be improved, at least for automotive/IVI scenarios (get display/video/audio enabled early) == Related work == * 0xlab survey - Shorten Device Boot Time for Automotive IVI and Navigation Systems; Implement Checkpointing for Android; Android Boot Time Optimization * CELF Boot time page - http://elinux.org/Boot_Time == Scope == * Leverage most powerful hw platforms (multicore Cortex-A15 SOCs, fast storage, etc.) * Get max of what could be optimized at bootcode/kernel level (this could be done in a week or so - using boottime cook books) * Try to get Android booting to UI/video/audio in a couple of seconds range (i.e. custom/automotive-focused use-case)... * Compare results with snapshots/checkpoints implementation Efforts: 6-8 weeks == Contractor Candidates == == Comments == [[Category:Project proposals 2013]] |
|
|
|
Jean-Christophe PLAGNIOL-VILLARD
On 10:27 Thu 03 Oct , Artemi Ivanov wrote:
; Summary: Android boot time improvementswhat is the booting target? I've done in the past on non optimised android < 30s from cold start to UI on arm926ejs with base Android < 30s on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s with optimised bootloader (barebox) more powerfull hw does not mean shorter boot time to be able to comparare anything we need have similar hw feature as more driver you have to load means more time to boot. I also could have hw design issue on dev board that slow down the boot * Get max of what could be optimized at bootcode/kernel level (this |
|
|
|
Geert Uytterhoeven
On Thu, Oct 3, 2013 at 9:31 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...> wrote: Hmm, 30 seconds can be a long time ;-)Android boot time could be dramatically improved by leveragingwhat is the booting target? For user interaction, the typical guideline is: upon any user activity, the system should respond within 500 ms, either by performing the operation, or by giving an indication about it's progress. if I e.g. fetch my camera and turn it on, I want to take a picture within 500 ms. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
|
|
|
Jean-Christophe PLAGNIOL-VILLARD
On 10:11 Thu 03 Oct , Geert Uytterhoeven wrote:
On Thu, Oct 3, 2013 at 9:31 AM, Jean-Christophe PLAGNIOL-VILLARDThat is exactly the issue here what means boot time. here I get board with a full system + QT UI in 300ms running from cold start. You must specify what means boot time because boot time can be up to the prompt or up to specific application feature that is customer specific not general purpose Best Regards, J.
|
|
|
|
Bird, Tim <Tim.Bird@...>
On Wednesday, October 02, 2013 11:27 PM, Artemi Ivanov wrote:
Thanks for this proposal. Just to clarify - are you describing getting the Android framework up quickly, or doing a side-load of AV functionality in order to get to a specific feature (video playback) quickly? If the former, I have walked my own trail of tears on this path. It's a difficult problem, due to the architecture of the system. If you have some new insights here I'm very interested (at least personally). If you're talking about side-loading, then how do you envision handing the switchover of resources to java-based software, once the system is up? Thanks, -- Tim BTW: elinux page is at: http://elinux.org/Android_boot_time_improvements |
|
|
|
Bird, Tim <Tim.Bird@...>
On Thursday, October 03, 2013 2:28 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
here I get board with a full system + QT UI in 300ms running from cold start.Wow! That's really impressing. Can you provide any details? Is that from power on to Qt driving the gui with an image up? Are you doing XIP? I haven't seen times under 500 ms. unless people are doing some form of XIP, because binaries are getting so big these days that just the load/link times are getting bad. Did you statically link or pre-link? Thanks - any details on this would be great. I'm trying to find examples of quick boot, to use for the "state of the art" for my status presentation at ELCE. You must specify what means boot time because boot time can be up to theAgreed. It's valuable to see new boot-time enhancement techniques. But we should be specific about what the limits are, relative to other techniques. One appeal of the checkpoint technique is that it appears to be general-purpose. I'm not sure what technique is being proposed in Artemi's project. As an aside, I'm not sure why checkpoint isn't referred to as hibernation, but I haven't looked into the details. -- Tim |
|
|