How android build system handles java libraries that load native shared libraries

Consider the following situation: I have two Android projects named P1 and P2 that both produce apk that use the same process id and will run in the same process on android. P1 and P2 use Java library JL1. JL1 is loaded into the shared library of the SL1 environment.

What I see at runtime is that at some point I get java / lang / UnsatisfiedLinkError while loading this SL1. It also outputs: The shared library is already open.

What is causing this problem? My guess is that the library code in java is copied in every project / apk and at runtime when the apks are merged into one process it forgets about the copies. Therefore, each copy loads its shared library, causing an already loaded error.

If so, this is not unwanted behavior. Because now you can never have Java libraries with a shared library in the same process that has been used more than once.

[edit] I found out that each apk uses its own classloader (also in the same process). This means that each JL will be loaded by the class on the apk and therefore each shared object will be loaded more than once, resulting in an error. Does anyone know how to get around this? Is it possible for apks to share a classloader?

+3


source to share


1 answer


Each apk has its own classloader. This means that the two projects / apks will have their own copy of the classes from the library. Which they load at runtime. Therefore, what looks like the same classes are actually copies. Therefore, loading your own library in such a class will cause it to be loaded for each loaded class (even if it is done in a static field). This results in a runtime error to load native shared object more than once if two apks are using the same process.



+1


source







All Articles