How to create a shared library in Android

2019-02-16 13:25发布

问题:

I have a library, say LIB, which exposes the quite a few APIs and classes for use by application developers.

If there are more than one applications that use LIB on the phone, I want only one instance of LIB to be created and running. It is somewhat similar to what Android Platform Services like LocationManager, SensorManager, PackageManager etc.

Specifically, there are two problems that are to be addressed:-

  1. How to make sure that there is only one instance of LIB ?
  2. How to deploy LIB(separate apk/ bundled with every application that uses it, but only one of them creating the library instance at any point of time) etc.
  3. Is there any other way(other than service/AIDL) to make sure that only one instance of LIB runs irrespective of the number of applications using it.

回答1:

Okay, after spending time on this, here the answers to my questions:-

Q. How to make sure that there is only one instance of LIB ? - Only through exposing the LIB functionality through a service.

Q. How to deploy LIB(separate apk/ bundled with every application that uses it, but only one of them creating the library instance at any point of time) etc. -

For service, there would be a separate apk(or probably bundled with one of the service client app),

Q. Is there any other way(other than service/AIDL) to make sure that only one instance of LIB runs irrespective of the number of applications using it.

Yes, that would be like LIB is bundled with every application. But that would need a strong communication protocol between the libraries using intents, so that one of them acts as master, and shares the data with the other libraries. Effectively, the LIB packaged within an apk starts its engine, only if no other instance is running. One way of accomplishing this is using broadcasts and to maintain security, permissions can be associated with the involved broadcast actions.



回答2:

With the library project, you have a static inclusion of the classes and resources from the library project. Nothing will be running that doesn't need to be.

That can increase the size of your app, but techniques such as ProGuard can remove unused classes from your final .apk.

If you want your library to be running independently of other apps, then it is indeed a service and you should consider what the lifecycle should be (e.g. started by the app, started at boot, etc.).

If your lib contains activities to be run, the Android OS already handles this - the other app just creates an intent and calls out your activity. This is how Android works - apps can share data and workflow between each other seamlessly using intents.

If there are services, it's the same thing - the calling app either interacts with a running service or triggers a service to start.

Library projects handle a lot of issues for most developers, but if you have a really large shared code package you'll want to install as a separate app.

For example, Google Maps is a separate app, but other apps can trigger an intent to load an activity from that app. The same with messaging and other activities that can be handled by different apps.