Android Jar vs Android Libraries

[Ievgenii Nazaruk]

Hi all,

For some time now I've been using Android Jars, meaning a simple java
jar file that references android.jar. For this I've used some eclipse
project trickery and some simple custom ant files. This allows to use
some Android specific functionality which would not be available if
from plain java jars.

When I was starting with Android there was a very limited support for
Android Libraries. One of the major limitations was inability to
reference Android Library from another Android Library. Now this and
other issues have been fixed, and Android Libraries were improved
quite a bit over the time.

I personally prefer to use Android Jars whenever possible. But when
I'm using UI or need resources I'm going with Android Library. The
distinction was quite logical for me. But recently I've been pointed
out that it's just easier to use Android Libraries for all cases. The
reasoning is simple: Android Libraries are supported and tested by
Google. And Android Jars is just my preference and is not directly
supported by anyone but me, and using Android Jars actually requires
extra effort,

So my question to ADT devs:

Are there any considerations to add explicit support of Android Jars
to eclipse and ant build system. Or I was wrong, and the strategic
idea was for everybody to use Android Libraries only?

[Xavier Ducrohet]

As we add support for packaged Android library (single package with code + resources), what you call and Android Jars would simply be a packaged library with no resources in it.

The issue is that even with a packaged library, the dependency setup in a project is more complex as you have a required order to resolve resource overlay, which is not the case for straight code-only jar that you can dump in the libs folder.

We'll probably:

- make packaged library have a different extension to differientiate them

- make the packaging feature be smart to detect lack of resources and create standard jar instead.

Xav

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

Please do not send me questions directly. Thanks!

[Ievgenii Nazaruk]

So in other words you considering (or planning) to treat "Android Jar" as a specific case of a more general "Android Library" feature? 

[Xavier Ducrohet]

Well actually I'd like to know what you mean exactly by Android Jars.

Is that a straight up Jar file that contains code that was linked against an android.jar? Basically the result of "export jar" on an Android project?

In this case, it's just a jar, no different from any other jar (except, I suppose, that Ant doesn't let you create them easily, but we could add a target for that.)

We might want to add some android-specific features if you wanted to put Services, or Broadcast receiver in there too (I would think activity would require resources and push it into the Android Library realm) since you'd need to merge the manifest. Also we'd need to handle minsdkVersion to ensure proper compatibility.

I'll need to think more about it.

[Manfred Moser]

The Android Maven Plugin does reuse with the "apklib" format which is
just resources and code all packed together. There is no smarts in
terms of merging manifest and so on but it works at least. I think it
would be a good first step to add something like that to the core SDK
and then implement more fancy merging and so on later in a way that
other tools can reuse the functionality. But reuse is very important
to get some support now..

E.g look at applications like the Gauges app from Github and how many
libraries (dependencies) it uses.

https://github.com/github/gauges-android

Lots of apps using frameworks like ActionBarSherlock, Roboguice, and
many more as well as plain libraries like gson, ksoap2-android ...

manfred
http://simpligility.com

[Mark Murphy]

On Fri, Feb 24, 2012 at 1:31 PM, Xavier Ducrohet <x...@android.com> wrote:

> As we add support for packaged Android library (single package with code +
> resources), what you call and Android Jars would simply be a packaged
> library with no resources in it.
>
> The issue is that even with a packaged library, the dependency setup in a
> project is more complex as you have a required order to resolve resource
> overlay, which is not the case for straight code-only jar that you can dump
> in the libs folder.
>
> We'll probably:
> - make packaged library have a different extension to differientiate them
> - make the packaging feature be smart to detect lack of resources and create
> standard jar instead.

The fact that this is mostly in future tense, and the fact that the
R17 preview doesn't seem to mention any of it, suggests that this
stuff didn't make R17. Am I correct in this assessment?

Thanks!

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_Android Programming Tutorials_ Version 4.1 Available!

[Xavier Ducrohet]

Correct.

[Joe Bowbeer]

On Friday, February 24, 2012 10:31:21 AM UTC-8, Xavier Ducrohet wrote:

As we add support for packaged Android library (single package with code + resources), what you call and Android Jars would simply be a packaged library with no resources in it.

The issue is that even with a packaged library, the dependency setup in a project is more complex as you have a required order to resolve resource overlay, which is not the case for straight code-only jar that you can dump in the libs folder.

We'll probably:

- make packaged library have a different extension to differientiate them

- make the packaging feature be smart to detect lack of resources and create standard jar instead.

Xav

Is there an issue # for this packaged library feature? (Now that 9656 is released.)

What about support for pre-built packaged libraries consisting of binary + resources, without src code?

[pete jackson]

As far as I can see the ever present problem with this approach is backward compatibility and non-standard type builds. Perhaps at a basic level Code + Binary packages would be fine and fit most requirements but  Code + Resources optionally downloadable as/if required for the remaining few unusual builds?
Take care, Pete Jackson :-)

[Benoit Billington]

Hello guys,

Maybe there's another topic but I think ADT plugin should definitely improve the way Android library are dealt with.

What is the roadmap for better or reworked support for Android libraries? and "Android jars" (plain jar using android stuff) ?

I can only see "Build support: Library support: merge manifest of libraries into application's manifest"

I'm using maven-android-plugin and they have introduced a nice way to deal with apklib.

But sadly this is not the same in the Eclipse environment.

The ADT plugin is not flexible as it required us to have the Android library checked out in our work space and put into eclipse.

What is the version changes to a major one which is not backwards compatible?

I would need to have 2 Android library in my Eclipse workspace if I have 2 projects that uses 2 different major versions.

This is simply a nightmare to manage in Eclipse.

Thanks to android-maven-plugin for giving us support via the command line for all this already. but it's just not sufficient to develop our app as we needs good editors like Eclipse.

[Xavier Ducrohet]

Yes, this is a known issue. You might want to read on my build system
proposal to see what we're planning.