Hello all. I posted this information over at the Google+ group for BeagleBoard.org, but I wanted to post it here as well. I have Android running on the BBB using the Jellybean (4.2.2) source from arowboat.org and the Linux 3.8.13 kernel from my BeagleSNES project (www.beaglesnes.org). I just added the Android drivers (Drivers → Staging Drivers → Android) into the same kernel configuration that I use for BeagleSNES. This kernel is really just a stripped down configuration (a 1.9 meg zImage) using Robert Nelson’s 3.8.x kernel source tree. Instead of using the GCC cross-compiler that comes in Rowboat’s current prebuilt tools, I use the 3.7 GCC that comes with Robert’s kernel tree to build the entire system. I also updated the u-boot to v2013.04.
There is no hardware accelerated video in this version, since SGX support isn’t ready for the 3.8 kernel. To shut off hardware accelerated video, I pass “qemu=1” as a kernel command line argument in uEnv.txt and I add “debug.egl.hw=0” to the /system/build.prop file in the root file system. To get rid of that blinking cursor on the framebuffer (which I accidentally left on in the image that I made), add this to the uEnv.txt kernel command line arguments: “vt.global_cursor_default=0”
This build will be of interest to Android experimenters who want to use HDMI for audio and video output (rather than using an LCD cape) and who want to experiment with using the device tree. My kernel is pretty stripped down, so feel free to fetch Robert’s latest kernel source for the 3.8.x branch and rebuild your own kernel to drop into the image that I have supplied. That way, you can include whatever drivers you would like in your kernel. Use a USB mouse (and a keyboard, too, if you want) to interact with the system.
I forget the exact file path off the top of my head, but you can copy your .apk file to somewhere convenient on the /data partition and then browse to it via Android and “launch” the .apk file by double-clicking it. As long as you can browse to the .apk file, you’re good. Under Settings → Applications, make sure that the “Unknown sources” box is checked. The .apk file will be treated as an installer of sorts by the OS when launched. To get the .apk onto the microSD card in the first place, you can use the wired ethernet connection and the web browser to download the .apk. You can also just mount the /data partition under Linux and copy it over that way.
Thanks for the info.
When possible, could you pl. write up a “step by step” howto for newbie’s like me. Don’t understand all the steps listed above.
Or, could you point to links that basically lists the steps for generic android builds that reflect your steps above.
Thanks for sharing Andrew, This looks like a very interesting project.
Can you elaborate further on how you were able to boot the Android 4.2.2 image on the BBB. From what I’ve been reading the arowboat guys have not yet got it working on the BBB.
It's actually pretty cool what Andrew just did.. So in the last few
kernel releases there has been renewed interest in merging the android
kernel stuff in mainline.. So Andrew took the kernel source we are
using for Angstrom/Ubuntu and rebuilt it with more of the Android
config options enabled.. Essentially ignoring the 'arowboat' kernel..
Tweaked a few things, and bam, Android works.
I am still working on writing up some step-by-step instructions for building the complete Android image from scratch. My efforts here are due to my needing a working Android image for the BBB for a class of graduate students in a “Smartphone Technology” at Syracuse University this summer.
An Android kernel is a Linux kernel with about 25k of extra Android-specific code in it. As of Linux 3.3, Android support is part of the mainline Linux kernel, so if you turn on the extra Android features in the kernel configuration you have an Android kernel. You can actually run an Android-enabled Linux kernel on your Linux system, so there isn’t any harm in turning on the additional features. So really, if you have a Linux kernel and system that runs well and stable on the BBB with the drivers that you need, that kernel is ready for an Android system.
Rowboat does have a BBB build, but it is quite new. Last I checked, the wiki documentation had not yet caught up to it. The first I saw of it was when Manish Shakya posted a picture of a 4.1.2 Android build with a 3.2 kernel running on BBB on 6 June to the Google+ BeagleBoard.org discussion area. Once Manish had done the hard work of getting a BBB build into the Rowboat build scripts, swapping out the kernel for 3.8 and upgrading the bootloader were fairly straight-forward. I had to make sure that the kernel data structures that were exposed to the Android system apps during building were correct, so the 3.8 kernel source headers had to be placed into the Rowboat source tree prior to building Rowboat. I actually built the kernel and the bootloader without Rowboat. Only building the root Android file system was done using the Rowboat makefile. I also modified the top-level Rowboat makefile to use the same compiler that I used to build the kernel (to keep everything “simple”).
All of the pieces were there: BBB Rowboat support, Robert’s kernel tree, and a new u-boot that supports device tree kernels. It just took some (very time-consuming) effort to get them all built, in-sync with each other, and configured properly. Luckily, my experience with my own BBB projects has given me the know-how to troubleshoot all of these little system hiccups and cobble together a working Android image. It is my hope that having a “working” reference platform for the 3.8 kernel to start from will assist people that want to try their own Android-enabled kernels, play with the uEnv.txt settings, use a “real” Android system for their application development, etc.
Thanks again Andrew for your work. I really liked the last sentence of your post!
I am new to building Android for the BBB and your step-by-step instructions will be a great resource. I am looking forward to it.
Will you let us know when the instructions will be out? Was it hard to create? Overall it runs well, glad that Android can be supported on the black! Thanks
When I started up the Bone, it went to a screen that said ‘Automatically Logging In’ with the beagleboard logo in the right handside. Android didn’t boot up, and I don’t know why. Did I do something wrong, or should I just wait?
What does the debug output over your FTDI cable show? Was the microSD card detected? If so, is there an error message from the bootloader saying that the kernel wasn’t found? Is there an error message about the .dtb file missing? Do you have four partitions on your microSD card (boot, rootfs, data, usrdata)? Offhand, it sounds like you’re booting off of the eMMC, not the microSD card. Is this a fairly new BBB? Did you follow step #8, here: http://beagleboard.org/Getting%20Started ? We’ll need more information to be able to help you. That’s definitely not Android that you are seeing.
One question, does the 3.8 kernel under Android bring with it Cape support for Capes supported currently? Most interested in the LCD4 which I have, will Android be displayed on that like X does on the standard kernel and allow us to use touch screen?
The short answer is “if it is supported under 3.8 Linux, it is supported under Android because it is the same kernel”. Now, that being said, I have no cape hardware at all, so I can’t tell anyone if it definitely works because I have not seen it with my own eyes. As a PhD student, I just can’t afford to buy all of the various capes for testing. Looking at the am335x-bone-common.dtsi device tree file in the 3.8 kernel, I see support for Adafruit’s 1.8" TFT display (BB-BONE-TFT-01) and the LCD3 cape (BB-BONE-LCD3-01). Looking in my patches, I see the 0167-capes-add-LCD7-A3.patch and 0168-capes-add-basic-support-for-LCD4-capes.patch. So, offhand, I would say support for it is in there. I’m not sure about how loading cape firmware under Android will work, as I have not tried it, but I suspect that it would be built into the kernel as a firmware blob at compile time (Device drivers → Generic Driver Options → Include in-kernel firmware blobs in kernel binary). In the stripped-down kernel that I provided for the sample Android image, capes are enabled (since HDMI is considered a built-in cape), but I don’t believe I included the firmware in the boot partition. I didn’t not turn on support for the Geiger or Nixie capes in the kernel configuration, though, so I hope no one was hoping to use my test Android image to make a Geiger counter.
Android is running on the Linux framebuffer, so I suspect that the cape will show an image similar to how it displays X under Linux: the top-left portion of the screen will be mapped to the physical resolution of the LCD. After all… at its lowest level, X is drawn onto the framebuffer for display. From the cape standpoint, the cape hardware is just pulling its graphics from the framebuffer. Since the DVI cape replicates the display that is shown on the HDMI video output, I would expect LCD capes to act in a similar fashion.
I’m sure that with the hardware and a little time to hack on it, I could cobble something together and provide you with some steps to get everything working. But, unfortunately, I don’t have that knowledge for you right now. Sorry.
If it doesn’t work with the kernel in my image, try rebuilding the kernel with all of the features in it. That instructional link that I included gives the information on how to fetch and build everything, but you only need to worry about the kernel. I may have removed some kernel feature that your cape depends upon (since that kernel came from a different project of mine), so don’t get discouraged if you use my image and it doesn’t work right away. Rebuilding the kernel will also give you all of the firmware blobs, which you might need to copy over to the boot partition to get your cape working.
Well, without more information, I don’t think that I can provide much assistance to you. The FTDI output that I asked for will at least let me know if you’re booting off the eMMC, if you’re trying to boot off the microSD card and failing (i.e. bad kernel name in the uEnv.txt), and whether the microSD card is even detected by your BBB. Also, can you at least mount the microSD card on a Linux system and see all four of the partitions?
