gradle and your android wearable projects

Copyright © 2014 CommonsWare, LLC

Gradle and Your Android

Wearable Projects


One APK To Rule Them All

● One APK, regardless of device type● Original Android development vision● Still works for conventional apps... within

reason● Starts to break down as you go beyond

traditional device types into things like wearables


Presentation Terminology

● Device● Runs a mainstream mobile operating system, designed for

multiple form factors– Today: Android, Tizen– Tomorrow: who knows?

● Accessory● Runs some dedicated OS● Most/all app logic resides on tethered phone or tablet

● Hybrid: dedicated OS, but apps run on wearable


Terminology Examples

● Device● Google Glass● Omate TrueSmart● I'm Watch● Samsung Gear 2 / Gear 2 Neo

● Accessory● SONY SmartWatch/SW2● Samsung Gear Fit● Fitbit

● Hybrid● Pebble


Wearables: Why Multiple APKs?

● CPU architecture● Distribution channel (e.g., no Play Services)● Per-device libraries

● Licensing● Bulk

● API level● Entry points and security● Resources


A Specific Wearable Scenario

● Main App

● Phones, tablets, modern Android wearable devices (Omate TrueSmart)

● SONY SW2

● Dedicated libraries● I'm Watch

● Workarounds where new API options are missing


Other Possible Scenarios

● Samsung Gear Fit● Dedicated libraries, dedicated distribution channel

● Google Glass● New UI backed by common code● Dedicated distribution channel

● Pebble● Separate C language project for on-device portion of app● Android project for the on-phone tethered side


Classic Solution: Library Project

● Common materials in the library● Java code● Standard resources

● Per-device apps that leverage the library● Works, but a bit clunky

● Future: relegated to cases where library needs to be used by totally disparate apps


Gradle Solution: Product Flavors

● One Project, N Flavors● Additions to manifest● Alternative Java classes (one per flavor)● Additional or replacement resources

● Each Flavor Generates Own APK● Unique package name, but independent from your

R classes

● Other techniques available as well


What Is Gradle?

● Role: Build Automation● Think Ant plus Maven plus other goodness

● Implementation: It's Groovy● DSL implemented in Groovy, blending declarative

structures and full-blown scripting

● Provider: Gradleware● Open source, Apache licensed


Gotta Getta Gradle

● Direct Download● The Gradle Wrapper

● gradlew script and related files in a repo● Designed for boostrapping

– Running the script does a Gradle build– Running the script installs Gradle itself if development

machine does not have it● Actual Gradle comes from wherever script says

– Net: only use this if you REALLY trust the source


The Basic Gradle Process

● Write build.gradle File● Describes sources and results● Same role as build.xml for Ant, etc.● Usually in root of project directory

● Run gradle / gradlew● Supply task name as command-line parameter● Optional: IDE integration


Escape From Eclipse

● Exporting a build.gradle● Export wizard in Eclipse through current ADT● Choose project(s) to export● Get build.gradle files generated for you

– A bit more complicated than the normal build.gradle starting point due to legacy project structure

● NOTE: Not Kept in Sync!● Project changes in Eclipse do not mirror to build.gradle!


build.gradle: High-Level View

● buildscript {}● Describing dependencies for running the build● Key: Android plugin

● apply plugin: 'android'● dependencies {}

● Describing compile-time dependencies (JARs, etc.)

● android {}● Tailoring what Android builds for you


Tons o' Tasks

● assemble*● Compiles APK for you● Tied to “build type” (assembleDebug, assembleRelease are default)

● install*● Installs APK on device for you, after assembly● Only installDebug works by default

– installRelease requires configuring your signing keys


Project Structures, Old and New

● Original Recipe● src/, res/, assets/ in top-level project directory● libs/ also in top-level project directory

● New Project Structure● src/, res/, assets/ in subdirectory

– main/ by default– Others by “build type” or “product flavor”

● libs/ remains in top-level directory– Or gone, replaced by artifacts


Pieces of New Project Structure

● Source Sets● Build Types● Product Flavors● Build Variants


Source Sets

● Gradle Construct for Organizing “Source”● In Android's case, includes resources and assets

● Vision● Have one main/ source set with most of your code● Have alternatives in other source sets, used

conditionally– Resources, assets: can replace main/ source set– Java: cannot replace main/, can only add


Build Types

● Android Plugin Construct for Describing Output Variations● Two build types come default: debug and release

● Build Types Configurable● Project properties in build.gradle● Source sets

● Define Others As Needed● Smoke tests, debuggable-release builds, etc.


Product Flavors and Build Variants

● Product Flavors● Android plugin construct for different deployment

variations● None defined by default, can create your own

● Build Variants● Cross product of build types and product flavors● Drive task names (assembleSonyDebug) and

results


Quick Dependencies Overview

● Sub-Projects● JARs

● compile fileTree(), sub-projects, or replace with artifacts

● AARs● Compiled Android library projects

● Artifacts● Maven Central and/or your own repositories● JARs and AARs supported


Specific Scenario Build Script

● One Project● Three Product Flavors

● standard● sony● imwatch


Flavor-Specific Changes

● SONY● sonyCompile● Hand-rolled local artifacts for SONY libraries

– Long-term: hope they publish to Maven Central or own artifact repository

● I'm Watch● Resources


What You Get

● Three APKs● Two for Play Store distribution (standard and

SONY)● One for dedicated distribution (I'm Watch)

● In general, one APK per build variant● For release = one APK per product flavor


Gradle Pros...

● One build system to rule them all● ...in the fullness of time

● Much more powerful than Ant for command-line builds

● More flexible options for code reuse● Richer build script syntax


...and Cons

● Android Studio still a work in progress● No Eclipse support yet● Gradle for Android still has its own bugs and

limitations● Breaking changes with updates● AAR packaging far from universal

● ...let alone being artifacts for easy consumption


Where To Learn More

● http://tools.android.com/● Home of the Android tools team● Information on Gradle for Android, Android Studio

– Note: much is out of date!

● http://gradle.org● For general Gradle information

● http://gradleware.com● Firm behind Gradle's development, offering training and consulting

● http://commonsware.com/Android● Some book by some balding guy● Several chapters on Gradle for Android

gradle and your android wearable projects

Technology