I wholeheartedly agree with Guillaume that Android lib projects would be a good feature. But maybe the case I have in mind requires something different.
I have ported to Android an LGPL library, libdmtx. This library has native code and JNI wrapper. I created an org.libdmtx APK which installs the native library (and the icon). The standard access rules to /data/data/org.libdmtx/lib folder allow the native library to be used from any application. But to work with this library, for every application I must copy the libdmtx.jar file to the project libs directory. Also, creating libdmtx.jar is a separate manual step in Eclipse, and I must not forget to do this when some sources of libdmtx change. I would expect there to be a more straightforward and automatic way to do all this. At least, luckily I can tell Eclipse that the application references the libdmtx project (in the same workspace) and it will install libdmtx.apk together with my application apk when I debug it or run it as Android application. Thanks, Alex From: Guillaume Perrot <[email protected]> Android lib projects would be a good feature. But why not having a dependency system between APKs like debian packages ? 2009/5/1 Xavier Ducrohet <[email protected]> > Hello, > Editing the .classpath is a good solution. Let me explain why. > ADT supports referenced projects so that you can have library projects > reused by your main Application project. > In the past, the build system provided by ADT just looked at the list > of referenced projects, and added their output (bin/*/*.class) to the > classes.dex of the application project. > The main issue here is that those referenced projects should never > have been Android project themselves. > The reason is that those Android projects could have resources, which > in turn creates an R.java file, which in turn is potentially used by > the library project classes. Even if the resources from the library > projects are copied into the main application project, there's no > guarantee that the IDs in R.java will be similar between the projects. > Therefore, at runtime, the classes from the library would access the > wrong resources. > We noticed this when we implemented the JUnit support. Instrumentation > projects (look under samples/ApiDemos/test/) must reference the > project they're testing to be able to compile, but they shouldn't > include the code of the application they test. > To fix this, we've restricted support of referenced projects to > projects that are not Android projects (ie, do not have the Android > Nature). > Now, we do realize that you may still want to be able to share code > that reference or extend Android classes, and this is not convenient. > The solution to edit the .classpath to remove the nature and builder > is one that will work, as long as you ensure that you are not using a > previously generated R.java. > For code that doesn't reference Android code, just make a standard Java > project. > In the future we will probably add a new type of Android project > (maybe Android Library Project), that will allow you to compile > against the Android framework but doesn't support Android resources, > and doesn't generate R.java classes. > Xav > On Thu, Apr 30, 2009 at 7:26 AM, JMoger <[email protected]> wrote: > > I've got a working solution to this similar to your hint about J2SE > > projects. Assuming your lib project is an android project, modify > > the .project file to remove all Android builders and Android natures. > > I removed the "resourcemanagerbuilder", "precompilerbuilder", > > "apkbuilder", and "androidnature". My lib project does not have any > > resources so I don't know what happens in that situation; its just my > > android code common to multiple projects. > > The .classpath file remains unchanged: > > <classpath> > > <classpathentry kind="src" path="src"/> > > <classpathentry kind="src" path="gen"/> > > <classpathentry kind="con" > > path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/> > > <classpathentry kind="output" path="bin"/> > > </classpath> > > This allows the project to compile against the Android library > > specified by the new "default.properties" file without manually > > specifying the android.jar and your dependent applications projects > > still compile in Eclipse and generate proper APKs. > > This is still less than ideal, but it has allowed me to get back on > > track. YMMV. > > -J > -- > Xavier Ducrohet > Android Developer Tools Engineer > Google Inc. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
