1. 1

2. 2
Building next-gen
Android library
with Gradle
Anton Rutkevich
Android developer

3. 3
About me
3+ years of Android development
Mobile game-dev experience
At Yandex:
Android development
Continuous Integration

4. 4
Old-style library projects
The past, the present…

5. 5
What’s wrong?
• Hard to update
• Hard to distribute
• Eclipse, eclipse…

6. 6
Gradle &
The New Build System
The present, the future…

7. 7
Gradle - build automation evolved
• Build scripts on Groovy
• Flexible build setup
• Runs everywhere (Java required)
• Dependency management

8. 8
Dependency management
• Maven artifacts
• Local artifacts
• Library projects
dependencies {
compile ‘com.google.code.gson:gson:2.2.4’
compile fileTree(dir: ‘libs’,
include: ‘*.jar’)
compile project(‘:my-library’)
}

9. 9
The New Build System
• Brings Gradle features to Android builds
• Provides Android Studio integration

10. 10
.aar format
• Zip archive
• Structure is similar to old-style library project
• /AndroidManifest.xml
• /classes.jar
• /res/
• /R.txt
• /assets/
• /libs/*.jar
• /jni/<abi>/*.so
• /proguard.txt

11. 11
A good library

12. 12
Self sufficient
• plain java jar-file ?
• maven plain java jar?
• maven Android jar ?
- dependencies
+/- obfuscation
- AndroidManifest.xml

13. 13
Friendly
• Does not create conflicts with other
libraries

14. 14
Stable
• Behavior does not change over time

15. 15
Building next-gen
Android library
The right way

16. 16
Key components
/AndroidManifest.xml
/classes.jar
/res/
/R.txt
/assets/
/libs/*.jar
/jni/<abi>/*.so
/proguard.txt

17. 17
Resources
Lint will warn you!
android {
resourcePrefix 'mylib_'
}
Use resource prefix for library resources

18. 18
Obfuscation. DON’Ts for library
-repackageclasses ‘’
-allowaccessmodification
// hidden -> public
a.class
b.class
…
a.class
b.class
…
first.jar second.jar
error:
duplicate class

19. 19
Obfuscation. Rules for users
Will be packaged into aar
defaultConfig {
consumerProguardFiles ‘pro-consumer.txt’
}

20. 20
Dependencies.
Stable vs dynamic versions
Stable versions give stable builds
dependencies {
// 1.6.0 only
compile ‘com.squareup.okhttp:okhttp:1.6.0’
// Latest version
compile ‘com.squareup.okhttp:okhttp:+’
}
Dynamic versions do not require redeploy
Use stable versions for library dependencies

21. 21
Dependencies. Maven only!
What’s wrong with
local jars?
libs/
lib-1.0.jar
libs/
lib-1.0.jar
first.aar second.aar
In extreme cases –
use jarjar tool error:
duplicate class

22. 22
Manifest. Static values
Will be copies into app’s manifest file ‘as is’.
<uses-permission android:name="android.permission.INTERNET"
/>
<application>
<activity android:name="com.my.app.SomeActivity”/>
</application>
Include required values only!

23. 23
Manifest. Dynamic values 1
defaultConfig {
manifestPlaceholders
= [ userAppPackage: "${packageName}” ]
}
<uses-permission
android:name="${userAppPackage}.LIB_PERMISSION" />
Library’s build.gradle
Library’s AndroidManifest.xml

24. 24
Manifest. Dynamic values 2
<uses-permission
android:name="${packageName}.LIB_PERMISSION" />
Will give
in library’s aar AndroidManifest.xml

25. 25
Manifest. Dynamic values 3
Library’s aar AndroidManifest.xml
Application’s build.gradle
<uses-permission
android:name="${packageName}.LIB_PERMISSION" />
defaultConfig {
packageName = "com.my.app”
}

26. 26
How to use it
depending on your build system

27. 27
Case 1. Using Eclipse, etc
1. Unzip aar
2. Attach as library project
3. Add classes.jar (and libs/) to classpath
4. Add native libraries
5. Add proguard entries
6. …

28. 28
Case 2. Using Gradle & local aar
project-folder/
build.gradle
repo/library-1.0.aar
repositories {
flatDir { dirs ‘repo’ }
}
dependencies {
compile ‘com.company:library:1.0@aar’
}

29. 29
Case 3. Using Gradle & Maven
dependencies {
compile ‘com.company:library:1.0’
// or
compile ‘com.company:library:1.0@aar’
}

30. 30
What’s next?

31. 31
Uncovered topics
• Maven Central publication
• Multiple library variant generation
• Native libraries
• …

32. 32
Thank you for your attention!
Anton Rutkevich
antonrut@yandex-team.ru