Developing on a real device
You don't need to get a special development device in order to do development work on it. Pretty much any phone or tablet can be used for regular application development, you just need to make sure it has the version of Android you need on it.
Configuring your device
To enable your phone/tablet to be used as a developement device follow these steps:
- In the "Developer options" settings you need to enable "USB debugging" to allow you to connect to the device using ADB.
- If you don't see developer options - they are hidden by default and getting them to show varies on different devices. On a Nexus you go to "About phone" and tap "Build number" seven times.
- Then you also need to allow your phone to install the apps you build. Go to the "Security" settings and enable installing from "Unknown sources". This way you don't need to go through the trouble and expense of signing your application and publishing them on Google Play.
Note that for security reasons you shouldn't keep the USB debugging option turned on permanently. It's not easy to abuse but it can be done.
Configuring your system
If you have your own Linux system (not the ICT USB Stick) you'll have to allow your user to read and write directly to a USB device. To do this simply add this file to your /etc/udev/rules.d/ directory: 51-android.rules
If you don't do that you'll still be able to use your device, but you'll need to use it as the root user instead.
Rooting and unlocking
This is a complex topic that we don't need to dig into because you don't need a rooted or unlocked device to do development on it. But it's important for you to know what these terms mean:
- Unlocking the phone usually means unlocking it from a specific service provider. When you buy a phone from a telecom (perhaps at a discount) that phone will only work on that provider's network (it's locked to it). You can pay for a code that will unlock the device from that network and then use it with other providers.
- An unrelated thing you can unlock is the boot loader. Devices have a locked boot loader by default which means you will be unable to boot an alternate operating system or make any changes to the system image. This is accomplished with public key cryptography. The process for unlocking the boot loader is different for every device.
- A rooted phone has the "su" command, which will let you run commands as root on the phone. You need to unlock the boot loader before you can root a phone. A rooted phone is great for development if you do more system-level programming rather than just writing apps.
More command-line tools
These commands are used a lot in the real world. While developing a simple test app you may not need them - they are critical when used together with automated deployment systems and various development/QA setups.
android
This command works with the SDK Manager and the AVD Manager. Note that even though later you'll be doing all of your work from Android Studio - the SDKs and AVDs are separate from it and can be used also with Eclipse or with just the command-line.
SDK Manager
This application lets you download and delete parts of the Android development system. Specifically if you want to develop against a specific API (e.g. API 10 which is Android 2.3.3) you can download the development libraries and emulator images from that version.
Theoretically newer versions of the libraries can be used to develop against older APIs but that will give you more trouble than benefits.
AVD Manager
This application will let you create, modify, and start AVDs. These are virtual machines, the same idea as a desktop virtual machine, but specialized for phones. You can create an AVD of any Android version, and choose various hardware configurations for your virtual machine.
Project templates
You can also use the "android" command to create new projects (instead of doing it all manually as you have in the last lab).
Run this command to see the available options, you should be able to understand all the options listed:
android help
emulator
This command will let you run virtual machines you've created with the AVD Manager. For example:
$ android list avd
Available Android Virtual Devices:
Name: myavd
Path: /home/andrew/.android/avd/myavd.avd
Target: Android 2.3.3 (API level 10)
Tag/ABI: default/armeabi
Skin: WVGA800
---------
Name: Nexus_5_API_21
Device: Nexus 5 (Google)
Path: /home/andrew/.android/avd/Nexus_5_API_21.avd
Target: Android 5.0.1 (API level 21)
Tag/ABI: default/x86
Skin: nexus_5
Sdcard: 100M
Snapshot: no
$ emulator -avd Nexus_5_API_21
Remember these commands exist so you can do things (like testing) automatically. The emulator command has many options that you don't need to be concerned with. Now that you know this command exists and the type of options it has - you'll be able to find parameters you need when you need them.
adb
Probably the most commonly used command. Here are the options I feel are the most important from "adb help":
Android Debug Bridge version 1.0.32
-s <specific device> - directs command to the device or emulator with the given
serial number or qualifier. Overrides ANDROID_SERIAL
environment variable.
devices [-l] - list all connected devices
('-l' will also list device qualifiers)
device commands:
adb push [-p] <local> <remote>
- copy file/dir to device
('-p' to display the transfer progress)
adb pull [-p] [-a] <remote> [<local>]
- copy file/dir from device
('-p' to display the transfer progress)
('-a' means copy timestamp and mode)
adb shell - run remote shell interactively
adb shell <command> - run remote shell command
adb logcat [ <filter-spec> ] - View device log
adb install [-lrtsd] <file>
- push this package file to the device and install it
(-l: forward lock application)
(-r: replace existing application)
(-t: allow test packages)
(-s: install application on sdcard)
(-d: allow version code downgrade)
(-p: partial application install)
adb uninstall [-k] <package> - remove this app package from the device
('-k' means keep the data and cache directories)
adb help - show this help message
scripting:
adb kill-server - kill the server if it is running
adb remount - remounts the /system and /vendor (if present) partitions on the device read-write
adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program
adb reboot-bootloader - reboots the device into the bootloader
pm
Short for "Package Manager". This command is on the device, not in your development environment. The adb command does some package management (install/uninstall) but if you want something simple like a list of apps installed you have to use "pm".
$ adb shell root@generic_x86:/ # pm list packages package:com.android.customlocale2 [...] package:com.android.development
or:
$ adb shell "pm list packages" package:com.android.customlocale2 [...] package:com.android.development
monitor
This is a replacement for the old ddms command. You can use this to graphically read the logs (and filter them), monitor memory and CPU usage, download and upload files.
telnet
You can also telnet from your host to your emulator and run some control commands:
$ telnet localhost 5554
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Android Console: type 'help' for a list of commands
OK
help
Android console command help:
help|h|? print a list of commands
event simulate hardware events
geo Geo-location commands
gsm GSM related commands
cdma CDMA related commands
kill kill the emulator instance
network manage network settings
power power related commands
quit|exit quit control session
redir manage port redirections
sms SMS related commands
avd control virtual device execution
window manage emulator window
qemu QEMU-specific commands
sensor manage emulator sensors
try 'help <command>' for command-specific help
OK
window scale 0.2
OK
Android Studio
In the last lab we installed Android Studio but we haven't used the application itself. The package you used for installation included:
- Android Studio, an IDE specifically designed for Android development. It's based on IntelliJ IDEA. A replacement for Eclipse.
- All the command-line tools we've used so far.
- An Android SDK.
- A version of the Android system image to run your app in the emulator.
- An AVD using that image.
Biggest change from Eclipse is move from Ant/Make-based build system to one using Gradle. Another very big change for some types of development is the lack of support for the NDK.
You can use Android Studio as your main IDE for developing an Android app, including:
- Managing all your source files and directories.
- Editing Java, XML, Gradle, other text type files.
- Graphically editing layout XML files.
- Building, deploying, and debugging your apps.
- Using version control.
- Working with the SDK manager, AVD manager, and the Android Device Monitor.
The only downside to it is it's not very stable. Google releases new versions often and they're not backwards compatible, so you may have to relearn how to do some things. Gradle build files are particularly bad when it comes to that. Often you'll find instructions online that simply don't work at all - it's possible the reason is you have a newer version of Android Studio or one of the tools it's using.
Android Studio can update itself to the newest version. Just go to Help/Check for update.