Android Wear Tests

So there’s a hackathon going on over the next 48 hours, revolving around wearable tech and how it can be used to further certain corporate goals. I’m poking around with an Android Wear device, the Moto 360, to see how it stacks up. There’s currently someone sitting across the room from me futzing with a Google Glass headset (looks kind of stupid).

A few first impressions:

  • The device itself is pretty slow.
  • The initial pairing can fail frustratingly, because Android seems to have problems when you don’t reboot after turning Bluetooth on, even on a Nexus phone. Also, if you accidentally pair the watch using the normal Bluetooth device selector, then the Google Wear app will fail to pair with it, and fail to realize that you’ve already paired.
  • There’s a weird Bluetooth wireless debugging mode, that still requires you to plug your phone into a USB port then Bluetooth pair the Wear device to the phone.
  • The edit, compile, debug cycle is incredibly slow; pressing run in Android Studio leads to a delay time of up to a minute or more waiting for the app to make it to the watch (so the only way to really do this is using an accelerated virtual device, on x86).
  • Android Studio has gotten a lot better since the betas I tried. (The fun part is when you hear someone sitting across the room at the hackathon complaining about how much it crashes, as if he would like to return to the world of Eclipse? Reminds me of Louie CK’s rant about everything being awesome and nobody being happy.
  • Initial Gradle builds are still really slow, though. It’s totally killing my processor.


  • The Salesforce Android SDK is not published to Maven Central, instead being distributed using npm (the Node package manager) and/or needs to be built from github sources. This makes zero sense. The SDK should be a versioned, precompiled, signed binary JAR file checked into Maven, and easily importable into any sensible Java IDE.
  • I’m noticing myself checking my wrist a lot more. When washing the dishes, the notification was forwarded to the watch, which was actually kind of convenient, I must say.

In order to develop apps directly for the Android Wear device, you have to set up a weird multi-hop debugging session that connects you to the Wear device through your phone. It would be a nice leap forward if the watches themselves had WiFi, or you could directly debug using the Bluetooth on your development computer (i.e. Macbook).

The weird multihop setup looks something like:

Dev computer --(wired)--> Smartphone --(Bluetooth)--> Android Wear device

And to make those connections, once you set up the Android Wear device, and smartphone app to allow Bluetooth debugging, you have to use some adb magic:

$ adb forward tcp:4445 localabstract:/adb-hub
$ adb connect localhost:4445
connected to localhost:4445
$ adb devices
List of devices attached 
localhost:4445	device

Then Android Studio will finally recognize the device:


Anyways, the Moto 360 itself is pretty interesting:

shell@minnow:/ $ cat /proc/cpuinfo                                             
processor	: 0
model name	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 398.74
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: minnow
Revision	: 0000
Serial		: 0000000000000000

With 512MB of RAM and about 4GB of flash storage, it’s pretty amazing how far we’ve come.

shell@minnow:/ $ cat /proc/meminfo
MemTotal:         511156 kB
MemFree:           85236 kB

shell@minnow:/ $ df
Filesystem               Size     Used     Free   Blksize
/dev                   249.6M    24.0K   249.6M   4096
/sys/fs/cgroup         249.6M    12.0K   249.6M   4096
/mnt/asec              249.6M     0.0K   249.6M   4096
/mnt/obb               249.6M     0.0K   249.6M   4096
/system                252.0M   237.7M    14.2M   4096
/cache                 248.0M   240.0K   247.7M   4096
/data                    2.9G   178.3M     2.7G   4096
/pds                     3.9M    40.0K     3.8M   1024
/customize              84.6M    44.0K    84.5M   4096
/mnt/shell/emulated      2.9G   178.3M     2.7G   4096

The feeling I get, is that they need to figure out how to get WiFi and 3G built into those watches, and cut the weird Bluetooth smartphone tethering.

Compiling the Salesforce SDK

Ignore all of this stuff. The process of getting started with the SDK, and adding it to an existing Android project, is completely undocumented.

If you check out the Salesforce Android SDK via Github, and then run, which grabs all the other dependencies it needs, you then to build a compiled JAR version of the SDK:

  1. Go to the tools/ folder from the SDK root folder
  2. Run: tools/ -v -b SalesforceSDK

Adding “-v” lets you see the verbose output, which is good, because otherwise the only output you see is “Building project SalesforceSDK”, which isn’t particularly enlightening.

And then Gradle throws up on you:

*                                                                              *
* TOP /Users/nuketlua/AndroidStudioProjects/SalesforceMobileSDK-Android
* Building project SalesforceSDK
*                                                                              *
Updated file ./proguard-project.txt
:libs:SalesforceSDK:copyDebugLint UP-TO-DATE
:libs:SalesforceSDK:preBuild FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':libs:SalesforceSDK:preBuild'.
> failed to find Build Tools revision 21.1.1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.


Total time: 1 mins 40.505 secs

Compiling the Salesforce SDK (Second Try)

An alternative mechanism to building the thing could be to open the SalesforceSDK project folder in Android Studio or Eclipse, and to run the “SalesforceSDK” Gradle target. This way, you’ve got all of the nice SDK management features of the Android Developer Tools, and hopefully all of the CLASSPATH stuff gets set up correctly for you too. Who knows?

Unfortunately, the Salesforce SDK wants Android API level 21. I’ve got level 22, but it should still build, right?


Maybe they need a decent Continuous Integration system to help them out here? But I’m sure I’m not the only one seeing this problem.

I’d rather not blow the disk space on it, but the easiest thing to do is have Android Studio download and install the Android level 21 files.


Oh wait, but that’s not enough either, they want the level 21 build tools as well. What a PITA.

Once those the old SDK and old SDK tools are installed, Android Studio will index the entire project, and stop complaining.

Now you can crack open the Gradle tab in Android Studio, and try assembling the libs you’ll want to use for development.


Not Compiling the Salesforce SDK (Third Try)

There’s a sample app at Github, here — — which has some extra bits that set up and download a prebuilt JAR file. NOT THAT ANYONE EXPLICITLY EXPLAINS THIS.

So if you’re trying to add the Salesforce SDK to an existing app, you have to add the extra bits yourself. Have fun.

Also, after trying it, the sample doesn’t work. Way to sell us on your API, guys.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.