Creating a JAR is, in my opinion, a very bad decision. Android has specific features just for the kind of thing you're looking for. If your JAR:
- provides some sort of (structured) data to be used in other applications, use a
ContentProvider
;
- does some backround processing and makes that processing's results available to other applications, use a
Service
;
- provides an
Activity
that gets some input from the user (or shows some information about something), eventually processes it and returns it to the calling Activity
, just create that Activity
and any application will be able to start your Activity
as long as it's installed on the phone.
If you use one of the three solutions above, third party apps will be able to probe for whether your application is installed and, if not, prompt the user to install it. Only if your application does not fall into one of the three bullet points mentioned above should you use a JAR. Otherwise, using a ContentProvider
, Service
or Activity
provides:
- More standardized interaction between components
- Better maintainability -- if you update your SDK you won't have to call everyone who uses it and tell them to upgrade.
- No duplication -- if you were to provide a JAR and multiple applications that use it would be installed on a device, multiple copies of the JAR would be present on that device, thus using more memory than it has to. If you provide one of the three components mentioned above, one copy will satisfy all applications that need to use it.
Again, these components are specifically designed and provided by the Android OS for creating such SDKs. Please, only use a JAR if you really, really have to. Otherwise, provide a standardized ContentProvider
, Service
or Activity
and document the way it's supposed to be used (i.e. how to use/query/integrate it).