Class files with incorrect resource import path about aaraar HOT 8 CLOSED

I see. For me using this rename rule is just fine. Maybe you can add this as an extra example on readme info.

aaraar {
    rename("**.R\$**", "com.gmcristiano.sampleaaraar.R\$@2")
}

Forget about my issue with disabling module metadate. That was copied from my original project where I was adding Pom dependencies manually and to do that, gradle module metadata needs to be disabled.

In my case, to use auto generated gradle module metadata, I need to figure out how to add a dependencies to pom from a local project(:library) with configured group, id and version.

appreciate the effort with everything.

from aaraar.

Hmm...are you applying some shading rules and expecting these package names to be different? I'm not sure I fully understand what's breaking here. If you're able to provide a dummy project example just to show the full parameters of the project, that would be helpful!

from aaraar.

@christiandeange when merging everything, android resources will be part of the final AAR. This means that all classes should have the original path to the resources changed to the final AAR.

I tried to change like this and didn't work,

aaraar {
    rename("com.originalaar.R.**", "com.finalaar.R.@1") // doesn't work
    rename("com.originalaar.R", "com.finalaar.R") // doesn't work
    rename("com.originalaar.R.layout", "com.finalaar.R.layout") // doesn't work
    
    rename("com.originalaar.**", "com.finalaar.@1") // WORKS BUT CHANGES EVERYTHING INCLUDING IMPORTS AND FILE PATH INSIDE classes.jar
}

from aaraar.

The classes inside R are inner classes that use the $ notation when being referenced as a class file. I think you should be able to rename them at the class level using rules like:

aaraar {
    rename("com.originalaar.R", "com.finalaar.R")
    rename("com.originalaar.R\$**", "com.finalaar.R\$@1")
}

That would correct what you're trying to do with that rule, though I'm still a bit unclear on if using a rule like that addresses the root cause of what you're trying to do.

from aaraar.

Thank you.

Works perfectly.

A more generic version:

aaraar {
    rename("**.R\$**", "com. finalaar.R\$@2")
}

Without this rule, what happens is that the bitecode will have import references to the original AAR resource location,
But when using the final merged AAR, the location will be the final AAR.

I think this should be included internally.

Don't you have a AAR with a fragment for example with an incorrect import path to the layout or string from R. It's the simplest example...

from aaraar.

Sorry I still don't think I understand what you're trying to accomplish.

I have an "empty code" android library project with just AARs and realize that after generating the final merged aar file [...]

Are you running aaraar in your library module or in your "empty code" module? Again, a sample project would really go far to explain what the underlying issue is here.

from aaraar.

sample aaraar.zip

here it is.

Some instructions:

sample_aar -> sample lib project with Activity -> Fragment -> ViewModel to create sample-release.aar
sample_aaraar - > sample lib using AarAar to merge with sample-release.aar using version from 0.0.8-SNAPSHOT.
My Application -> Android App using sample_aaraar (activity crashing) from mavelLocal.

findViewById<TextView>(R.id.text_view).setOnClickListener {
    Intent(this, SampleActivity::class.java).apply { startActivity(this) }
}

aars compiled -> sample-release.aar, and both working and not working mavenLocal (.m2) version of sample_aaraar with rename rule:

aaraar {
    rename("**.R\$**", "com.gmcristiano.sampleaaraar.R\$@2")
}

I'm using "./gradlew clean assembleRelease && ./gradlew publishToMavenLocal" to compile and publish sample_aaraar to mavenLocal. You can config the publish.properties file, or build and switch just the aar file from .m2 folder.

You need to config gradle jdk to use java 11+.

from aaraar.

Thank you for the example project. However, this example is far from simple. You're depending on a separate AAR like so:

configurations.maybeCreate("default")
artifacts.add("default", file('sample-release.aar'))

This is very atypical of the way that developers consumer other libraries and is often only used because AGP will attempt to block you from depending on an AAR by other means. There is no way for the library to know what application modules will be using it there's nothing for us to include internally here.

The sample project is interesting though – I will look into the issue of having to disable Gradle module metadata generation.

from aaraar.