Droidcedas : Edifice A Wireless Android Device Using Beaglebone Black

Our previous posts were nigh code signing inward Android, in addition to they turned out to live surprisingly relevant amongst the annunciation of the 'master key' code signing Android vulnerability. While details are yet to live formally released, it has been already patched in addition to dissected, thence we'll skip that 1 in addition to seek something different for a change. This postal service is non direct related to Android security, but volition hash out roughly Android implementation details, thence it powerfulness live of roughly involvement to our regular readers. Without farther ado, let's instruct closer to the metallic than usual in addition to create a wireless Android device (almost) from scratch.

Board introduction -- BeagleBone Black

For our device we'll occupation the late released tracking satellites. You tin claw it upward to circuits you've create or speedily extend it using 1 of the many 'cape' plug-in boards available. We'll occupation a twosome of those for our project, thence 'building' refers to a greater extent than oftentimes than non to creating an Android create compatible amongst our hardware. We'll special the hardware later, but let's maiden of all outline roughly unproblematic requirements for our mobile Android device:
  1. touch hide input
  2. wireless connectivity via WiFi
  3. battery powered
Here's what nosotros start with:

Building a nub for Android

Android back upward for AM335x-based devices is provided past times the rowboat project. It integrates the required nub in addition to OS patches in addition to provides create configurations for each of the supported devices, including the BBB. The latest version is based on Android 4.2.2 in addition to if you lot desire to instruct started quickly, you lot tin download a binary build from TI's Sitara Android development kit page. All you lot demand to exercise is flash it to an SD card, connect the BBB to an HDMI display in addition to powerfulness it on. You volition at nowadays instruct a fully working, hardware-accelerated Jelly Bean 4.2 device you lot tin command using measure USB keyboard in addition to mouse. If that is all you lot need, you lot powerfulness every bit good halt reading here. Our maiden of all requirement, withal is a working deport on screen, non an HDMI monitor, thence nosotros receive got roughly piece of work to do. As it happens, a reveal of LCD capes are already available for the BBB (from circuitco in addition to others), thence those are our maiden of all choice. We opted for the LCD4 4.3" cape which offers almost reasonable resolution in addition to is modest plenty to live direct attached to the BBB. Unfortunately it doesn't piece of work amongst the rowboat create from TI. To empathise why, let's receive got a measuring dorsum in addition to hash out how the BBB supports extension hardware, including capes.

Linux Device Tree in addition to cape support

If you lot aspect at the expansion header pinout tabular array inward the BBB reference manual, you lot volition notice that each pivot tin serve multiple purposes, depending on configuration. This is called 'pinmuxing' in addition to is the method modern SoC's occupation to multiplex multiple peripheral functions to a express laid of physical pins. The AM335x CPU the BBB uses is no exception: it has pins amongst upward to 8 possible peripheral functions. So, inward club for a cape to work, the SoC needs to live configured to occupation the right inputs/outputs for that cape. The province of affairs becomes to a greater extent than complicated when you lot receive got multiple capes (up to iv at a time). BBB capes solve this past times using EEPROM that stores plenty information to position the cape, its revision in addition to series number. At kick time, the nub identifies the capes past times reading their EEPROMs, computes the optimal configuration (or outputs in addition to mistake if the connected capes are non compatible) in addition to sets the expansion header pinmux accordingly. Initially, this was implemented inward a 'board file' inward the Linux kernel, in addition to adding a novel cape required modifying the nub in addition to making certain all possible cape configurations were supported. Needless to say, this is non an slow task, in addition to getting it merged into Linux mainline is fifty-fifty harder. Since everyone is edifice roughly form of ARM device nowadays, the reveal of board files in addition to variations thereof reached critical mass, in addition to Linux nub maintainers decided to decouple board specific conduct from the kernel. The machinery for doing this is called Device Tree (DT) in addition to its goal is to brand life easier for both device developers (no demand to hack the nub for each device) in addition to nub maintainers (no demand to merge board-specific patches every other day). Influenza A virus subtype H5N1 DT is a information construction for describing hardware which is passed to the nub at kick time. Using the DT, a generic board driver tin configure itself dynamically. The BBB ships amongst a 3.8 nub and takes total wages of the novel DT architecture. Cape back upward is naturally implemented using DT source (DTS) files in addition to fifty-fifty goes a measuring farther than mainline Linux past times introducing a Cape Manager, an in-kernel mechanism for dynamically loading Device Tree fragments from userspace. This allows for runtime (vs. kick time) loading of capes via sysfs, resources conflict resolution (where possible), manual command over already loaded capes in addition to more.

Going dorsum to Android, the rowboat Android port is using the 3.2 nub in addition to relies on manual porting of extension peripheral configuration to the nub board file. As it happens, back upward for our LCD4 cape is non at that topographic point yet. We could seek to land the nub based on the 3.8 DTS files, or receive got the plunge in addition to endeavour to run Android using 3.8. Since all BBB active evolution is going on inward the 3.8 branch, using the newer version is the ameliorate (if to a greater extent than involved) choice.

Using the 3.8 kernel

As nosotros know, Android adds a bunch of 'Androidisms' to the Linux kernel, most notably wakelocks, alert timers, ashmem, binder, depression retentiveness killer in addition to 'paranoid' network security. Thus you lot could non occupation a vanilla Linux nub every bit is to run Android until recently, in addition to a reveal of Android-specific patches needed to live applied first. Fortunately, thank you lot to the Android Mainlining Project, most of these features are already merged (in 1 shape or another) inward the 3.8 nub in addition to are available every bit staging drivers. What this way is that nosotros tin receive got a 3.8 nub that plant good on the BBB in addition to occupation it run Android. Unfortunately, the BBB can't quite occupation a vanilla 3.8 nub yet in addition to requires quite a few patches (including Cape Manager). However, edifice a 3.8 nub amongst all BBB patches applied is non likewise difficult to do, thank you lot to instructions in addition to create scripts past times Robert Nelson. Even better, Andrew Henderson has successfully used it inward Android in addition to has detailed the procedure. Following Andrew's create instructions, nosotros tin create an Android create that has a skillful gamble of supporting our deport on screen. As Andrew's article mentions, hardware acceleration (support for the BBB's PowerVR SGX 530 GPU) is non yet available for the 3.8 kernel, thence nosotros demand to disable it inward our build. One thing that is missing from Andrew's didactics is that you lot also demand to disable edifice in addition to installing of the SGX drivers, otherwise Android volition seek to occupation them at kick in addition to neglect to start SurfaceFlinger due to driver-kernel module incompatibility. You tin exercise this past times commenting out the dependency on sgx inward rowboat's top-level Makefile similar this:

@@ -11,7 +13,7 @@  CLEAN_RULE = sgx_clean wl12xx_compat_clean kernel_clean create clean  else  ifeq ($(TARGET_PRODUCT), beagleboneblack) -rowboat: sgx +#rowboat: sgx  CLEAN_RULE = sgx_clean kernel_clean create clean  else  ifeq ($(TARGET_PRODUCT), beaglebone)  

Note that the nub lonely is non plenty though: the kick loader (Das U-Boot) needs to live able to charge the (flattened) device tree blob, thence nosotros demand to create a recent version of that every bit well. Android seems to run OK amongst this configuration, but at that topographic point are still a few things that are missing. The maiden of all you lot powerfulness notice is ADB support.

ADB support

ADB (Android Debug Bridge) is 1 of the best things to came out of the Android project, in addition to if you lot receive got been doing Android evolution inward whatever shape for a while, you lot in all probability receive got it for granted. It is a fairly complex slice of software though, providing back upward for debugging, file transfer, port forwarding in addition to to a greater extent than in addition to requires nub back upward inward add-on to the Android daemon in addition to customer application. In nub damage this is known every bit the 'Android USB Gadget Driver', in addition to it is non quite available inward the 3.8 kernel, fifty-fifty though at that topographic point receive got been multiple attempts at merging it. We tin merge the required bits from Google's 3.8 nub tree, but since nosotros are trying to remain every bit unopen every bit possible to the original BBB 3.8 kernel, we'll occupation a different approach. While attempts to instruct ADB inward the mainline continue, Function Filesystem (FunctionFS) driver back upward has been added to Android's ADB in addition to nosotros tin occupation that instead of the 'native' Android gadget. To occupation ADB amongst FunctionFS:
  1. Configure FunctionFS back upward inward the nub (CONFIG_USB_FUNCTIONFS=y):
    • Device Drivers -> USB Support ->       USB Gadget Support -> USB Gadget Driver -> Function Filesystem 
  2. Modify the kick parameters inward uEnv.txt to laid the vendor in addition to production IDs, every bit good every bit the device series number
    • g_ffs.idVendor=0x18d1 g_ffs.idProduct=0x4e26 g_ffs.iSerialNumber=<serial>
  3. Setup the FunctionFS directory in addition to mountain it inward your init.am335xevm.usb.rc file:
    • on fs     mkdir /dev/usb-ffs 0770 musical rhythm shell     mkdir /dev/usb-ffs/adb 0770 musical rhythm shell     mountain functionfs adb /dev/usb-ffs/adb uid=2000,gid=2000 
  4. Delete all lines referencing /sys/class/android_usb/android0/*. (Those nodes are created past times the native Android gadget driver in addition to are non available when using FunctionFS.)
Once this is done, you lot tin reboot in addition to you lot should come across your device using adb devices before long after the nub has loaded. Now you lot tin debug the OS using Eclipse in addition to force in addition to install files direct using ADB. That said, this won't assist you lot at all if the device doesn't kick due to roughly nub misconfiguration, thence you lot should definitely instruct an FTDI cable (the BBB does non receive got an on-board FTDI chip) to live able to come across nub messages during kick in addition to instruct an 'emergency' musical rhythm when necessary.

cgroups patch

If you lot are running adb logcat inward a console in addition to experimenting amongst the device, you lot volition notice a lot of 'Failed setting physical care for group' warnings similar this one:

W/ActivityManager(  349): Failed setting physical care for grouping of 4911 to 0 W/SchedPolicy(  349): add_tid_to_cgroup failed to write '4911' (Permission denied); 

Android's ActivityManager uses Linux command groups (cgroups) to run processes amongst different priorities (background, foreground, audio, system) past times adding them to scheduling groups. In the mainline nub this is solely allowed to processes running every bit root (EUID=0), but Android changes this conduct (naturally, amongst a patch) to solely require the CAP_SYS_NICE capability, which allows the ActivityManager (running every bit system inward the system_server process) to add together app processes to scheduling groups. To instruct rid of this warning, you lot tin disable scheduling groups past times commenting out the code that sets upward /dev/cpuctl/tasks inward init.rc, or you lot tin merge the modified functionality shape Google's experimental 3.8 branch (which we've been trying to avoid all along...).

Android hardware support

Touchscreen

We at nowadays receive got a functional Android evolution device running to a greater extent than oftentimes than non without warnings, thence it's fourth dimension to aspect closer at requirement #1. As nosotros mentioned, 1 time nosotros disable hardware acceleration, the LCD4 plant fine amongst our 3.8 kernel, but a few things are still missing. The LCD4 comes amongst v directional GPIO buttons which are somewhat useful because scrolling on a resistive touchscreen takes roughly getting used to, but that is non the solely thing they tin live used for. We tin remap them every bit Android organisation buttons (Back, Home, etc) past times providing a key layout (.kl) file similar this one:

key 105   BACK               WAKE substitution 106   HOME               WAKE substitution 103   MENU               WAKE substitution 108   SEARCH             WAKE substitution 28    POWER              WAKE 

The GPIO keypad on the LCD identifies itself every bit 'gpio.12' (you tin cheque this using the getevent command), thence nosotros demand to squall the layout file to 'gpio_keys_12.kl'. To attain this nosotros modify device.mk inward the BBB device directory (device/ti/beagleboneblack):

... # KeyPads PRODUCT_COPY_FILES += \     $(LOCAL_PATH)/gpio-keys.kl:system/usr/keylayout/gpio_keys_12.kl \ ... 

Now that nosotros are using hardware buttons, nosotros powerfulness desire to mash roughly to a greater extent than hide existent estate from the LCD4 past times non showing the organisation navigation bar. This is done past times setting config_showNavigationBar to false inward the config.xml framework overlay file for our board:

<bool name="config_showNavigationBar">false</bool> 

While playing amongst the screen, nosotros notice that it's a fleck dark. Increasing the brightness via the display settings withal does non seem to work. Influenza A virus subtype H5N1 friendly mistake message inward logcat tells us that Android can't opened upward the /sys/class/backlight/pwm-backlight/brightness file. Screen brightness in addition to LEDs are controlled past times the lights module on Android, thence that's where nosotros aspect first. There is a a hardware-specific 1 nether the beagleboneblack device directory, but it solely supports the LCD3 in addition to LCD7 displays. Adding back upward for the LCD4 is merely a thing of finding the file that controls brightness nether /sys. For the LCD4 it's called /sys/class/backlight/backlight.10/brightness in addition to plant precisely similar the other LCDs -- you lot instruct or laid the brightness past times reading or writing the backlight intensity story (0-100) every bit a string. We modify light.c (full source on Github) to maiden of all seek the LCD4 device in addition to voila -- setting the brightness via the Android UI at nowadays works... not. It turns out the brightness file is owned past times root in addition to the Settings app doesn't receive got permission to write to it. We tin modify this permission inward the board's init.am335xevm.rc file:

# PWM-Backlight for display brightness on LCD4 Cape chmod 0666 /sys/class/backlight/backlight.10 

This lastly settles it, thence nosotros tin cross requirement #1 off our listing in addition to seek to tackle #2 -- wireless support.

WiFi adapter

The BBB has an onboard Ethernet port in addition to it is supported out of the box past times the rowboat build. If nosotros desire to brand our novel Android device mobile though, nosotros demand to add together either a WiFi adapter or 3G modem. 3G back upward is possible, but somewhat to a greater extent than involved, thence nosotros volition seek to enable WiFi first. There are a number of capes that provide WiFi in addition to Bluetooth for the original BeagleBone, but they are non compatible amongst the BBB, thence nosotros volition seek using a regular WiFi dongle instead. As long every bit it has a Linux driver, it should live quite slow to wire it to Android past times next the TI porting guide, right?

We'll occupation a WiFi dongle from LM Technolgies based on the Realtek RTL8188CUS chipset which is supported past times the Linux rtl8192cu driver. In add-on to the nub driver, this wireless adapter requires a binary firmware blob, thence nosotros demand to brand certain it's loaded along amongst the nub modules. But earlier getting knee-deep into makefiles, let's briefly review the Android WiFi architecture. Like most hardware back upward inward Android, it consists of a nub layer (WiFi adapter driver modules), native daemon (wpa_supplicant), HAL (wifi.c inward libharware_legacy, communicates amongst wpa_supplicant via its command socket), a framework service in addition to its populace interface (WifiService in addition to WifiManager) in addition to application/UI ('WiFi' hide inward the Settings app, every bit good every bit SystemUI, responsible for showing the WiFi condition bar indicator). That may good fairly straightforward, but the WifiService implements roughly pretty complex solid soil transitions inward club to deal the underlying native WiFi support. Why is all the complexity needed? Android doesn't charge nub modules automatically, thence the WifiStateMachine volition seek to charge nub modules, uncovering in addition to charge whatever necessary firmware, start the wpa_supplicant daemon, scan for in addition to connect to an AP, obtain an IP address via DHCP, cheque for in addition to handgrip captive portals, in addition to finally, if you lot are lucky, laid upward the connexion in addition to ship out a broadcast to notify the residuum of the organisation of the novel network configuration. The wpa_supplicant daemon lonely tin snuff it through xiii different states, thence things tin instruct quite involved when those are combined.

Going step-by-step through the porting guide, nosotros maiden of all enable back upward for our WiFi adapter inward the kernel. That results inward six modules that demand to live loaded inward order, plus the firmware blob. The HAL (wifi.c) tin solely charge a unmarried module though, thence nosotros pre-load all modules inward the board's init.am335xevm.rc in addition to laid the wlan.driver.status to ok inward club to forbid WifiService from trying (and failing) to charge the nub module. We thence define the wpa_supplicant in addition to dhcpd services inward the init file. Last, but non least, nosotros demand to laid the wifi.interface holding to wlan0, otherwise Android volition silently seek to occupation a exam device in addition to neglect to start the wpa_supplicant. Both properties are laid every bit PRODUCT_PROPERTY_OVERRIDES inward device/ti/beagleboneblack/device.mk (see device directory on Github). Here's how the relevant component from init.am335xevm.rc looks like:

on post-fs-data     # wifi     mkdir /data/misc/wifi/sockets 0770 wifi wifi     insmod /system/lib/modules/rfkill.ko     insmod /system/lib/modules/cfg80211.ko     insmod /system/lib/modules/mac80211.ko     insmod /system/lib/modules/rtlwifi.ko     insmod /system/lib/modules/rtl8192c-common.ko     insmod /system/lib/modules/rtl8192cu.ko  service wpa_supplicant /system/bin/wpa_supplicant \        -iwlan0 -Dnl80211 -c/data/misc/wifi/wpa_supplicant.conf \        -e/data/misc/wifi/entropy.bin        course of didactics primary        socket wpa_wlan0 dgram 660 wifi wifi        disabled        oneshot  service dhcpcd_wlan0 /system/bin/dhcpcd -ABKL        course of didactics primary        disabled        oneshot  service iprenew_wlan0 /system/bin/dhcpcd -n        course of didactics primary        disabled        oneshot  

In club to create the wpa_supplicant daemon, nosotros thence set BOARD_WPA_SUPPLICANT_DRIVER in addition to WPA_SUPPLICANT_VERSION inward device/ti/beagleboneblack/BoardConfig.mk. Note the nosotros are using the generic wpa_supplicant, non the TI-patched 1 in addition to the WEXT driver instead of the NL80211 1 (which requires a proprietary library to live linked in). Since nosotros are preloading driver nub modules, nosotros don't demand to define WIFI_DRIVER_MODULE_PATH in addition to WIFI_DRIVER_MODULE_NAME.

BOARD_WPA_SUPPLICANT_DRIVER      := WEXT WPA_SUPPLICANT_VERSION           := VER_0_8_X BOARD_WLAN_DEVICE                := wlan0 

To brand the framework aware of our novel WiFi device, nosotros modify networkAttributes in addition to radioAttributes inward the config.xml overlay file. Getting this incorrect volition Pb to Android's ConnectionManager totally ignoring WiFi fifty-fifty if you lot deal to connect in addition to volition outcome inward the non likewise helpful 'No network connection' message. "1" hither corresponds to the ConnectivityManager.TYPE_WIFI connexion type (the built-in Ethernet connexion is "9", TYPE_ETHERNET).

<string-array name="networkAttributes" translatable="false"> ...   <item>"wifi,1,1,1,-1,true"</item> ... </string-array> <string-array name="radioAttributes" translatable="false">   <item>"1,1"</item> ... </string-array> 

Finally, to brand Android aware of our newly flora WiFi features, nosotros re-create android.hardware.wifi.xml to /etc/permissions/ past times adding it to device.mk. This volition receive got attention of enabling the Wi-Fi hide inward the Settings app:

PRODUCT_COPY_FILES := \ ...  frameworks/native/data/etc/android.hardware.wifi.xml:system/etc/permissions/android.hardware.wifi.xml \ ... 

After we've rebuild rowboat and updated the root file system, you lot should live able to plow on WiFi in addition to connect to an AP. Make certain you lot are using an air conditioning powerfulness render to powerfulness the BBB, because the WiFi adapter tin depict quite a fleck of electrical flow in addition to you lot may non instruct plenty via the USB cable. If the board is non getting plenty power, you lot powerfulness sense failure to scan, dropping connections in addition to other weird symptoms fifty-fifty if your configuration is otherwise correct. If WiFi back upward doesn't piece of work for roughly reason, cheque the following:
  • that the nub module(s) in addition to firmware (if any) is loaded (dmesg, lsmod)
  • logcat output for relevant-lookin mistake messages
  • that the wpa_supplicant service is defined properly inward init.*.rc in addition to the daemon is started
  • that /data/misc/wifi in addition to wpa_supplicant.conf are available in addition to receive got the right possessor in addition to permissions (wifi:wifi in addition to 0660)
  • that the wifi.interface in addition to wlan.driver.status properties are laid correctly
  • use your debugger if all else fails
That was easy, right? We at nowadays receive got a working wireless connection, it's fourth dimension to squall back nigh requirement #3, powering the device.

Battery power

The BBB tin live powered inward iii ways: via the miniUSB port, via the 5V air conditioning adapter jack, in addition to past times using the powerfulness rail (VDD_5V) on the board directly. We tin occupation whatever USB battery pack that provides plenty electrical flow ( 1A) in addition to has plenty capacity to hold the device going past times merely connecting it to the miniUSB port. Those tin live rather bulky in addition to you lot volition demand an extra cable, thence let's aspect for other options. As tin live expected, at that topographic point is a cape for that. The aptly named Battery Cape plugs into the BBB's expansion connectors in addition to provides powerfulness direct to the powerfulness rail. We tin plug the LCD4 on top of it in addition to instruct an integrated (if a fleck bulky) battery-powered touchscreen device. The Battery Cape holds iv AA batteries connected every bit ii sets inward parallel. It is non merely a glorified battery holder though -- it has a boost converter that tin provide stable 1A electrical flow at 5V fifty-fifty if battery voltage fluctuates (1.8-5.5V). It does provide back upward for monitoring battery voltage via AIN4 input, but does non receive got a 'fuel gauge' chip thence nosotros can't display battery story inward Android without adding additional circuitry. That is ways our mobile device cannot display the battery story (yet) in addition to unfortunately won't live able to unopen itself downward when battery levels snuff it critically low. That is something that definitely needs work, but for at nowadays nosotros brand the device ever believe it's at 100% powerfulness past times setting the hw.nobattery holding to true. The alternative is to receive got it display the 'low battery' cherry-red warning icon all the time, thence this approach is somewhat preferable. Four 1900 mAh batteries installed inward the battery cape should provide plenty powerfulness to run the device for a few hours fifty-fifty when using WiFi, thence nosotros tin (tentatively) score requirement #3 every bit fulfilled.

Flashing the device

If you lot receive got been following Andrew Henderson's create guide linked above, you lot receive got been 'installing' Android on an SD menu in addition to booting the BBB from it. This plant fine in addition to makes it slow to create things when Android won't charge past times merely mounting the SD menu on your PC in addition to editing or copying the necessary files. However, most consumer story SD cards don't offering the best functioning in addition to tin live quite unreliable. As nosotros mentioned at the commencement of the post, the BBB comes amongst 2GB of built-in eMMC, which is plenty to install Android in addition to receive got roughly infinite left for a information partition. On most Android devices flashing tin live performed past times either booting into the recovery organisation or past times using the fastboot tool over USB. The rowboat create does non receive got a recovery image, in addition to spell fastboot is supported past times TI's fork of U-Boot, the version nosotros are using to charge the DT blob does non back upward fastboot yet. That leaves booting roughly other OS inward lieu of a recovery in addition to flashing the eMMC shape there, either manually or past times using an automated flasher image. The flasher icon merely runs a script at startup, thence let's come across how it plant past times doing it manually first. The latest BBB Angstrom bootable image (not the flasher one) is a skillful selection for our 'recovery' OS, because it is known to piece of work on the BBB in addition to has all the needed tools (fdisk, mkfs.ext4, etc.). After you lot dd it to an SD card, mountain the menu on your PC in addition to re-create the Android kick files in addition to rootfs archive to an android/ directory. You tin thence kick from the SD card, instruct a root musical rhythm on the Angstrom in addition to install Android to the eMMC from there.

Android devices typically receive got a boot, system in addition to userdata parition, every bit good every bit a recovery 1 in addition to optionally others. The kick sectionalization contains the nub in addition to a ramdisk which gets mounted at the root of the device filesystem. system contains the actual OS files in addition to gets mounted read-only at /system, spell userdata is mounted read-write at /data in addition to stores organisation in addition to app data, every bit good user-installed apps. The sectionalization layout used past times the BBB is slightly different. The board ootloader volition aspect for the maiden of all phase bootloader (SPL, named MLO inward U-Boot) on the maiden of all FAT sectionalization of the eMMC. It inward plow volition charge the minute solid soil bootloader (u-boot.img) which volition thence search for a OS icon according to its configuration. On embedded devices U-Boot configuration is typically stored every bit a laid of variables inward NAND, replaced past times the uEnv.txt file on devices without NAND such every bit the BBB. Thus nosotros demand a FAT kick sectionalization to host the SPL, u-boot.img, uEnv.txt, the nub icon in addition to the DT blob. system in addition to userdata volition live formatted every bit EXT4 in addition to volition piece of work every bit inward typical Android devices.

The default Angstrom installations creates solely ii partitions -- a DOS 1 for booting, in addition to a Linux 1 that hosts Angstrom Linux. To laid upward the eMMC for Android, you lot demand to delete the Linux sectionalization in addition to create ii novel Linux partitions inward its house -- 1 to concur Android organisation files in addition to 1 for user data. If you lot don't invention to install likewise many apps, you lot tin merely brand them equal sized. When booting from the SD card, the eMMC device volition live /dev/block/mmcblk1, amongst the maiden of all sectionalization existence /dev/block/mmcblk1p1, the minute /dev/block/mmcblk1p2 in addition to thence on. After creating those 3 partitions amongst fdisk nosotros format them amongst their respective filesystems:

# mkfs.vfat -F 32 -n kick /dev/block/mmcblk1p1 # mkfs.ext4 -L rootfs /dev/block/mmcblk1p2  # mkfs.ext4 -L usrdata /dev/block/mmcblk1p3  

Next, nosotros mountain boot in addition to re-create kick related files, thence mountain rootfs in addition to untar the rootfs.tar.bz2 archive. usrdata tin live left empty, it volition live populated on maiden of all boot.

# mkdir -p /mnt/1/ # mkdir -p /mnt/2/ # mountain -t vfat /dev/block/mmcblk1p1 /mnt/1 # mountain -t ext4 /dev/block/mmcblk1p2 /mnt/2 # cp MLO u-boot.img zImage uEnv.txt am335x-boneblack.dtb /mnt/1/ # tar jxvf rootfs.tar.bz2 -C /mnt/2/ # umount /mnt/1 # umount /mnt/2 

With this, Android is installed on the eMMC in addition to you lot tin shutdown the 'recovery' OS, take away the SD menu in addition to kick from the eMMC. Note that the U-Boot used has been patched to probe whether the SD menu is available in addition to volition automatically kick from it (without you lot needing to concur the BBB's user kick button), thence if you lot don't take away the 'recovery' SD card, it volition kick again.

We at nowadays receive got a working, deport on hide Android device amongst wireless connectivity. Here's how it looks inward action:

Our device is unlikely to win whatever blueprint awards or supercede your Nexus 7, but it could live used every bit the soil of  dedicated Android devices, such every bit a wireless POS terminal or a SIP telephone in addition to extended fifty-fifty farther past times adding to a greater extent than capes or custom hardware every bit needed.

Summary

The BBB is fully capable of running Android in addition to past times adding off-the shelf peripherals you lot tin easily plow it into a 'tablet' (of sorts) past times adding a deport on hide in addition to wireless connectivity. While the required software is to a greater extent than oftentimes than non available inward the rowboat project, if you lot desire to receive got the best hardware back upward you lot demand to occupation BBB's native 3.8 nub in addition to configure Android to occupation it. Making hardware fully available to the Android OS is to a greater extent than oftentimes than non a thing of configuring the relevant HAL bits properly, but that is non ever straightforward, fifty-fifty amongst board vendor provided documentation. The argue for this is that Android subsystems are non especially cohesive -- you lot demand to modify multiple, sometimes seemingly unrelated, files at different locations to instruct a unmarried subsystem working. This is, of course, non specific to Android in addition to is the cost to pay for edifice a organisation past times integrating originally unrelated OSS projects. On the positive side, most components tin live replaced in addition to the required changes tin normally live confined to the (sometimes loosely defined) Hardware Abstraction Layer (HAL). 
0 Komentar untuk "Droidcedas : Edifice A Wireless Android Device Using Beaglebone Black"

Back To Top