Adding aar of Another Apk with Target Apk result in Multiple Apk error

[Fenil15]

When I try to add my apk as an aar (AAR created using dexpatcher-sample app) with Target Apk getting below runtime exception: java.lang.RuntimeException: Multiple apk libraries found How can I possibly Add my app's functionality in Target Apk using dexpatcher?

[Lanchon]

hi,

your description is extremely unclear. what are you trying to achieve? exactly what are you doing to reach that end?

When I try to add (add to what? what is your project? how and where are you adding your AAR to it?) my apk as an aar (AAR created using dexpatcher-sample app) ("dexpatcher-sample app" does not exist. how are you creating your AAR? why are you creating an AAR?) with Target Apk getting below runtime exception: java.lang.RuntimeException: Multiple apk libraries found

[Fenil15]

Q - What I am Trying to Achieve? Ans - I am trying to Add my Apk in any 3rd party Apk using Dex-Patcher and overriding that target 3rd Party Apk source to add entry point to my library using DexPatcher Annotation. This will help me to provide my app's functionality into any App

Sample project works fine with Target Apk, but when I am trying to add my library as aar it is giving multiple errors. Can you guide me about what is the correct process?

Details - I converted my Apk into aar using source code changes (First I relied on Dexpatcher to convert my Apk into Aar but that is considering as an Apk, so created aar seperately). But my library is dependent on multiple libraries defined in gradle, which needs to be added in DexPatcher-Sample App's gradle and on building it is giving multiple errors regarding some of the resources already added.

Below are is the part of my additional dependencies which I think is creating conflict of my aar library when adding it in the Dexpatcher-Sample-

    compile "com.android.support:support-v4:27.1.1"
    compile "com.android.support:appcompat-v7:27.1.1"
    compile "com.android.support:design:27.1.1"
    compile "com.android.support:percent:27.1.1"

Basically looks like the 3rd party Apk compiled with Support library version is conflicting wth the one used by my AAR library. Can you please guide me in how to progress, it will be of great help?

[Fenil15]

@Lanchon In patched/build.gradle while importing aar file you have mention -

Alternatively we could delete the copy brought in by the source app using DexPatcher package annotations.

Can you let me know on how to use DexPatcher package annotations? I have used Annotations in java file but how to use it in gradle file I don't know

[Lanchon]

you can never convert an APK to an AAR. dxp can create an APK library which is a different thing. an APK library can only be consumed by dxp, while an AAR is consumed by the regular android builder.

two APK libraries can ABSOLUTELY NEVER be merged into a single APK. APK libraries have compiled bytecode with numeric resource identifiers baked in as numeric literals. dxp handles this by not changing the numeric values of resource identifiers coming from the source APK, while generating new values for added patch resources as usual. but if two APKs are merged, the numeric values of resource identifiers of both APKs will clash, and because the numeric IDs cannot be changed in the bytecode, the clash cannot be resolved. (there is no way to know if numeric literals are resource IDs or other unrelated numbers or both at the same time, or if they will be computed at runtime by obfuscated code.) this is not a limitation of dxp, but rather an unavoidable property of android APKs.

when there is a library in the source APK and you want to use the same library in the patch, you have a few options:

• if the library in APK is not obfuscated, the APK and the patch can share one instance of the library:
  • if the library in APK is not minimized, you can use that version from your patch code:
  • you can use the 'compileOnly' scope to reference the library from the patch without including it in the patch.
  • or if you are creating an AAR, when you reference your AAR from the patch you can exclude the transitive dependency like this.
  • or you can remove the source APK version of the library and replace it with your own copy like this.
• otherwise you can include two separate copies of the same library in the patched APK by doing a "package rename" of the library included in the patch so that it will not clash with the one in the source. this works even if the source library is obfuscated. there are various Gradle plugins to create this type of "fat jars", as they are called. mixing several AAR in one APK sometimes results in this problem, so some AAR authors do this "fat jarring" of some of their transitive dependencies. this problem is not unique to dxp and is relatively common in android development, so please google elsewhere for details on how to do package renaming of dependencies in android.

[Lanchon]

Can you let me know on how to use DexPatcher package annotations? I have used Annotations in java file but how to use it in gradle file I don't know

package annotations are a standard java feature: https://www.intertech.com/Blog/whats-package-info-java-for/

[Lanchon]

closed due to inactivity