Getting AOSP Android KitKat up and running with the 3.8 kernel has been on my to-do list for a while now. After all, once we get the process in place for 3.8, 3.14+ should be pretty straightforward to get going. I use a file system creation process similar to how Rowboat does it for JellyBean, rather than the raw image writing process that @chris_simmonds has mentioned in the recent past for KitKat, so my partition structure is a little different compared to Chris’s. I don’t use a ram disk with the init process and .rc files inside of it with U-Boot, for example. There was quite a steep learning curve on the various pieces of AOSP, but the O’Reilly book “Embedded Android” by @Karim_Yaghmour has been a huge help in figuring it all out. I even managed to get i2c-tools built in as an additional external project during the AOSP build. Once I am able to get the process ironed out and documented, I’ll make some new pre-made Android images available for download.
@Lewin_Edwards Processor evaluation, research, and education are common goals for running Android on these platforms.
I have received hundreds of mails over the last year or so from development shops around the globe that are trying to decide on a reference platform to serve as a base for a new tablet or smartphone. The open hardware of the BBB makes it an attractive choice, but when you aren’t familiar with the pros and cons of every EVM out there, it is quite helpful to have an established Android build process already ready for you to begin working with for your evaluation.
My PhD research is in the area of dynamic analysis. I study systems as they execute to identify security and data leakage issues. While I can catch every CPU instruction and every memory and I/O operation, I’m only watching bits move around. I must be able to add context to the operations that I am seeing to close this “semantic gap”. Having the source code to the entirety of the OS, bootloader, and kernel is a huge boon for this. I can not only store debug information on the binaries under analysis, but I can also instrument the framework as needed to assist in analysis. With the widespread use of Android-based smartphones, such methods of analysis are of considerable academic and commercial interest. Demonstrating such run-time analyses on real hardware with concrete performance impact numbers is a key factor in the acceptance of such work.
I have used Android on BBB as an educational tool when teaching courses on smartphone technology and embedded systems. Having a platform that can be easily connected to SPI and I2C hardware is huge for this sort of work. It enables students to explore the logistics of extending the Android HAL, writing custom services to interface with kernel-exposed drivers, and expanding the API framework to add new interfaces or implement existing ones (such as SensorManager, for example). Aside from the students that I have worked with directly, I have also received mails from students doing similar project work at a variety of universities all over the world. The low-cost and processing power of the BBB makes it an attractive platform for students on a limited budget that wish to study the Android OS.
@Lewin_Edwards Other than having an actual hardware platform for benchmarking Android app performance, I suspect that most people with an interest in Android on the BBB are more interested in the experience of developing a custom tablet platform (@Nikolay_Elenkov has documented some good work doing this sort of thing, for example) than developing an Android touchscreen app to do something. That doesn’t mean that people aren’t doing UI/hardware interfacing development with it (@Noel_Geren comes to mind), but I suspect that that isn’t the primary focus for most.