Android Wear Tests

12 June 2015
Tech

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: {crayon="false"} 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: {crayon="false"} $ 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: {crayon="false"} 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. {crayon="false"} 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. ::: {style="text-decoration: line-through"} If you check out the Salesforce Android SDK via Github, and then run install.sh, 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/sdk.sh -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: {crayon="false"} ******************************************************************************** ***TOP /Users/nuketlua/AndroidStudioProjects/SalesforceMobileSDK-Android *Building project SalesforceSDK ********************************************************************************** Updated project.properties Updated local.properties Updated file ./proguard-project.txt Download https://repo1.maven.org/maven2/com/android/tools/build/builder/1.0.0/builder-1.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/lint/lint/24.0.0/lint-24.0.0.jar Download https://repo1.maven.org/maven2/net/sf/proguard/proguard-gradle/5.1/proguard-gradle-5.1.jar Download https://repo1.maven.org/maven2/com/android/tools/sdk-common/24.0.0/sdk-common-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/common/24.0.0/common-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/build/builder-test-api/1.0.0/builder-test-api-1.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/ddms/ddmlib/24.0.0/ddmlib-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/build/manifest-merger/24.0.0/manifest-merger-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/build/builder-model/1.0.0/builder-model-1.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/sdklib/24.0.0/sdklib-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/lint/lint-checks/24.0.0/lint-checks-24.0.0.jar Download https://repo1.maven.org/maven2/net/sf/proguard/proguard-base/5.1/proguard-base-5.1.jar Download https://repo1.maven.org/maven2/com/google/guava/guava/17.0/guava-17.0.jar Download https://repo1.maven.org/maven2/com/android/tools/layoutlib/layoutlib-api/24.0.0/layoutlib-api-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/dvlib/24.0.0/dvlib-24.0.0.jar Download https://repo1.maven.org/maven2/com/android/tools/lint/lint-api/24.0.0/lint-api-24.0.0.jar :libs:SalesforceSDK:compileLint :libs:SalesforceSDK:copyDebugLint UP-TO-DATE :libs:SalesforceSDK:mergeDebugProguardFiles :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. BUILD FAILED 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 --- https://github.com/developerforce/WearablePack-AndroidWear/blob/master/samples/QuoteDiscountApproval/build.gradle --- 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.

← Previous
FastFerment Rolling Stand
Next →
Raspberry Pi Notes