Note this post has been published on Zebra developer portal, if you’ve any comment, probably best to post them over there.
Working in Android Studio you can notice that every project contains a
local.properties file with at least a couple of properties containing the path for Android SDK and Android NDK.
Android Studio populates this information when it creates the project based on the
ANDROID_HOME environment variable. If this variable is not present in your system Android Studio will find the correct path in other ways, but having
ANDROID_HOME setup correctly is a really good idea, see the note at the end of this short post.
Given that I usually have in my
build.gradle file a reference to Zebra’s EMDK, look like a good idea to use
sdk.dir instead than hardcoding the path (like I’ve done for a too much long time) given that the EMDK resides in Android SDK’s add-ons folder.
So, my gradle files now includes:
Properties properties = new Properties() properties.load(project.rootProject.file('local.properties').newDataInputStream()) def sdkDir = properties.getProperty('sdk.dir')
so that I can the use the sdkDir variable like:
provided fileTree(include: ['com.symbol.emdk.jar'], dir: sdkDir+'/add-ons/addon-symbol_emdk-symbol-23/libs/')
Much cleaner and nice :-)
A note on
It’s not usually a good idea to include in your revision system the
local.properties file because this contains information… «local»… to your machine.
Imagine that you’re sharing a project with a colleague or with a remote CI build server. In this case everybody will have the Android SDK (and the Zebra’s EMDK that resides in the SDK add-ons) in a different folder.
The best option in this case is to avoid to share the
local.properties file and have the
ANDROID_HOME environment variable correctly setup so that the build works correctly on every machine.
local.propertiesis not available, Gradle will use
local.propertiesis available, Gradle will use this file having a wrong
sdk.dirset and fail.