tags:

views:

288

answers:

4

As I understand, the three ways of distributing my application are via Jar, Android Library and Android Library Project.

Jar - cannot contain resources or XML layouts (so this is out for me)

Android Library - I don't really know how this works but the Google API uses it...

Android Library Project - includes resources but allows the client free rein on the code as it is distributed as source.

If I am to create a closed source application that requires drawables and XML files that I want to distribute to other Android programmers, what should I use? And can someone direct me to a tutorial on creating an Android Library?

A: 

The android developer documentation has an article on about Android Libraries:

http://developer.android.com/guide/developing/eclipse-adt.html#libraryProject

hcpl
That is an Android Library Project not an Android Library. They are different.
jax
A: 

First of all, I think that if you want to publish your projects, programs you want them to work on an android device.. So you may want to publish them on .apk format. And when you create an apk package there isn't any limitations about what you put in it. Your resources and layouts must be in it because your application won't work without them.. if I were you, I would check out the android project export tutorials at first.

http://developer.android.com/guide/publishing/app-signing.html

In this page it explains the methods of publishing and signing your application.. You can have a look at this.

Ertan
An APK is a compiled project. This does not allow other programmers to use the library I have created.
jax
A: 

It's not a Jar its an APK

Blundell
+1  A: 

More details on what exactly does your project would be welcome. My understanding is that you want to sell a library (a set of components/tools developers can integrate in their app) without disclosing the source.

As you stated, you can't include assets/resources in Jar files.

An Android Library Project would force you to let the source code be "visible". Proper licensing terms could help you put legal fences around source code usage but... well, you know what people do with licenses... Maybe some code obfuscation (not on the public visible methods) could help.

I'm not sure about how "shared libraries" included with <uses-library> work, but the examples have seen are system dependent (maps API available only on "official" Google accepted devices, Sprint Evo front facing camera...) and might require to be built within the system. Maybe some root privilege could help adding one, but this would have to be done on EACH device where applications using your library would want to run...

Kevin Gaudin