Larry Schiefer @ljschiefer Exploring SDK Add-ons for Android Devices 

About Me * CTO, co-founder of HiQES LLC * Over 16 years developing embedded / mobile device software * Extensive experience throughout software stack, numerous operating systems * Android development since first AOSP * Android native dev / debug, before NDK * Lead architect and dev on 3 custom Android platforms * Experienced trainer 

Overview * OEM magic: the SDK add-on * What can a SDK add-on do? * App development: how to get and use one * Platform development: sample platform add-on * Extra add-on: how to create and use them * Q&A 

OEM Magic: The SDK Add-on * Platform specific functionality * Enable devs to take advantage of value-added features * Extends the core Android feature set * Features sometimes adopted by AOSP * Special shared library on OEM device * Integrates with ADT or Android Studio 

Hang on just one second… * …don`t OEMs have to comply with compatibility requirements and not modify the Android API?! * Yes, according to the CDD…but this is different! 

Android CDD * Android Compatibility Definition Document (CDD) * Establishes rules for OEMs in order to use Android name * Hardware and software requirements * Applies to specific Android versions * Continues to evolve * Section 3.6 prohibits altering the Android public APIs: Android follows the package and class namespace conventions defined by the Java programming language. To ensure compatibility with third-party applications, device implementers MUST NOT make any prohibited modifications (see below) to these package namespaces:
 
 java.*
 javax.*
 sun.*
 android.*
 com.android.*
 
 Prohibited modifications include:
 Device implementations MUST NOT modify the publicly exposed APIs on the Android platform by changing any method or class signatures, or by removing classes or class fields.
 Device implementers MAY modify the underlying implementation of the APIs, but such modifications MUST NOT impact the stated behavior and Java language signature of any publicly exposed APIs.
 Device implementers MUST NOT add any publicly exposed elements (such as classes or interfaces, or fields or methods to existing classes or interfaces) to the APIs above. * SDK add-on uses OEM namespace 

What can a SDK add-on do? * Just about anything! * Ex: Google`s APIs * Ex: HTC Sense UI * Ex: HTC lEchoz display (HDMI) * OEM bears additional responsibility * Security risks * Unintended platform side-effects * Unintended app side-effects 

App Development * Where do I find them? * Depends on the OEM HTC: http://developer.htc.com Motorola: http://developer.motorola.com Samsung: http://developer.samsung.com * Not always easy to find! * Not always straightforward to setup! * Not all SDK add-ons created equal * Some provide emulators + APIs * Some provide just emulators 

Setup Example: HTC Sense * Load SDK Manager * Tools → Manage Add-on Sites… * User Defined Sites * http://dl.htcdev.com/apis 

Setup Example: HTC Sense (cont) * Sort by Repository * Select HTC API and SDK and install 

Where is the Add-on? * SDK Manager places it under the SDK directory * Stored hierarchically under the ladd-onsz subdirectory 

Platform Development * Integrated into the platform runtime * Defined in the device/vendor tree * Be careful in the core framework! * Can include JNI component(s) * Source tree must contain: * Makefiles * Permission declaration * SDK Add-on details * The library source(s) (private) 

Platform Development – AOSP * Based on AOSP, http://source.android.com * Beyond the scope of this class * Get familiar with the build system * Command line, make based * Very extensible, but not much documentation 

Makefiles * Define special make variables * PRODUCT_SDK_ADDON_NAME * A logical name for your module (library) * PRODUCT_SDK_ADDON_COPY_FILES * A list of special files to be copied into the SDK itself as part of the add-on * PRODUCT_SDK_ADDON_COPY_MODULES * A mapping of the Java library FQN to device filesystem * PRODUCT_SDK_ADDON_STUB_DEFS * A file name which contains public APIs from the library * PRODUCT_SDK_ADDON_DOC_MODULES * The name of the module to auto-generate documents (same as ADDON_NAME) * Modify standard make variables * PRODUCT_PACKAGES * A list of libraries or apps to be included the device build * PRODUCT_COPY_FILES * A list of special files to be copied to the device filesystem 

Add-on Permissions * Handled both on device and build machine * Uses special files to define accessible APIs and the library * On device * Uses XML lpermissionsz file * Copied via PRODUCT_COPY_FILES * Sample contents: * On build machine * Declares all APIs (classes) publicly exposed * File specified in PRODUCT_SDK_ADDON_STUB_DEFS * Simple format +com.hiqes.android.utility_library.* 

Add-on Details * Manifest describes the SDK Add-on version, API level, etc. * Included in the SDK add-on * Specified via PRODUCT_SDK_ADDON_COPY_FILES * Can included hardware.ini and skins * manifest.ini declares API level, version, description, etc. # Name and vendor of the add-on. This with the vendor and API uniquely id it. # Mandatory character set: a-z A-Z 0-9 _.- name=HiQES Utility Add-on vendor=HiQES LLC description=Utilities for the platform # version of the Android platform on which this add-on is built. api=15 # revision of the add-on. This must be a strict integer. revision=1 # list of libraries, separated by a semi-colon. libraries=com.hiqes.android.utility_library # details for each library. format is: # =.jar; com.hiqes.android.utility_library=utility_library.jar; HiQES utility library 

Add-on Sources * Structured in the usual way * Built via Android.mk LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_SRC_FILES := \ $(call all-subdir-java-files) LOCAL_MODULE_TAGS := optional LOCAL_MODULE:= com.hiqes.android.utility_library include $(BUILD_JAVA_LIBRARY) * Be sure to build Javadoc, too! * Built via Android.mk include $(CLEAR_VARS) LOCAL_SRC_FILES := $(call all-subdir-java-files) $(call all-subdir-html-files) LOCAL_MODULE:= utility_library LOCAL_DROIDDOC_OPTIONS := com.hiqes.android.utility_library LOCAL_MODULE_CLASS := JAVA_LIBRARIES LOCAL_DROIDDOC_USE_STANDARD_DOCLET := true include $(BUILD_DROIDDOC) 

Building * Part of your product definition * Use a special make rule to build: make PRODUCT--sdk_addon * The add-on is pre-zipped for you, located in: out/host//sdk_addon * Contains a stub jar, emulator images, etc. from the build files 

Packaging – Make it Available * SDK Manager can use HTTP or local file * Add-on uses XML with simple schema *  Defines Add-on name, vendor, etc. like embedded manifest.ini *  Defines files included in the add-on HiQES Utility SDK 10 hiqes HiQES LLC hiqes_utility HiQES Platform Utility SDK 2 HiQES Platform Utility SDK http://www.hiqes.com e9f4fd1a397e1660783c03fc2d939cee9ee54110 sdk/hiqes_utility_library-10_r02.zip com.hiqes.android.utility_library

Additional Items * Security * Use custom permissions * Enforce existing and new permissions * Be wary of data usage/persistence * Side effects * Must be stable * Must be efficient * Use proper threading, locking 

Demo: Custom Add-on for Emulator * Custom add-on to read PID of SystemServer 

Special SDK Add-ons: Extras * Extras are 3rd party components * Not necessarily tied to a platform * EX: Android Support Library * EX: Google Play Services * You can specify architecture and OS, if needed 

What can an SDK Add-on Extra Contain? * Typically contains libraries * Sources * EX: Android Support Library * Documentation! * TIP: Use Javadoc to do the heavy lifting! * Samples 

Add-on Extra Packaging * Similar to the platform SDK add-on XML format * Use the tag instead of * Provide a tag to specify where it goes locally hiqes HiQES LLC HiQES Android Helper APIs 1 utilities HiQES Android Helper APIs Library http://www.hiqes.com/ 7c8958d8c13c1837ca865b7e9c6ba13ab59abe20 sdk/hiqes_helper_apis-8_r01.zip 

Where are SDK Extras stored? * Under the SDK tree, like add-ons! * Stored in the lextrasz directory * Hierarchical, by vendor * Uses the for placement under the vendor tree 

How do I use extras? * Short answer: it depends! * Typically static libs are manually copied into your project * Create a llibsz directory in your project * Copy the jar file into the llibsz directory * Update build path to include the llibsz directory * Sometimes extras can be demonstrated/used in-place * EX: Google webdriver, Intel HAXM installer * No built-in support for Eclipse Android Library projects 

Questions? 

Credits The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License. Android SDK Documentation http://developer.android.com/sdk/index.html http://developer.android.com/sdk/exploring.html Android Open Source Project (AOSP) http://source.android.com Github Repository of Samples https://github.com/hiq-larryschiefer/android-device-ballard.git https://github.com/hiq-larryschiefer/android-DemoPlatInfo.git HiQES Pre-built Android Add-ons (for Android SDK Manager) http://developer.hiqes.com/android/addon.xml Android Compatibility http://source.android.com/compatibility/index.html Presentation http://copy.com/g74rZllWktiu 

Contact Information [email protected] @ljschiefer http://www.hiqes.com