Category Archives: Android

AVD System Path Not Found Using Ionic CLI

22 Nov 2016

I’m starting to learn Ionic and after a few hours of installing/updating software I went down the short list of commands to see an app on my device. The final command to start an Android emulator, which is:

$ ionic emulate android

Produced this error:

$ ionic emulate android
PANIC: Cannot find
AVD system path. Please define ANDROID_SDK_ROOT

Given the error message we of course need to create a new environment variable but instead of creating “ANDROID_SDK_Root” you instead create one called “ANDROID_AVD_HOME”. Along with creating that new variable we will also need to determine the “AVD system path”.

You will be interested to know that Android searches for the AVD path via three different environment variables in a specific order. The variable names and order of precedence are:

  2. $ANDROID_SDK_HOME\.android\avd\
  3. $HOME\.android\avd\

As you can see, “ANDROID_AVD_HOME” trumps the other paths for specifying where your AVD’s can be found.

Creating environment variables in Windows is well documented everywhere you look, but here’s the short list of steps:

  1. Right-click “My Computer”
  2. Click on “Properties”
  3. Click “Advanced System Settings”
  4. Click “Environment Variables”
  5. Under “System Variables” click “New”
    • For the variable name follow the console output and use “ANDROID_AVD_HOME”
    • For the variable value….. see below

Locating the path to your AVD’s can easily be found by firing up the Android Virtual Device Manager which is located in your Android SDK directory. The path to my Android installation was the following:


Yours may be similar to the above, or use Cortana to locate it for you.

Again, locate and start the Android Virtual Device Manager. In this screen shot I’ve created a single AVD:


Click an AVD to select it then click on the “Details” button. You will see the following:


Note the path to your AVD directory, that is your AVD System Path. Use the path up to the “avd” directory as the value for the variable value as can be seen below:


[EDIT] the trailing slash in your paths is important!!! its not in the screen cap, but you must have a trailing slash!!!!

All done. Restart your console and give it a try.

Enable Debugging in Android Using PhoneGap Build

12 Nov 2016

PhoneGap Build offers easy iOS and Android builds without the need to install any SDK’s. To debug an app in iOS you simply create an Ad Hoc Provisioning Profile, upload it to PhoneGap Build, and then create your app. When its time to build for production you then provide a Distribution Provisioning Profile and PhoneGap Build creates your IPA ready for the App Store. On Android – you don’t have the option of providing a debug or release key as PhoneGap Build will always create a release build from the key that you provide.

In a normal PhoneGap CLI-based setup you would edit Android’s manifest.xml by adding the following attribute to the <application> element.


PhoneGap Build lets you edit the Android Manifest indirectly via a special-purpose element within the PhoneGap Build config.xml document. The element in question takes this form:


Any valid android manifest elements that you add within the above will have its attribute values over-ride its matching element’s attributes in the final manifest. In addition, if you provide an element within the above that doesn’t exist in the build’s manifest then that element will be inserted.

Since the android:debuggable attribute lives within the <application> element then all we need to do to enable debugging is the following:


In order for the above to work you **must** add the Android XML namespace to the widget element of your config.xml:

xmlns:android = ""

So then, a valid widget element would look like this:

The above was tested to work with PhoneGap Build CLI 6.3.0.

For additional information see the PhoneGap documentation.

For additional information re the Android manifest’s <application> element see the relevant documentation.

Angular and Scrolling Content

15 Oct 2015

I’m currently enrolled at in the Angular course. I’m well over half-way through and have been applying Angular to my work projects with great success. One thing that I needed to do was to have scrolling views in my hybrid apps while having other areas of the app remain static. My future goals involve using Ionic – which handles scrolling easily enough, and I suspect, in the exact same way I’ve done it here – but I’m a logical step-by-step kind of guy so for now I’m content with learning Angular and rolling my own UI. That being the case I thought to search for the “Angular” way of getting views to scroll and tried a few of the custom directives available on the Internet.

The easiest to set up was ng-scrollable which technically worked but lacked the finesse of the vaunted iScroll. I also tried angular-iscroll but without much success. I reverted to the usually reliable iScroll but Angular didn’t want to play nicely with it. I then reverted to ng-scrollable thinking I could revisit it and proceeded with my other layout duties only to find that ng-scrollable injected too much crap into the DOM which broke a previously working flex-box-based layout. Attempts to rectify the layout proved to be a waste of time. So, I removed ng-scrollable and instead pursued a native / pure css solution.

The Technique

So lets get back to what I wanted – native-like smooth scrolling with inertia. The answer can be found via CSS by creating a class with the following properties (your wrapping container must have a set width / height, and a setting of “overflow:hidden” on the wrapper will kill scrolling):

.scrollable {
    overflow-x: hidden; // Control how to clip the container's content.
    overflow-y: scroll;
    -ms-overflow-style: -ms-autohiding-scrollbar; // configure overflow scrolling behavior for IE 10
    -webkit-overflow-scrolling: touch; // The magic happens here

Each of the above styles are configured as follows:

  • -webkit-overflow-scrolling
    • auto – Non-inertia scrolling. Scrolling stops as soon as your finger no longer touches the screen.
    • touch – Use inertia-based scrolling, the faster you flick the scrollable content the faster it scrolls but continues to a deaccelration scroll whne your finger stops touching the screen. I find this to be the desired behavior as its closest to native on Mobile.
  • overflow-x, overflow-y – These properties specify how to treat overflowing content via one of the following values:

    • visible – Indicates the content is not clipped, it may be rendered outside the content box.
    • hidden – Indicates the content is clipped and no scrollbars are provided.
    • scroll – Indicates the content is clipped and desktop browsers use scrollbars whether or not any content is clipped. For hybrid application development the scrolling behavior mimics native scrolling where scroll bars don’t appear unless you interact with the scrollable content. On Android at least the scrollbar overlaps content so you should add padding to account for it. On desktop the scrollbars use up additional space within the scrolling wrapper.
    • auto – Depends on the user agent – meaning that you should expect the native behavor for the overflowing content.

I’m not too concerned with IE in my hybrid app development but here are the configuration options none-the-less:

  • -ms-overflow-style – Sets the scrolling behavior for overflowing elements in IE (copied from MS).

    • auto – Indicates the element inherits its -ms-overflow-style from its parent element
    • none – Indicates the element does not display scrollbars or panning indicators, even when its content overflows. Unlike overflow: hidden, elements with -ms-overflow-style: none can still be scrolled via touch panning, keyboard, or mouse wheel.
    • scrollbar – Indicates the element displays a classic scrollbar-type control when its content overflows.
    • -ms-autohiding-scrollbar – Indicates the element displays auto-hiding scrollbars during mouse interactions and panning indicators during touch and keyboard interactions.


If using this on Android / PhoneGap be sure to install the Crosswalk plugin so that you don’t have to worry about compatibility with older webkits.

Also, it is worth noting that sometimes it wont work unless you apply the webkit-specific styling directly to the element like so:

<div id="comeContent" style="-webkit-ovrflow-scrolling: touch;">...

Also worth noting is that if the content of the scrolling element changes that you may need to force the content heights to be recalculate on iOS by inserting a psuedo-element using a simple calc() function to determine its new height:

#comeContent:before {
  width: 1px;
  float: left; // remove from the document flow
  height: calc(100% + 1px); // force the recalculation of the container's height
  margin-left: -1px; // remove from view

Other methods of forcing a screen redraw may work as well.

Installing Crosswalk in an Older PhoneGap Project

08 Sep 2015

Starting with Android 5.0 the webview has been separated from the OS and is now itself an app that will receive updates like any other app. The implication here is that from Android 5.0 and up users won’t have to receive an OS update to get better webviews for PhoneGap apps to use, they can now download and install WebView updates separate from the OS.

All fine and good – in the meantime older Android versions still have the webviews that shipped with the OS / device. OS updates don’t happen very often, typically only occurring when someone gets a new phone or until the device manufacturer decides to issue an update. In even rarer instances a device might be updated if it is rooted and a custom ROM is applied.

Until recently this meant that PhoneGap developers would still have to deal with the various webkits that their apps may encounter and whatever features might be lacking (The most infamous example of a lacking feature that comes to mind was the completely missing toDataURL() canvas method a few years ago.)

Given all the different Android devices in the wild it is sometimes quite a task for developers to be able to create hybrid apps that behave predictably in all the different webkit flavors. The Crosswalk plugin addresses this issue by embedding a web runtime in your Android apps (Android 4 and up) meaning that you don’t need to worry about the version of webkit on older Android OS’s as you now have an modern embedded Chromium under the hood giving you a consistent environment for your apps to execute within.

Today I’m trying to update an older app of mine so that it will use Crosswalk and I hit an issue that prevented me from installing it. The error:

“Plugin doesn’t support this project’s cordova-android version. Cordova-android: 3.6.3, failed requirement: >=4”


The first thing to be aware of is that the CrossWalk plugin requires Android 4. While searching online revealed some hacks to force Crosswalk to install that wasn’t something that I wanted to do.

My first instinct was to edit the manifest.xml since I recall from having previously used Eclipse to compile my apps that that would be the course of action to take. Unfortunately as you may know the Eclipse ADT no longer works with Eclipse and the latest SDK’s so thats not something I want to try and get working since the Cordoca CLI makes compiling a lot easier.

Anyway, editing the manifest.xml didn’t seem to have an effect as rebuilding did nothing and trying to re-add the platform resulted in the “Platform android already added” error message. Searching online revealed a few hacks that could be done and seems to have worked for some people but I didn’t want to pursue any hacky methods so I stopped bothering with trying to use my current project files.

In the end I decided to rebuild my PhoneGap project and target a specific version of Android so as to meet Crosswalk’s requirements. The takeaway is that yes, you’ll have to rebuild and wont be able to install CrossWalk for apps targeting pre Android 4 devices.

The easiest way to rebuild the project to target more recent versions of Android is to simply delete the Android folder out of the project and then rebuild it. While a wholesale delete works a cleaner method (presumably) is to issue the CLI command to remove the platform. Either way you don’t have to worry about reinstalling all of your plugins as Cordova will detect their prior installation and install them all for you when the new target platform is created.

So then, I deleted the Android folder using the CLI via this command…

  • cordova platform remove android

…and then reinstalled Android making sure to target a specific version using this syntax:

  • cordova platform add android@x.x.x

Where the @x.x.x represents the desired version of the OS.

An easy way to see what version numbers will work is to try to create an Android project with a version that doesn’t exist. Try Android 4.2 and Cordova will of course fail the attempted platform add but also show you the valid version numbers / install targets that it expects.


That’s a nice reference – I decided to go for Android 4.1.1 JellyBean.

  • cordova platform add android@4.1.1

In the image below you can see the result of the install followed by a list of all the installed plugins – note that it happened on its own since if you were to look in the project folder all the plugins are there – all we did was delete the platform so Cordova still knows what plugins to install.


A quick build showed my app working – all done!

Installing The SQLite PhoneGap Plugin via the CLI

30 Apr 2014

For some reason I had issues trying to install the PhoneGap SQLite plugin for Android on my Windows 8.1 laptop using the CLI. Attempting to run the install resulted in a Command failed: fatal: could not create work tree dir error. After some fruitless searching for a solution I took another look at the error message and thought that maybe the problem would be something simple to resolve.

This type of CLI command usually works:

$ phonegap plugin add

As mentioned this resulted in the following error:



The key to solving this is in the error message – apparently the temp path can’t be created…. so… create it!

Using Explorer navigate to this path:

  • C:\Users\[YOUR USER NAME]\AppData\Local\Temp

Note that “AppData” is likely a hidden folder – just enter the path (use your own user name where appropriate). For example:




Once in the Temp folder create the necessary directories to recreate the following path:

  • C:\Users\[YOUR USER NAME]\AppData\Local\Temp\plugman\git

And once again run the CLI command for installing the plugin. This time everything runs without error:





All content © 2012-2017.