Fom2008 and coming articles

Posted on 22. Nov, 2008 by admin in Android, Blog, Business, Conference & Events, Development, Training & Speaking

On Tuesday 18th November Novoda attended London’s Future of Mobile 2008 and gave a short workshop introduction to Android in conjunction with Kieran Gutteridge of Intohand. The talk was aimed at developers experienced in a variety of other mobile and embedded platforms but who were not familiar with the various specifics of Android. All the attendant’s benefited from the presentation, but ideally more resources prepared for the event would have increased it’s value for everyone. In light of the questions asked to us by developers at FOM we will present on this blog, a series of articles based around the lesser explained points of Android’s underlying architecture and design.

Carl Carl presenting at Fom 2008 with Kieran Gutteridge

Carl presenting at Fom 2008 with Kieran Gutteridge

A Summary of coming articles

In this series we will seek to offer value over Google’s own very well prepared documentation by layering external developer experience and context to each of the areas we cover. This series is intended for seasoned developers who wish to gain a well documented, experienced technical insight into the platform. The following articles are planned:

Android Architecture Overview

Android is often cited as a ‘full stack’. This means that the platform is provided with an OS, sys bins/libs, JRE and SDK. The full shabang is open source from top to bottom but the documentation only lightly covers the Dalvik Virtual Machine. We explore the specifically built packages that make up android from the kernel to the Java libraries in the hope to completely orientate developers with the inner technical workings within most current Android package.

AndroidManifest.xml

The AndroidManifest.xml serves as an application’s contract between it’s end environment and the other installed applications. Through the AndroidManifest.xml an application can choose to expose its intentions, services and content to outside applications. We look into the alternative situations in which the AndroidManifest.xml’s role affects an application and expose its implementation.

Activities

An activity is embodied as a screen and breaks up high level functional elements in an Application. When navigating through an android system the forefront process operates upon the ‘context’ of the shown Activity. We examine the relationships between different types of activities in an attempt to completely understand their life cycle and how it affects the surrounding system.

Intents & BroadcasteReceivers

In Android, actions and re-actions across processes and activities are carried out through means of Intents and BroadcastReceivers. Instead of hard coding the intended application path, applications can choose to leave their journey open to re navigation and simply declare their intentions to the rest of the system. By preemptively declaring their intentions, both the user and other applications can choose to supplement any behavior upon their phone with any other piece of software that offers the same functionality. We explore the extents to which you can choose to customize the experience and look at the practical aspects and challenges that lie in deciding how to best share with the rest of the system.

Views and Resources

External resources are subject to localization and more commonly changed than the internals of an applications inner code. For this reason amongst others the layouts of views are marked up in xml. Binary resources such as images and audio files are also more prone to change and security issues and so are located within a predefined area. The Android SDK makes all resources available through an automatically generated and local binary registry. An application can easily access any of it’s resources via this registry throughout it’s operation. To what advantage has xml been used in such an unconventional why does the Android SDK choose to enforce the location of all binary files so rigidly?

Services

Services have no user interface and can run locally within an application or can take on a life of their own outside any one application, adhering to Linux’s inbuilt security model. Remote Services are shared via Android’s own IDL (Interface description language). The majority of the code for this external communication is generated for a user after declaring the interface by which the data is to be exchanged.

Content Providers

The architecture of Android applications is designed around the idea of opting into a degree of sharing within a community of applications. And application can choose to what extent it makes its data available through content providers. Content providers promote the idea of global data inter exchange and reuse within every system and we look at how Applications can best take advantage of this unique feature upon the Android platform.

We would be very happy to hear comments, criticism and requests so if you have anything to say on anything we cover then please leave a comment.

Citations & Research

0 Comments

Extending Android’s shell with BusyBox

Posted on 12. Nov, 2008 by admin in Android, Blog, Development, Tools

A vanilla android installation is a bare bones affair aimed solely at the mobile device. This comes at the initial expense of our development environment. This platform is only intended for only the smallest devices and so searching amongst ‘system/bin‘ reveals only a cherry picking of Linux system administrator staples, even the most common binaries such as ‘ls‘, ‘mv‘ and ‘rm‘ have been stripped of all but their essential options and recompiled. Installing third party tools on Android offers a range of additional productive tools and options for ease of development within the Android shell.

Android shell

Invoking the android emulator from within an IDE is the ideal setup but developers will find need to interact with the emulator through other means for scripting, integration testing and just practical reasons. The SDK tools are located in the tools directory and I’d recommend regular users of the sdk to add this directory to their shell’s export path.

I develop on a mac so I have added the android-sdk-mac_x86-1.0_r1/tools to my .profile but you could equally add it to your .bashrc or .kornrc within your user’s home area giving you convenient direct access to all of android’s development tools via the binary names such as $adb, $emulator or $ddms. If you are on a windows machine these variables would instead be set via your system settings -> environment variables.

With the tools on the shells $PATH, the emulator can now be invoked:

$emulator

Now to telnet to the running device image:

$adb shell

BusyBox

BusyBox is a single multicall binary that packages the functionality of many popular standard Unix tools. The aim of the BusyBox project is to keep the total package size overhead as small as possible by sharing commonly used gnu libC libraries via a single set of ELF headers and stripping down gnu’s libc so as only to provide the functions necessary to support Busybox and the other executables.

Side note – Standing up for GNU with legal action

Busybox author’s have gained a reputation for their commendable efforts to uphold the legal rights of the GNU public license as they have brought about court action as plaintiffs on a series of cases where they believed companies were not holding to the terms of GNU public license. Companies they have appealed against include Verizon, High-Gain Antennas and Xterasys. Most notably they are commonly credited with the first GNU public licence related court action against Monsoon Multimedia for their use of BusyBox within it’s HAVA streaming video software (Hava have since made their alterations available). So far all cases have been settled before they reached the court.

Installing busy box on Android

It is common place for developers to check out the source of BusyBox and compile a tailor made build with any preferred tools and options. There are others like myself who just use whatever they can find and I have settled with a build generously donated with the intent of android deployment by Ben Leslie available from both his site and the run buddy code wiki.

First aquire your build and then add it to the running android device like so:

$adb shell mkdir /data/busybox
$adb push busybox /data/busybox
$adb shell

Now within the android Emulator shell:

$cd /data/busybox
$chmod 775 busybox
$./busybox –install

Now you have installed BusyBox!

For ease of use I would add this to the shell’s $PATH

export PATH=/data/busybox:$PATH

Now invoking busybox will reveal all your new commands!

$busybox

Some highlights of this particular binary of BusyBox are:
chown, chgrp: change permission ownership.
awk, sed: languages to both process & transform text
grep: a text search utility
du: shows disk usage
vi: a shell based text editor
pidof: return the pid of a running process
less: text reader with back and forward nav
tail: trail the end of a file for activity
gunzip, gzip, tar, bzip2: archival compression software
clear: clear screen
crontab, crond: task scheduling
diff: compare files
httpd: a light webserver
telnet: basic TCP remote login
xargs: use the output of a command as the arguments for another
su: masquerade as another system user
wget: retrieves content from a web server
which: identifies the location of an executable
For info on these or any linux commands check the man pages online.

Have I missed any of your shell essentials? If you have any BusyBox builds for Android then we’d love to hear about how you are using them in your development environment.

Android SDK at time of writing was: android-sdk-mac_x86-1.0_r1

Citations & Research

4 Comments