Android from scratch: the basics

Hi people,

When the Open Handset Alliance decided to make the Android Platform available I was happy: I could already see myself building crazy mobile apps.
Well since then I have been hit hard by reality: before producing any working piece of code on my I had to get familiar with that new ecosystem.

Android ecosystem is very wide because it covers various aspects from installing the development platform to deploying publicly on Google Play®.
The official documentation is complete thus quite dense. Yet knowing everything is not required when one want to get quick visual result.
The purpose of the post is to help one deploying an application on an Android device (be it virtual or real). A simplified deployment process could be:
– download and install the SDK
– create a virtual device or plug a real one
– create a project
build the project
deploy the project to your device
– enjoy your application
This simple workflow is functionnal but misses more advanced steps like testing with elaborate tools (lint, monkey, etc), preparing artefact for production (obfuscation, zipalign, signing), plublishing artefact on Google Play® (prepare marketing assets, etc).
In this post we’ll focus on the simple workflow. I may write another post on the advanced one.

DISCLAIMER: I was not couragous enough to decline the example for windows systems. All samples are in bash.

1 – Install the SDK

If you’ve never installed any Android SDK you should get and install a starter package first. It will help you manage (install/delete/update) your Android components.
Get the latest archive here and replace the URL below

cd /tmp
tar zvfx android-sdk_r18-linux.tgz
sudo mv android-sdk-linux /opt
sudo ln -s /opt/android-sdk-linux /usr/local/android-sdk
sudo ln -s /usr/local/android-sdk/tools/android /usr/bin/android
sudo ln -s /usr/local/android-sdk/platform-tools/adb /usr/bin/adb
sudo ln -s /usr/local/android-sdk/tools/emulator /usr/bin/emulator
sudo ln -s /usr/local/android-sdk/tools/emulator-arm /usr/bin/emulator-arm

You can now install platforms and other components if needed.

2 – Install platforms

The starter package contains a graphical Android SDK Manager.
Run it with that command line and choose your components

android &

3 – Manage devices

You can test the produced code either on a real device or an emulated/virtual one.
The Android SDK allows you to create such virtual devices. You can then specify hardware options like disk space, ram size, screen resolution. Idealy vendors should provide avds but I could not find any for my Samsung Galaxy S II.
The other way is to connect a real device on a USB port and you’re done. Simpler and close to reality but costy and compelling as a device must always be connected.

3.1 – Manage emulated devices


android create avd -n android-from-scratch -t 14 --skin WVGA800

What we just did? We created an android virtual device named “android-from-scratch” and with a version “14” of its target platform and a “WVGA800”.
The name must be unique and is required (I can’t have 2 “android-from-scratch” AVDs).
The target platform is required. The number 14 is the version of the android API. It corresponds to the name “Android 4.0 Ice Cream Sandwich”. To have a full targets list run:

android list targets

The skin parameter is optional but can save you a lot of time. It’s more of a hardware config than a skin. I’m still wondering why they called it ‘skin’. For example the WVGA800 skin defines the hardware setting hw.ramSize=256
If not statisfied with the skin, you can refine the skin settings. You can find all the new skins for your platform just run the below command, replacing 15 with your target platform version.
Of course the skins are forward compatible. A skin released in platform 13 is available in platform 14 and upper.

grep -r hw.ramSize /usr/local/android-sdk/platforms/android-15/skins/

specify hardware options and skin
Once created you can edit the AVD config file

vi ~/.android/avd/android-from-scratch.avd/config.ini

The full list of supported options is in the documentation
If not satisfided with your virtual device just delete it and create it again

android delete avd -n android-from-scratch

If satisfied you can start your device to see how it looks like and behaves. The android Emulator runs virtual devices

emulator -avd android-from-scratch&

It should look like this

close the emulator or kill its process

3.2 – Real devices

As stated before just plug your device and you’re done.

4 – Run debugger

The Android Debug Bridge (adb) is a core component because it will mainly help you with the following tasks:
– list running devices (be them virtual or real)
– deploy an artefact to any/all device(s)
– print event informations

adb is a server that listens to incoming requests so you may start/stop it.

start server

adb start-server

stop server

adb kill-server

list devices
Adb will list connected devices, print their serialnumber and status (offline|device)

adb devices

5 – Manage projects

Enough for the tools. Now I want to create an application and deploy it to my devices (real and virtual).
The Android SDK provides commands to manage project. You can create and update a project. Update command is more a platform upgrade actually.
In the same spirit of the maven archetypes, this tool will generate a project that includes the minimum functionnal app:
– an activity: AndroidFromScratchActivity. In an MVC model it would be a Controller that registers events to components and updates a View.
– a view descriptor: the file res/layout/main.xml holds a descriptor of the main View. Android runtime uses descriptors under res/layout to instanciate views
– a constants file: res/values/strings.xml. This file holds string values to avoid unecessary duplication. Remember, we are in mobile env: performance is a design issue.
– an application descriptor: describes the application entry point, permissions, versions in a declarative way. Again, the Android runtime will parse and manage lifecycle.
build files: build.xml (ant) and proguard-project.txt (proguard obfuscation tool).

5.1 – Create
mkdir ~/soft/data/workspace/android-from-scratch
android create project --target 14 --name AndroidFromScratch --path ~/soft/data/workspace/android-from-scratch --package --activity AndroidFromScratchActivity
5.2 – Update

If, for any reason you wish to downgrade your android API you can do so. The below code downgrades to API 13

android update project --name AndroidFromScratch --target 13 --path ~/soft/data/workspace/android-from-scratch
5.3 – Project types

You can create 3 types of project. The above commands created a standard project.
You can create a test project which instruments a classic project and a library project which is not runnable, just included in other ones. I won’t dive into the specifics. If you want more information on project types you can read this documentation.

6 – Develop

Pure developement activity requires knowledge. You can read numerous posts (like this one) on the web but if your codebase becomes important I suggest you to read books. They explain the philosophy behind android and you learn to code the right way, often with a sample all along the book. Makes you understand better this or that part of the API.
We’re still going to indulge in a little fantasy, let’s change a label !

vim ~/soft/data/workspace/


<LinearLayout xmlns:android=""
    android:text="Android rocks !!!!"

7 – Build

The build process includes assembling java source and resources, compiling, generating dex files, packaging into apk, signing, zipaligning and obfuscating.
The debug mode provides defaults for this whole process.
The native building tool is ant and the resulting artifact is an apk file.

7.1 – Debug mode

The first time you are in a hurry and you want to know if it works like described in the tutorial, without going into too much details.
But trust me: knowing that your artefact was signed with a default debug key can save you a lot of time because some apps (Google Maps for instance), based on signature, won’t function properly when provided with wrong keys.
The default debug key is generated at build time and stored at ~/.android/debug.keystore.

sudo aptitude install ant &amp;&amp; ant debug
7.2 – Release mode

I might write on this topic in another post because diving into this mode implies an already good understanding of the debug process and its defaults.
The signing step can hide some niceties :).

8 – Manage artifacts

Well so far we’ve created a project and built an apk. We can’t wait to see it on device.
First prepare the devices: plug an android phone and run it (if not already running)
Then run adb (will help us deploying). Note the serial numbers provided by the adb devices command

emulator -avd android-from-scratch&amp;
adb kill-server; adb start-server
adb devices
8.1 – Deploy/Install

Provide the serial number to the -s param and the apk path (example on the emulated device):

adb -s emulator-5554 wait-for-device install ~/soft/data/workspace/android-from-scratch/bin/AndroidFromScratch-debug.apk

You should be seing this on your emulator when accessing the apps screen (our new app is on the top left):

You should be seing this when clicking on the app:

The exact same can be done on the real device:

adb -s 304D192EFC152B7E wait-for-device install ~/soft/data/workspace/android-from-scratch/bin/AndroidFromScratch-debug.apk

You should be seing the exact same.

8.2 – Undeploy/Uninstall

To uninstall you don’t specify the apk path but the application package name. So be sure to provide unique root packages to avoid conflicts …
I don’t know the behaviour when no such package was installed on the device or when 2 apps with same package are installed on the device (is that even possible …). Will they be both removed ?

adb -s 304D192EFC152B7E wait-for-device uninstall

Pfuiii, that was intense but you now have solid basic knowledge on android developement. And most important: you know were to find informations.
You can now focus on real developement without being parasitized by build/install pitfalls. If you’ve already built fat client and are used to DI then it should be quite simple to start.
You can now buy any book on android without having the feeling you’re many step behind.
I did not talk about advanced packaging (proguard, signing, zipaligning), testing (instrumentation testing), tools (debug, monitoring, code quality, android-maven-plugin etc) or publishing process (Google Play) as they are advanced topics and the aim was to have a working solution and to avoid getting lost in too much technical details.
My next move would be to migrate my build on android-maven-plugin as it brings the power of maven and its benefits in terms of professionnal work. Maybe more on that in another post.

Hope you did learn, even a little, reading this post. If so feel free to share.


2 thoughts on “Android from scratch: the basics

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s