With the growth of mobile browsing, AddThis has continually improved and optimized layouts, sprites and other elements to make sure that our standard suite of tools works well wherever they are used. SmartLayers was designed to be user-friendly and optimized for phone and tablet viewers. In order to make sure we’re providing that experience, we had to do a lot of testing, across a multitude of devices, screen sizes, browsers and operating systems.
As a publisher using the AddThis tools, you’ll need to do your own testing to verify your user’s mobile experience. Learning to do so is something of a daunting task, but we’ll help walk you through some steps to set up, speed up, level up, and ramp up your experience with Android Emulation, to start.
You’ve changed your user agent, tried BrowserStack or Sauce Labs, maybe done a hundred other things trying to get the perfect view into what your mobile visitors are experiencing, but it’s just not good enough. Luckily you can use the Android Emulator, part of the Android SDK. It’s more accurate than user agent switching, and closer to home than remote VMs, allowing for some interesting remote debugging options.
Note: this article assumes that you’re working on Macintosh OS X and are comfortable with the command line. Once you’ve got the SDK installed, most of the techniques should be applicable on all operating systems.
1. Brewing Your Android
You only need a few of the command line tools from the SDK in order to use the Android Emulator to debug websites; in my experience, “android”, “emulator”, and “adb” (Android Device Bridge). On Macintosh OS X, you can install the SDK which includes these tools using the great package manager, homebrew.
brew install android-sdkAfter install, add the line mentioned in the brew output to your .bashrc or .bash_profile, something like:
export ANDROID_HOME=/usr/local/opt/android-sdk2. Don’t Sprain Your Clicking Finger
Android is not a single OS/version. From the initial release to the date of this writing, there have been 17 numbered “platform” releases, that correspond to the OS versions 1.0 through 4.2.2 that you may be more familiar with. The SDK itself doesn’t contain all of these platforms, you’ll have to install them separately. There’s a graphical tool for doing so, but you can also do it rather easily and efficiently from the command line. To install all of the platforms you don’t have, run:
android update sdk --no-ui --filter platformSame thing for system images (which your emulated devices are built on), just provide a different filter:
android update sdk --no-ui --filter system-imagesUpdate your base SDK tools and platform tools with:
android update sdk --no-ui --filter tool,platform-toolThese are all of the named filters you can use: add-on, doc, extra, platform, platform-tool, sample, source, system-image, tool
If you want to see a list of everything you haven’t installed, run:
android list sdkThis will give you an indexed list. You can provide the index numbers from the list in the filter parameter, in order to install only those items:
android update sdk --no-ui --filter 4,5,6You’ll need to do this if you don’t want to install all of the platforms.
3. Here Loggy, Loggy
You can get the output of javascript console.log statements easily. The logcat tool, part of adb (Android Device Bridge), allows you to ‘tail’ the logging output from an Android device or emulated device (AVD, Android Virtual Device). To cut down on the output you see, so that you only get output from the browser, start it with a command like:
adb -e logcat -v time WebCore:V browser:V *:SThe -e flag tells it to attach to the running emulator, “-v time” tells it to add a timestamp. The *:S parameter tells it to silence output from anything not otherwise white-listed. Include the tag names for Android apps/processes you want to see the logs for, and the log level to show. Here we’ve included WebCore and browser, which are tags that I’ve read are used for the built in web browser. The :V portion causes logcat to show maximum verbosity.
4. Goodbye QEMU, Hello HAXM
The “regular” QEMU based emulator is slow. There are multiple layers of code translation involved as commands are converted into the Dalvik VM (this is Android’s final virtual machine) code used by the emulated device. Install Intel HAXM and forget about QEMU. If you’re just debugging web apps, it’s not likely you’ll have a problem fudging on the processor type.
To do this, go to http://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager and download, then run, the HAXM installer for your platform. Note that even though the HAXM is available via the SDK manager, you want to install it manually.
Open up the Android Virtual Device (avd) manager with the command:
android avdNow, go to one of your existing AVDs and edit it. Change the name and change the processor type to “Intel Atom”. Since you’ve changed the name, when you save it, you’ll be making a copy. Rinse and repeat for all AVDs you want to speed up.
5. Launchpad McSnapshot
Another high-speed technique is to eliminate the initial setup / startup time by enabling snapshots. As with tip #4, open up the AVD manager with the command:
android avdNow edit any AVDs you want and select “Snapshot” next to “Emulation” near the bottom. You’ll have to uncheck “Use Host GPU” in order to do so. Some apps may require the Host GPU setting, so if you experience difficulty, try changing from using snapshots to “Use Host GPU”.
6. Image-ine That
The “emulator” command line tool has more, powerful, command line options than you can shake a stick at. You really will have to go and read over them and think to see whether anything here can help you.
The emulator tool’s disk image options allow you a lot of flexibility in pre-configuring your Android Virtual Devices, and the debug and network options are quite useful as well.
7. Phone Bank
It’s not very fun to have to research what phones and tablets are out there and try to create replicas of them in the AVD manager. Luckily there’s a project to create a shared repository of AVDs (Android Virtual Devices). Get them here:
AndroidAVDRepo.
The bash script “linkavd” has been provided to help integrate those AVDs into your list.
The AVDs consist of a config-like .ini file normally located at ~/.android/avd and a directory which contains the AVDs themselves. There is also a devices.xml file which contains the ‘hardware’ definitions which can be used by an AVD. The “linkavd” script will replace the devices.xml file in ~/.android/ and create .ini files and link to them from ~/.android/avd. Please do NOT run the script if you have a bunch of preexisting AVDs or device definitions that you care about. If you do have pre-existing AVDs or devices, please consider contributing them to the repository.
8. One, You Lock the Target
You can have multiple hardware Android devices connected, and multiple Android Emulator instances running. When this happens, and you need to run one of the “adb” commands, you need to specify which device is the target of the command. To do this, you use one of three different command line flags, and an optional parameter. To target the only device attached, use adb -d <your command>. To target the only emulator, use adb -e <your command>. If there are multiples, it’s a little more complicated, as you need to specify the serial number, which looks like “emulator-5554”. For emulators, the port used will show up in the window’s title, where it will say something like “5554:MyAVD”. The serial number is the device type, then “-“, then the port number. That means this device’s serial number is “emulator-5554”. You can get a list of connected devices by executing adb devices from the command line. There are some cases where you won’t see all of the devices that you know are connected. If that happens, you’ll need to run adb kill-server to reset adb before executing adb devices again.
After you’ve found the proper serial number, you’ll execute a command targeting that device that looks something like this:
adb -s emulator-5554 install jsHybugger.apk9. I am the Keymaster
Once you’ve used an Android Emulator for a while, you’ll notice that you can’t figure out how to change the orientation of the display. The Android Emulator has keyboard commands that allow you to do this, among other things, but the keyboard mappings can be very difficult to work with. By running emulator -help-keys you can view the default key mappings:
HOME Home button
F2, PAGEUP Menu (Soft-Left) button
Shift-F2, PAGEDOWN Star (Soft-Right) button
ESCAPE Back button
F3 Call/Dial button
F4 Hangup/EndCall button
F7 Power button
F5 Search button
KEYPAD_PLUS, Ctrl-F5 Volume up button
KEYPAD_MINUS, Ctrl-F6 Volume down button
Ctrl-KEYPAD_5, Ctrl-F3 Camera button
KEYPAD_7, Ctrl-F11 Switch to previous layout
KEYPAD_9, Ctrl-F12 Switch to next layout
F8 Toggle cell network on/off
F9 Toggle code profiling
Alt-ENTER Toggle fullscreen mode
F6 Toggle trackball mode
DELETE Show trackball
KEYPAD_5 DPad center
KEYPAD_4 DPad left
KEYPAD_6 DPad right
KEYPAD_8 DPad up
KEYPAD_2 DPad down
KEYPAD_MULTIPLY Increase onion alpha
KEYPAD_DIVIDE Decrease onion alphaHowever, NUMLOCK must be OFF for the KEYPAD keys to be recognized. D’oh!
I highly recommend that you change the keyboard mappings to something you find more intuitive and comfortable. In order to do so, open the file ~/.android/default.keyset in your text editor. Overwrite it in order to use your new mappings with all AVDs. If you want to leave the defaults and create a new key mapping you’ll only use sometimes, you’ll have to launch your AVD using the emulator command. An example of directly launching an emulator with a specific keyboard mapping keyset file:
emulator -avd MyAVD -keyset mykeysetNote that “mykeyset” here is actually a file named “mykeyset.keyset” that is located either in the ~/.android/ folder, a “keysets” folder in the system directory, or a “keysets” folder of the program directory (e.g. the tools directory, I think).
Here’s what I have changed in my default.keyset in order to simplify the orientation change commands:
CHANGE_LAYOUT_PREV Keypad_7, Ctrl-F11, RCtrl-F11, Ctrl-P, RCtrl-P
CHANGE_LAYOUT_NEXT Keypad_9, Ctrl-F12, RCtrl-F11, Ctrl-L, RCtrl-LAs an alternative, open up a software keyboard program and use that to control your emulator with the default key commands.
10. A Picture is Worth …
You need to take a screenshot of how that looks on Android, and you’re running an emulator … or maybe not. Regardless, you don’t want to mess with regular screen capture tools for this job. How can you do it with the Android tools? Thankfully some other folks have solved the problem for us and given us a terminal command:
adb shell screencap -p | sed 's/\r$//' > screen.pngThis will save a screenshot from your Android device or emulator as “screen.png” in the current directory. Beautiful!
To Infinity and Beyond
Once you’ve got your AVDs singing, it’s time to look at remote debugging options. Paul Irish has an overview available at https://plus.google.com/+PaulIrish/posts/ccP98BTMd5Z. Until next time, when I get a chance to cover material on that subject in depth, chew on the information and links he’s provided and you’ll be better prepared for the challenges of web development for Android.
References:
Homebrew
Updating Android SDK from Command Line
Targeting Emulator or Device with ADB
Targeting a Specific Device with ADB
Setting ADB logcat Output Format
Emulator Startup Options
Emulator Keyboard Mappings
Grab Android Screenshot from Command Line