On Friday, December 16, 2011 6:36:35 PM UTC+1, Phillip wrote: > > Hi freakingtux ! Thanks for your answer!
> Well but my problem is that I have added some code to existing > > platform classes (e.g. simple static variables) and I want the IDE > (e.g. Eclipse) to have this updated class available for writing > applications. When I add theese certain classes to my vendor.jar it > does not work. > This indeed will not work. The android development tools will create an eclipse classpath that wil always first contain the android.jar from the SDK. The kind of changes you did sound similar to what we did .e.g add thing like additional sensors or network connection types. To guaranty that the customer of your API can use these constants you will not only need to copy them (e.g. duplicate them) into your own package(s). > What is interesting to see is that an add-on actually n ships a full > system image(including all > > the API implemnetation) but that something like an eclipse project will > > still use the android.jar specified in the normal platfom-sdk. > > Yeah I think the system.img just contains the Android root filesystem > and can be used with the emulator, but I haven't tired that yet, > because I don't need this feature at the moment. > Even the add-on approach is a pain to maintain and distribute. Depending on the scope of the project and the amount of custom code you have you should consider writing a (possibly wrapped) binder based API and "simply" publishing that jar for application developers to include in their code this might remove the need to publish these constants (depending on the kind of changes you made) Greetings -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
