Reputation: 11185
I have an Android library project (A) which is used by several Android application projects. A library jar placed inside the libs
folder of the library project refers to com.lib.R
resource files (say images) inside this project.
When application project (B) uses this library, it may invoke some code that triggers the jar file in the libs folder to refer to resources that are referenced by com.lib.R
. Unfortunately any attempt to access these resources results in the following error.
java.lang.NoClassDefFoundError: com.lib.R$layout
If these resources are accessed from the src/
folder of Lib A
or the src/
folder of Project B
, they resolve correctly to an int
value and can be used, but I'd prefer not to do that and keep the code inside the libs
folder.
My question - Why does this happen and how do I get it resolved ? One work around is to get the resource ID programmatically using resource.getIdentifier()
, but that can become a pain very fast. Is there a way I can still use com.lib.R
from a library jar under libs
without having to resolve it manually using helper methods ?
Here's an illustration to help you out.
Resource access from library
Upvotes: 2
Views: 1343
Reputation: 1007533
and how I can improve on it
I am going to assume that your objective is to be able to distribute A and B in source form, but not the contents of some_lib.jar
("The reason this was done was to avoid exposing the java files to end users"). In that case:
Step #1: Create another library project (L) containing the source code from some_lib.jar
and all the resources that it refers to (moving those resources out of A and into L)
Step #2: Create a distribution library project (LD) following the recipe that I just wrote about earlier today
Step #3: Have A depend upon LD, to pick up the resources along with the compiled JAR of L's code
Step #4: When you distribute the source, also distribute LD
My hope is that by creating a formal library project for some_lib
's code, and by having the resources it needs declared in that library project, you will be able to compile a JAR that will work for B.
Now, this is more complicated than I have tried, and so it's entirely possible this will result in the same outcome that you are experiencing. If that is the case, then you are out of luck, at least until you switch over to the Gradle-based build system, in which case L/LD becomes an AAR file, and hopefully will work.
Upvotes: 2