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 <x...@android.com> > > 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 <james.mo...@gmail.com> 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
