Google Android Experiences in porting, tips and
April 12, 2010
Introduction and apology
● I don't have as many tricks to share as I
● This is meant to be an talk, not a lecture.
● I work directly for the product group that is
creating the mobile chip sets and platforms
● I've suddenly gotten really busy lately.
● These are ugly slides, sorry.
● What Linux could learn from Google Android
● Google Android PM - the good and the ugly
● Out of tree kernel code == /me getting good at git rebase.
● Google Android Graphics – simple but still difficult (for Intel)
● Fastboot implemented on top of kboot
● Repo, tips and tricks
● SCM approaches for android
● Garret, first impressions.
● Hacking repo (adding a format-patch command)
● Things Intel is focused on WRT Android..AFAIK.
● Closing observations and babbling
What embedded Linux could learn
from Google Android
● Frameworks are important for creating
● User mode PM and application life cycle standards
● ISV's need to be able to develop applications
without being system integrators and kernel
hackers is important
● Integration enabling is important.
● Logcat, ADB, fastboot
Android PM the good the, meh, and
● Its a complete solution out of the box.
● The wake lock concept in user mode is pretty cool, at least its a standard all Android
applications can follow.
● Meh (I'm not ready to say “bad” yet...)
● ABI assumed by stack (early suspend notification, wake locks)
– Early suspend is actually the one I like the least.
● The suspend notification goes all the way up into the surface flinger and helps control
graphics rendering at screen on/off time.
– Worker threads doing blocking reads on wait_for_fb_sleep and wait_for_fp_wake in /sys/power.
● brakes PM for a typical Linux stack running on top of an android enabled kernel
● Grabbing and releasing wake locks in kernel is bad.
● You can't just have a few, you