Gradle build and specifically aar example project

1,208 views
Skip to first unread message

Manfred Moser

unread,
May 29, 2013, 4:15:00 PM5/29/13
to adt...@googlegroups.com
Hi!

I am starting to implement aar support for the Android Maven Plugin. In order to do so I would like to have some sort of Gradle build example that demonstrates creation of a simple aar and maybe another example that is a multi module build that creates an aar in one module and then reuses it in an apk..

Does such a thing already exists or do I have to slap something together myself? 

Specifically I going to need to figure out things like

naming of the jar with the class files inside the aar
other naming conventions
and other things I should be aware of 

At this stage I assume you should be able to publish a aar to a repository and then use it as a dependency in Gradle like so (not yet documented on http://tools.android.com/tech-docs/new-build-system/user-guide which is why I am asking) 

dependencies {
  compile group: 'com.simpligility.example', name: 'gradle-aar-example',
                  version: '1.0', ext: 'aar'
}

Correct?

Any more hints and ideas? 

thx 

manfred

Xavier Ducrohet

unread,
May 29, 2013, 8:19:46 PM5/29/13
to adt...@googlegroups.com
At the bottom of this page: http://tools.android.com/tech-docs/new-build-system
you'll find a zip with samples for 0.4.1

There are several samples with libraries, but the "repo" one is the one using an intermediary repository to push a library and have the app consume it.



--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

Manfred Moser

unread,
May 30, 2013, 9:49:56 AM5/30/13
to adt...@googlegroups.com
Thanks... thats a good start.. 


On Wed, May 29, 2013 at 4:24 PM, Malachi de AElfweald <mal...@playhaven.com> wrote:
Still playing with it, but I was curious about the .aar structure as well.

malachi@beast$ jar -xvf androidlib-debug.aar
 inflated: classes.jar
 inflated: AndroidManifest.xml
 inflated: R.txt
  created: res/
  created: res/layout/
 inflated: res/layout/splash.xml
  created: res/drawable-xhdpi/
 inflated: res/drawable-xhdpi/ic_launcher.png
  created: res/values/
 inflated: res/values/values.xml
  created: res/drawable-hdpi/
 inflated: res/drawable-hdpi/ic_launcher.png
  created: res/drawable-mdpi/
 inflated: res/drawable-mdpi/ic_launcher.png
  created: res/anim/
 inflated: res/anim/splash.xml
  created: res/drawable/
 inflated: res/drawable/playhaven.png
  created: assets/


malachi@beast$ jar -xvf classes.jar
  created: META-INF/
 inflated: META-INF/MANIFEST.MF
  created: org/
  created: org/eoti/
  created: org/eoti/gradle/
  created: org/eoti/gradle/test/
  created: org/eoti/gradle/test/gradletest3/
  created: org/eoti/gradle/test/gradletest3/androidlib/
 inflated: org/eoti/gradle/test/gradletest3/androidlib/Splash.class

Xavier Ducrohet

unread,
May 30, 2013, 2:13:43 PM5/30/13
to adt...@googlegroups.com
Yeah that's basically it. It's a zip file with the content flat in it:

  • classes.jar
  • res/
  • assets/
  • AndroidManifest.xml
  • R.txt
  • proguard.txt
  • libs/*.jar  (local jar dependencies)
  • aidl/ (aidl imports)
Not clearly defined yet but will also go in at some point:
  • native .so libs (per abi) (probably coming next)
  • native headers and static libs (this will take longer)
  • lint.jar for custom lint rules for your library.

Manfred Moser

unread,
May 30, 2013, 3:30:05 PM5/30/13
to adt...@googlegroups.com
so you are allowing libs .. that seems like a terrible idea.. would it not be better to rely on these dependencies to be declared in the build file and deployed to the repository as usual and then downloaded? 

That way you could support transitive dependencies better and also e.g. have transitive dependencies that are native files or other aar files.

Including the jar files locally without any identifier seems like asking for trouble in terms of being able to manage the dependency graph of a larger application ..

manfred

Xavier Ducrohet

unread,
May 30, 2013, 3:32:39 PM5/30/13
to adt...@googlegroups.com
oh it's a terrible idea indeed. but like the rest of Gradle, if you want/need to use local jar you should be able to.

This is definitively not the recommended way to do this, and we may actually display some warning so that people are aware about what they are doing.

Manfred Moser

unread,
May 30, 2013, 3:37:23 PM5/30/13
to adt...@googlegroups.com
So the gradle build will will deploy a pom file with the aar that has the dependencies if they are declared correctly? If so thats fine.. 

+100 for a warning .. 

Or even better a build breakage that warns and suggest to use some sort of override flag .. if you really know what you are doing only .. along the lines of .. you really want to user yourself and your users into the foot.. here is how to do it


manfred

Malachi de AElfweald

unread,
May 30, 2013, 3:48:02 PM5/30/13
to adt...@googlegroups.com
I agree.  Being able to is fine. Default should be the recommended way.


You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/t3bubNkssRo/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--

Thank you,
Malachi de Ælfweald
Sr. SDK Developer - Android
Reply all
Reply to author
Forward
0 new messages