Official Android ADK Guides

• Official Google Android ADK page
  • ADK Components
  • Getting Started with the ADK
  • How an Accessory Communicates with an Android-powered Device in Accessory Mode
  • How the ADK board communicates with an Android-powered Device in Accessory Mode

Related Android Guides

• USB Accessory Dev Guide
• Android USB driver

Videos

• Google I/O Session Video: Android Open Accessory API and Development Kit (ADK)

Arduino

• Arduino Language Reference
• Arduino Library Reference
• Makezine Arduino Page

Hardware

Android Specific Components

• RT Corp
• Microchip
• DIY Drones

Arduino Components

• Boards
• Maker Shed

Examples

• Robot from Google IO
• 5,000-pound labyrinth from Google IO
• ADK Components

Have any more that I missed? Add a comment and I’ll update the list.

The post is in “blog” format with paragraphs shoved into the middle of code. For reference you can find the original demokit.pde file over in this Gist.

demokit.pde

The Arduino language is based on C/C++ so the file starts off with the typical headers you’ll need for the various libraries used in the sketch (servos, LEDs, capacitive touch, USB, etc).

#include <Wire.h>
#include <Servo.h>
#include <Max3421e.h>
#include <Usb.h>

These two are the ones you added to the Arduino application libraries when you set up your system for ADK development.

#include <AndroidAccessory.h>
#include <CapSense.h>

Next, you’ll see several ‘#define’ constants. These indicate which pins are attached to which features on the Android Demo Shield. If you look at the shield, you’ll notice each pin has a corresponding number. For example #define LED3_RED 2 indicates that the third LED’s red component pin is using #2 on the shield.

Technically you don’t need to do this and you could just use 2 throughout your code but defining a constant makes it much easier to read and understand the code when you use LED3_RED instead of referring to the board to see what pin 2 is.

#define  LED3_RED       2
#define  LED3_GREEN     4
#define  LED3_BLUE      3

#define  LED2_RED       5
#define  LED2_GREEN     7
#define  LED2_BLUE      6

#define  LED1_RED       8
#define  LED1_GREEN     10
#define  LED1_BLUE      9

#define  SERVO1         11
#define  SERVO2         12
#define  SERVO3         13

#define  TOUCH_RECV     14
#define  TOUCH_SEND     15

#define  RELAY1         A0
#define  RELAY2         A1

#define  LIGHT_SENSOR   A2
#define  TEMP_SENSOR    A3

#define  BUTTON1        A6
#define  BUTTON2        A7
#define  BUTTON3        A8

#define  JOY_SWITCH     A9      // pulls line down when pressed
#define  JOY_nINT       A10     // active low interrupt input
#define  JOY_nRESET     A11     // active low reset output

Now it’s time to identify the actual accessory. Read my previous post on “Identifying Your Android USB Accessory “ for more information but you can see here that the demokit.pde file identifies itself as version 1.0 of the Google DemoKit accessory.

AndroidAccessory acc("Google, Inc.",
             "DemoKit",
             "DemoKit Arduino Board",
             "1.0",
             "http://www.android.com",
             "0000000012345678");

Now, all that’s left to do is initialize a few variables, setup the environment and then start the loop that will continuously run to evaluate the IO for the Arduion board.

// Define an array for the servos
Servo servos[3];

// Initiate the touch sensor
// 10M ohm resistor on demo shield
CapSense   touch_robot = CapSense(TOUCH_SEND, TOUCH_RECV);

// Run the initial setup on the board
void setup();

// Loop and check for IO 
void loop();

Initialization

The pinMode() method is used to initialize the input and output pins on the Android Demo Shield. It configures the specified pin to behave either as an INPUT or an OUTPUT. Arduino pins default to INPUT so the mode doesn’t need to be explicitly set but its usually a good idea to do it anyway so that your code is clear and understandable.

For example, the init_buttons function identifies the pins for BUTTON1, BUTTON2, BUTTON3 and JOY_SWITCH as input connections.

void init_buttons()
{

    pinMode(BUTTON1, INPUT);
    pinMode(BUTTON2, INPUT);
    pinMode(BUTTON3, INPUT);
    pinMode(JOY_SWITCH, INPUT);

To identify the state of the buttons, a pin configured as an INPUT can have a HIGH or LOW value. Writing a HIGH value with will enable an internal 20K pullup resistor. Writing LOW will disable the pullup. The pullup resistor acts as a known value when no other input is present (such as when pressing the button). Later you can use digitalRead() to check the value to determine if the button has been pressed or not.

    digitalWrite(BUTTON1, HIGH);
    digitalWrite(BUTTON2, HIGH);
    digitalWrite(BUTTON3, HIGH);
    digitalWrite(JOY_SWITCH, HIGH);
}

Output pins, such as the relays in init_relays() are also configured using the pinMode() function however no default value needs to be written to the relays because it is always told to be either on or off.

// Initializes the relays as outputs
void init_relays()
{
    pinMode(RELAY1, OUTPUT);
    pinMode(RELAY2, OUTPUT);
}

The digitalWrite() method can also take varying values as inputs. For example, you may want to write an integer between 1 and 255 to represent the brightness of an LED. The init_leds() function sets all the LED pins as outputs and presets their output value to 1 (or bright).

// Initialize the LED outputs
void init_leds()
{

    digitalWrite(LED1_RED, 1);
    digitalWrite(LED1_GREEN, 1);
    digitalWrite(LED1_BLUE, 1);

    pinMode(LED1_RED, OUTPUT);
    pinMode(LED1_GREEN, OUTPUT);
    pinMode(LED1_BLUE, OUTPUT);

    digitalWrite(LED2_RED, 1);
    digitalWrite(LED2_GREEN, 1);
    digitalWrite(LED2_BLUE, 1);

    pinMode(LED2_RED, OUTPUT);
    pinMode(LED2_GREEN, OUTPUT);
    pinMode(LED2_BLUE, OUTPUT);

    digitalWrite(LED3_RED, 1);
    digitalWrite(LED3_GREEN, 1);
    digitalWrite(LED3_BLUE, 1);

    pinMode(LED3_RED, OUTPUT);
    pinMode(LED3_GREEN, OUTPUT);
    pinMode(LED3_BLUE, OUTPUT);
}

The joystick controls are little tricker so I’m not going to go into it in this post. If you’re interested see the init_joystick() and related functions at the bottom of the demokit.pde file that comes with the kit.

void init_joystick(int threshold);

Setup

Now that all the necessary helper functions are defined we can look at the setup function. The setup() function begins serial communications with the device and then calls all the initialization methods you saw earlier.

// These are a few variables to hold the state of the buttons.
byte b1, b2, b3, b4, c;

// Setup the board
void setup()
{
    // Begin communications.
    Serial.begin(115200);
    Serial.print("\r\nStart");

    init_leds();
    init_relays();
    init_buttons();
    init_joystick( 5 );

Next, setup() calibrates the capacitive touch sensor and sets the servos to their initial positions of 90 degrees.

    // autocalibrate OFF
    touch_robot.set_CS_AutocaL_Millis(0xFFFFFFFF);

    servos[0].attach(SERVO1);
    servos[0].write(90);
    servos[1].attach(SERVO2);
    servos[1].write(90);
    servos[2].attach(SERVO3);
    servos[2].write(90);

Lastly, setup() assigns the current HIGH or LOW value of the buttons to b1, b2, b3 and b4. During the loop execution, these values will be compared to the values in the loop and used to determine if the button’s state has changed since the last loop.

    b1 = digitalRead(BUTTON1);
    b2 = digitalRead(BUTTON2);
    b3 = digitalRead(BUTTON3);
    b4 = digitalRead(JOY_SWITCH);
    c = 0;

Now the setup power’s on the accessory.

    acc.powerOn();
}

Loop

The loop() function is the heart beat of the Arduino Base Board. After creating and executing the setup() function, which is responsible for initializing the initial values, the loop begins it’s magic and loops consecutively, allowing the sketch to analyze and respond accordingly.

The loop in demokit.pde has two main responsibilities. First, if the device is connected, it will read any input and write output to the device as necessary. Second, if no device is connected it will reset all the initial values to await a new device connection.

void loop()
{
    byte err;
    byte idle;
    static byte count = 0;
    byte msg[3];
    long touchcount;

Here it looks for a connection.

    if (acc.isConnected()) {

        int len = acc.read(msg, sizeof(msg), 1);
        int i;
        byte b;
        uint16_t val;
        int x, y;
        char c0;

If the length of the input buffer from the attached Android device is greater than zero, the loop process the input command to determine what it should do.

        if (len > 0) {

The message format can be seen in the DemoKit Android App that also comes with the kit. If you take a look at the sendCommand() method in the com.google.android.DemoKit.DemoKitActivity class. You’ll see something like this:

...
buffer[0] = command;
buffer[1] = target;
buffer[2] = (byte) value; 
...

In the case of a LED or Servo command, the command‘s value is 2 (DemoKitActivity.LED_SERVO_COMMAND), followed by the target and the value to associate with the target.

For example, you can see in the following code that the red, green and blue pins for each LED are updated, but only when msg[0] is 2 (0x2). The LED pin to update is defined in msg[1] (0x0 thru 0x8 respectively) and the value is set using msg[2] and analogWrite().

In the case of the value for a LED, the lower the value the brighter the light (or the higher the value the more black and darker the light). The DemoKit app on the Android device sends 255 when it wants a full bright light so the value is subtracted from 255 to set the appropriate value for “bright”.

            // Assumes only one command per packet.
            if (msg[0] == 0x2) {
                if (msg[1] == 0x0)
                    analogWrite(LED1_RED, 255 - msg[2]);
                else if (msg[1] == 0x1)
                    analogWrite(LED1_GREEN, 255 - msg[2]);
                else if (msg[1] == 0x2)
                    analogWrite(LED1_BLUE, 255 - msg[2]);
                else if (msg[1] == 0x3)
                    analogWrite(LED2_RED, 255 - msg[2]);
                else if (msg[1] == 0x4)
                    analogWrite(LED2_GREEN, 255 - msg[2]);
                else if (msg[1] == 0x5)
                    analogWrite(LED2_BLUE, 255 - msg[2]);
                else if (msg[1] == 0x6)
                    analogWrite(LED3_RED, 255 - msg[2]);
                else if (msg[1] == 0x7)
                    analogWrite(LED3_GREEN, 255 - msg[2]);
                else if (msg[1] == 0x8)
                    analogWrite(LED3_BLUE, 255 - msg[2]);

The servo output uses the same command and is processed in the same if condition however setting the servo position is a little different. You can read more in the Servo library but the basics here are that the servo’s write() method takes an angle for the servo and the map() method is used to re-map the input value from one range (0-255) to another (0-180).

                else if (msg[1] == 0x10)
                    servos[0].write(map(msg[2], 0, 255, 0, 180));
                else if (msg[1] == 0x11)
                    servos[1].write(map(msg[2], 0, 255, 0, 180));
                else if (msg[1] == 0x12)
                    servos[2].write(map(msg[2], 0, 255, 0, 180));

            } else if (msg[0] == 0x3) {

For the two relays on the Android Demo Shield, msg[2] is simply compared for a HIGH or LOW value and the board is updated accordingly.

                if (msg[1] == 0x0)
                    digitalWrite(RELAY1, msg[2] ? HIGH : LOW);
                else if (msg[1] == 0x1)
                    digitalWrite(RELAY2, msg[2] ? HIGH : LOW);

            }

        }

At this point in the loop, all the input messages have been processed so the loop switches to checking all the output pins and sending any necessary messages to the device. The message type for output is set to 1 and each individual output is checked.

        msg[0] = 0x1;

For example, in the following code the state of BUTTON1 is read into b and compared to b1. Earlier you saw how the read value of the pin associated with BUTTON1 could be either HIGH or LOW. If the value of b differs from the value of b1 (defined in setup() or in the previous run of the loop) then the state of the button has changed and the appropriate message is sent back to the connected Android device. At the same time, b is assigned to b1 to indicate the new state for the next loop.

        b = digitalRead(BUTTON1);
        if (b != b1) {
            msg[1] = 0;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b1 = b;
        }

        // Check button 2
        b = digitalRead(BUTTON2);
        if (b != b2) {
            msg[1] = 1;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b2 = b;
        }

        // Check button 3
        b = digitalRead(BUTTON3);
        if (b != b3) {
            msg[1] = 2;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b3 = b;
        }

        // Check for a press on the joystick button.
        b = digitalRead(JOY_SWITCH);
        if (b != b4) {
            msg[1] = 4;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b4 = b;
        }

Once all the digital reads for the buttons have completed, the demokit uses an analogRead() to determine the current values of the temperature sensor, the light sensor, the joystick and the capacitive touch sensor. At first I was confused by the use of a switch statement here until I realized the expense of an analog read. It takes about 100 microseconds to read an analog input, so the maximum reading rate is 10,000 times a second. That’s pretty good but we don’t want to slow things down unnecessarily, especially when environmental variables such as temperature and ambient light are not changing dramatically at a rapid pace. The switch and count++ % 0x10 condition allows the loop to reduce the frequency of analog reads and only sample one analog read per loop.

        switch (count++ % 0x10) {
        case 0:
            val = analogRead(TEMP_SENSOR);
            msg[0] = 0x4;
            msg[1] = val >> 8;
            msg[2] = val & 0xff;
            acc.write(msg, 3);
            break;

        case 0x4:
            val = analogRead(LIGHT_SENSOR);
            msg[0] = 0x5;
            msg[1] = val >> 8;
            msg[2] = val & 0xff;
            acc.write(msg, 3);
            break;

        case 0x8:
            read_joystick(&x, &y);
            msg[0] = 0x6;
            msg[1] = constrain(x, -128, 127);
            msg[2] = constrain(y, -128, 127);
            acc.write(msg, 3);
            break;

        case 0xc:
            touchcount = touch_robot.capSense(5);

            c0 = touchcount > 750;

            if (c0 != c) {
                msg[0] = 0x1;
                msg[1] = 3;
                msg[2] = c0;
                acc.write(msg, 3);
                c = c0;
            }

            break;
        }
    } else {

As mentioned earlier, when a device is not connected (or was disconnected) the loop resets the outputs to the default values.

        analogWrite(LED1_RED, 255);
        analogWrite(LED1_GREEN, 255);
        analogWrite(LED1_BLUE, 255);
        analogWrite(LED2_RED, 255);
        analogWrite(LED2_GREEN, 255);
        analogWrite(LED2_BLUE, 255);
        analogWrite(LED3_RED, 255);
        analogWrite(LED3_GREEN, 255);
        analogWrite(LED3_BLUE, 255);
        servos[0].write(90);
        servos[0].write(90);
        servos[0].write(90);
        digitalWrite(RELAY1, LOW);
        digitalWrite(RELAY2, LOW);
    }

Then the loop ends by delaying for a few milliseconds.

    delay(10);
}

The remainder of the file deals with the IO of the joystick. You can just take it as is and I’ll leave it until another post.

Hopefully this was a little helpful getting you started with the ADK and the demokit example.

AndroidAccessory(const char *manufacturer,
                 const char *model,
                 const char *description,
                 const char *version,
                 const char *uri,
                 const char *serial);

For example, the DemoKit app that comes with the ADK identifies itself as version 1.0 of the Google DemoKit accessory:

AndroidAccessory acc("Google, Inc.",
                 "DemoKit",
                 "DemoKit Arduino Board",
                 "1.0",
                 "http://www.android.com",
                 "0000000012345678");

You’re own app might looks something like this:

AndroidAccessory acc("My App Company",
                 "CoolAccessory",
                 "CoolAccessory Arduino Board",
                 "1.0",
                 "http://www.example.com/CoolAccessory",
                 "0000000012345678");

The three key one’s you’ll need to remember are manufacturer, model and version as you’ll need to define these in you’re Android app so that the device can notify your app when your accessory is connected.

When you create your Android app, there’s a few steps you need to take. First, not every Android-powered device supports the USB accessory APIs. In fact, the Android Open Accessory ADK is only supported by Android OS 3.1 and 2.3.4 platforms. To identify that your app has USB features, you need to include a <uses-feature> element in your manifest to declare that your application uses the android.hardware.usb.accessory feature.

 <uses-feature android:name="android.hardware.usb.accessory" />

Next, if you’re using the add-on library, add a <uses-library> element with com.android.future.usb.accessory for the USB accessory library.

<uses-library android:name="com.android.future.usb.accessory" />

and set the minimum SDK of the application to API Level 10. If you’re using theandroid.hardware.usb package then the <uses-library> isn’t necessary and you only need to set the minimum SDK to 12 .

Lastly, you’ll want your application to be notified when your accessory is attached. Specify an <intent-filter> and <meta-data> element pair for the android.hardware.usb.action.USB_ACCESSORY_ATTACHED intent in your main activity. Overall your manifest should look something like this:

<manifest ...>
    <uses-feature android:name="android.hardware.usb.accessory" /> 
    <uses-sdk android:minSdkVersion="<version>" />
    ...
    <application>
        <uses-library android:name="com.android.future.usb.accessory" />
        <activity ...>
            ...
            <intent-filter>
                <action android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED" />
            </intent-filter>
            <meta-data android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED"
                android:resource="@xml/accessory_filter" />
        </activity>
    </application>
</manifest>

The <meta-data> element references an XML resource file that includes the manufacturer, model and version you defined earlier in your Arduino sketch. Create an accessory_filter.xml resource file in the res/xml/ directory with a <usb-accessory> element to identify your accessory.

<resources>
    <usb-accessory model="CoolAccessory" manufacturer="My App Company" version="1.0"/>
</resources>

Now, when you connect your accessory to the device android will send an intent to open an appropriate application. The best part is that more than one application can respond to a given intent so multiple apps could optionally respond for the same accessory.

A co-worker was lucky enough to be invited to Google IO this year to promote our Lozzal Android app. That went great but while there, he snagged me one of the Android Open Accessory API and Development Kits (ADK)! Though he got to keep the sweet, sweet tablet which kills my idea of a home automation panel on the kitchen wall.

I’m pretty excited about the Android ADK, especially since it’s based on one of the Maker’s favourite platform—Arduino. If you’re not sure why this is so awesome, I suggest reading the Makezine post on Why Google Choosing Arduino Matters. I looked into building external devices with iOS a few moths back but quickly discovered Apple requires special chipsets–which can’t be easily obtained by little indy hardware developers like myself. Now, with an easily accessible platform and relatively cheap hardware components, I have lots of projects I want to dive right into.

For those that didn’t get one, here’s a quick demo of what the Android ADK hardware includes (Sorry about the audio, didn’t have a mic):

Included in the kit:

• A USB micro-controller board that is based on the Arduino Mega2560
• Android Accessory demo Shield
  • Joystick
  • 3 Buttons
  • 3 RGB LEDs
  • Temperature Sensor
  • Light Sensor
  • Capacitive touch sensor
  • 2 relays (24 VOC, 1A max)
  • 2 servos (though the board has three connectors)
• AC Adapter
• USB cable

Before creating this demo video I only spent about 10 min installing and setting up the Arduino software, Android ADK components and the DemoKit app on the phone. The initial setup is quite easy and you can be playing in minutes.

My only complaint (if you can call it that) is it would have been awesome to have more IO sensors, maybe IR (tv remote!), sound, or NFC on there. I guess it’s time I investigate all the other great Arduino shields and see what else I can do.

The basic idea is that you’ll share your desktop’s internet connection with your mobile device and then watch any traffic you want from your desktop. This involves a few simple steps:

1. Share your desktop’s internet connection.
2. Use the shared connection from your mobile device.
3. Sniff your traffic.

Sharing your desktop internet connection with your mobile device

In a Mac environment this is easy (and you should be able to do something similar in Windows). The only requirement is that you’ll need a wireless card (comes built-in to all modern Macs) and you’ll need a second internet connection such as the ethernet port (since your wireless card will be occupied sharing your connection). Once you have these, simply go to:

Apple Menu > System Preferences… > Sharing (under Internet & Wireless)

In this pane, click on the “Internet Sharing” text but don’t check the box yet. Select Ethernet from “Share your connection from” and then check the box next to AirPort in “To computers using”. Now check the box next to “Internet Sharing” on the left. It should look something like this:

This tells your mac to take the incoming Internet connection on your Ethernet port and send it out to other connected devices on your wireless AirPort port. If everything went well you’ll also notice the icon for your AirPort connection looks like a little arrow pointing up:

.

NOTE: This creates an OPEN network without a password that anyone can connect to. If you’re in an area where you would rather have a private network, select the “AirPort Options…” button in the sharing pane and adjust settings as necessary before you start up your shared connection.

Connecting to the your shared connection from your mobile device.

Now you can connect any Wi-Fi device to your shared network including other computers, iPhones, iPads, Android phones, whatever.

For an iOS device, simple go to:

Settings.app > Wi-Fi

and select your shared network (in my case “Jeffrey Sambells’s MacBook Pro”).

For Android you can find similar settings in Settings > Wireless & Networks > Wi-Fi Settings.

Once you’re connected to your shared Wi-Fi your mobile device will act as usual but all it’s traffic will be routing through your desktop computer–perfect for sniffing.

TIP: I find it’s often a good idea to enable Airplane mode on your mobile device so that you can be sure the requests will go over Wi-Fi instead of the cell network. To do this, just turn on Airplane mode in settings and then enable just Wi-Fi to connect to your shared connection.

Sniffing your mobile traffic.

Now comes the fun part. Since all the traffic from your device is now routing through your shared network, you can watch that network and see what’s going on.

I’ve found the easiest way to do this is using an app like HTTPScoop. If you set HTTPScoop watch your AirPort interface and then hit Scoop you’ll get a list of all the HTTP connections that occur to and from the mobile device:

and you can inspect each request for headers, raw data and the content of the request:

This is very useful for debugging you app’s requests and response as well as poking to see how other apps (including Apple’s built in apps) communicate with the network. Every wonder how map tiles load into the Maps.app? Or maybe you’re curious what info all your installed apps are sending out about you. Know you can find out.

If you need deeper details about the network traffic, there’s a number of other apps you can use that provide more details packet analysis.

Enjoy.

Typically you would extend any of the existing Android views or layouts and override various methods to achieve whatever you want to do:

package com.example;

import android.content.Context;
import android.util.AttributeSet;
import android.widget.LinearLayout;

public class MyLayout extends LinearLayout {

    public MyLayout(Context context) {
        super(context);
    }

    public MyLayout(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    @Override
    public void onFinishInflate() {
        super.onFinishInflate();

        // Your fancy code...

    }

}

Then in your layout XML files you can use these new objects by specifying the class path in the XML node:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/root"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:background="#fff">

    <com.example.MyLayout
        android:orientation="vertical"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" />

</RelativeLayout>

I’ve done this several times in my Android projects but I didn’t realize until recently that you can also specify your own attributes. To do so, you list what attributes are available in the attrs.xml file. For example, let’s say we want to create a text attribute for the MyLayout class. In res/values/attrs.xml you declare text as a string attribute that is styleable for the MyLayout class:

<?xml version="1.0" encoding="utf-8"?>
<resources>
     <declare-styleable name="MyLayout">
        <attr name="text" format="string" />
    </declare-styleable>
</resources>

Now you can add a new namespace (for example myapp) to your layout XML file and declare your own properties using that namespace:

<RelativeLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:myapp="http://schemas.android.com/apk/res/com.example"
    android:id="@+id/root"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:background="#fff">

    <com.example.MyLayout
        android:orientation="vertical"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content" 
        myapp:text="My Special Text String"/>

</RelativeLayout>

All that’s left to do is read and apply the attributes when your custom component is created in MyLayout(Context context, AttributeSet attrs):

package com.example;

import android.content.Context;
import android.content.res.TypedArray;
import android.util.AttributeSet;
import android.widget.LinearLayout;
import com.example.R;

public class MyLayout extends LinearLayout {

    private String mText;

    public MyLayout(Context context) {
        super(context);
    }

    public MyLayout(Context context, AttributeSet attrs) {
        super(context, attrs);

        TypedArray a = context.obtainStyledAttributes(attrs,
                R.styleable.MyLayout);
        CharSequence s = a.getString(R.styleable.MyLayout_text);
        if (s != null) {
            mText = s.toString();
        }
        a.recycle();
    }

    @Override
    public void onFinishInflate() {
        super.onFinishInflate();

        // Your fancy code suing the mText property...

    }   
}

This ability to customize your object from the layout XML files comes in especially handy when providing different layouts for different devices or orientations.

Of course, the disadvantage is that not all these links will work for all devices so its best to selectively display them depending on the mobile OS. That aside, the link structure is relatively simple.

iTunes (iOS) App Store

To link to the iTunes app store from any iOS device, or web browser, simply link to http://itunes.com/app/YourAppName for example http://itunes.com/app/FlipFrog. This will either launch the appropriate app store application (iTunes on your computer, App Store on an iOS device) or display the product page in the web browser.

Android

To link to the Android Market from an Android device, use the market:// protocol and your package name like this: market://details?id=your.package.name, for example market://details?id=com.lozzal. This will launch the Market application on an Android mobile device but unfortunately won’t do anything in a regular web browser (not even in Chrome).

If you like, you can also link directly to a market search page using market://search?q=pname:your.package.name (for example market://search?q=pname:com.lozzal) which may be useful if you have a number of different apps or want to provide similar alternatives.

BlackBerry

To link to the BlackBerry App World from a BlackBerry device or in any web browser, link to http://appworld.blackberry.com/webstore/content/your_app_id, for example http://appworld.blackberry.com/webstore/content/8160. This will display the detail page in the browser and provide the appropriate direct download links for the device.

 }wjiGtdpcNrAlBJZ

into a nice GeoPoint array list:

private List<GeoPoint> decodePoly(String encoded) {

    List<GeoPoint> poly = new ArrayList<GeoPoint>();
    int index = 0, len = encoded.length();
    int lat = 0, lng = 0;

    while (index < len) {
        int b, shift = 0, result = 0;
        do {
            b = encoded.charAt(index++) - 63;
            result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        int dlat = ((result & 1) != 0 ? ~(result >> 1) : (result >> 1));
        lat += dlat;

        shift = 0;
        result = 0;
        do {
            b = encoded.charAt(index++) - 63;
            result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        int dlng = ((result & 1) != 0 ? ~(result >> 1) : (result >> 1));
        lng += dlng;

        GeoPoint p = new GeoPoint((int) (((double) lat / 1E5) * 1E6),
             (int) (((double) lng / 1E5) * 1E6));
        poly.add(p);
    }

    return poly;
}

If you need an encoder (or other decoders) check out Mark McClure’s page here.

Release early, release often (sometimes abbreviated RERO) is a software development philosophy that emphasizes the importance of early and frequent releases in creating a tight feedback loop between developers and users.

— Wikipedia

To begin let me say that I’m both a web developer and a mobile application developer and I LOVE the “release early, release often” philosophy for web development. RERO allows me to make quick updates and improvements and add great new features for all my users. RERO is great. It’s awesome. It works and all the developers and users using the application are happy.

On the other hand, I loath RERO when it comes to SDK’s. It’s just a flawed and utterly terrible idea when there’s no clear and very accessible upgrade path for end users. As a web developer, I would not be happy if Microsoft decided to release IE9, IE10 and IE11 in the span of a year. My workload would more than triple, my user base would fragment and I’d be endlessly adding kludges for each new version. Unfortunately this is what’s starting to happen with the Android SDK and, as a mobile developer, I’m starting to get worried.

Android OS

To understand how RERO can harm adoption let’s take a look at the public Android SDK release schedule:

• API Level 2, Android 1.1 — February 2009
• API Level 3, Android 1.5 — April 2009
• API Level 4, Android 1.6 — September 2009
• API Level 5, Android 2.0 — October 2009
• • API Level 6, Android 2.01 — December 2009
• API Level 7, Android 2.1 — January 2009
• API Level 8, Android 2.2 — May 2009

Wow. In the past fifteen months (a little over a year) there have been seven public releases of different versions of the Android SDK. That doesn’t include carrier or manufacturer revisions with different user interfaces. It’s not that I’m not happy with the advancements of the SDK. They’re all wonderful and obviously the Android team is working really hard but there’s a problem. If we take a look at Google’s published Platform Versions stats and we can see where developers have a tough decision:

— Source

More than 50% of the Android install base is still using version 1.6 or less. As a developer what should I do? If I choose to take advantage of the latest and greatest SDK I get less than half of the devices! But still, the bigger problem is there is no clear and easy upgrade path for those bottom 50% to get the newer OS version. Neither of my Google supplied development phones (which are only a year old) can be upgraded without a lot of illicit hacking and deep developer knowledge.

The Android OS is in deep trouble until there’s an easy way to upgrade the OS on every device that runs it.

iPhone OS

Now contrast this situation with iPhone OS. Apple has been lambasted by developers for their tight control and strict NDA rules regarding beta releases but in comparison to the situation with Android isn’t it better? The NDA period allows the SDK to be flushed out, before it is “publicly” available so that there is one complete well oiled version that all developers can target across a large set of devices.

The public iPhone SDK release timeline is also much longer:

• SDK 1.0 – June 2007 (not public)
• SDK 2.0 – July 2008
• SDK 3.0 – June 2009
• • SDK 3.1 – September 2009
• • • SDK 3.1.2 – October 2009
• • • SDK 3.1.3 – February 2010
• SDK 3.2 – April 2010

Major iPhone releases are spaced a year apart (with a few minor releases in-between) allowing developers to actually develop and release an app before the SDK changes.

The iPhone has another big advantage and it solves the problem of distribution as I alluded to earlier. iPhone users use iTunes to sync their devices and add content. The process of syncing the device also checks for updates and allows all iPhone OS devices (iPhones, iPod Touches, iPads) to download the latests version of the OS. As a result the March 2010 iPhone Platform Versions stats look very developer friendly:

— Source

That’s only 5% of users who have NOT upgraded to at least 3.0 and 86% who are using one of the latest two (as of March) 3.1 minor versions. How great is that? Not only does 3.1 contain great features, I can actually use them and hit 86% of my users right away.

The Result

Recent trends are showing that Android OS based devices are passing Apple’s iPhone OS devices to be the No. 2 smartphone operating system in the U.S.—After RIM’s Blackberry OS:

• RIM’s BlackBerry OS at 36 percent;
• Android at 28 percent;
• Apple at 21 percent.

—source

I say as a developer I don’t care. The number of devices per OS is a great marketing number for Google and Apple to fight over but as a developer—who wants to get the most out of the SDK—I care about the version of the OS on the devices. If I want to use the latest and greatest SDK’s I’ll take Apple’s 80% of 21% over Google’s 30% of 28%.

Now all I have to do is call setFitTextToBox(true) on the TextFitTextView after allocation. Enjoy!

public class TextFitTextView extends TextView {

    static final String TAG = "TextFitTextView";
    boolean fit = false;

    public TextFitTextView(Context context) {
        super(context);
    }

    public TextFitTextView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public TextFitTextView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    public void setFitTextToBox( Boolean fit ) {
        this.fit = fit;
    }

    protected void onDraw (Canvas canvas) {
        super.onDraw(canvas);
        if (fit) _shrinkToFit();
    }

    protected void _shrinkToFit() {

        int height = this.getHeight();
        int lines = this.getLineCount();
        Rect r = new Rect();
        int y1 = this.getLineBounds(0, r);
        int y2 = this.getLineBounds(lines-1, r);

        float size = this.getTextSize();
        if (y2 > height && size >= 8.0f) {
            this.setTextSize(size - 2.0f);
            _shrinkToFit();
        }

    }
}