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 wget http://dl.google.com/android/android-sdk_r18-linux.tgz 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
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
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&
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
– stop server
– list devices
Adb will list connected devices, print their serialnumber and status (offline|device)
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 org.diveintojee.poc.android --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 !
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" > <TextView android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="Android rocks !!!!" /> </LinearLayout>
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 && 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& 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 org.diveintojee.poc.android
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.