The issue I have is that when the service is started in either application, the other application is not notified of any events.
That's because you have two services. Just because the service is packaged in an Android library project does not somehow magically cause two distinct applications to use the same copy.
Such as using the Singleton pattern to retain a single instance, but the problem still seems to exist.
Both applications are running in separate processes, with their own private copy of the service.
My only comprehension of this is that each time either application is started, a new instance of the library is created.
Libraries don't have instances. Android library projects are not DLLs -- they are more akin to static libraries.
Thus the library referenced in TestApplicationOne is not the same instance as the library referenced in TestApplicationTwo, and as a result, not being notified.
More accurately, the service in TestApplicationOne
is a separate copy of the service from the copy in TestApplicationTwo
.
Or can think of any possible solution?
Don't have two separate applications.
Or, redesign your apps such that only one has the service, and the other uses the service from the first app.
Or, have the service disabled in the manifest in both apps, exported with a stable <intent-filter>
(e.g., with a custom action string). The first app to be installed/run uses PackageManager
to see if the service exists (e.g., it's not really the first app) -- seeing that the service does not exist, it enables its own copy of that service. Then, the second app goes through the same process, sees that the service is already there, and uses the remote copy rather than enabling its own.
Neither the second or the third are very easy, simply because the data only exists in one app (the one with the service). Hence, if that app is uninstalled, the other app is screwed, even if it happens to have the service code available as a disabled component. If the apps are clearly described to the user as having a primary/secondary relationship (e.g., app and its plugin), then this may work out -- users hopefully won't expect a plugin to work if the app isn't there, for example. Of course, in this case, the plugin wouldn't have its own copy of the service in the first place, but would always look to the main app for that.