Incompatibility with DexGuard about ruler

[simonschiller]

I've opened #88 to solve the mapping file issue (for classes). I don't have a DexGuard license to test it, if you want you can give it a try.

[simonschiller]

Should all be compatible now in the latest 1.4.0 release.

[ViktorPetrovski]

Hey, @MrHadiSatrio thanks for reporting this issue!
We will take a look and try to fix this as soon as possible!

[simonschiller]

Yes, all we should need to do for the mapping files is to figure out if DexGuard (or ProGuard) is used and then use the specific location, something like this:

val mappingFilePath = when {
    isUsingDexGuard(variant) -> // Use DexGuard specific path
    isUsingProGuard(variant) -> // Use ProGuard specific path
    else -> // Use AGP path (like we do now)
}

For the workaround - we could add one by adding a dependency on bundleRelease, but to be honest I'd rather wait for Guardsquare to fix this issue. In the meantime you can add a workaround yourself by doing something along the lines of in your project:

tasks.named("analyzeReleaseBundle").dependsOn("bundleRelease")

[MrHadiSatrio]

Sure thing @ViktorPetrovski. Thanks for acknowledging the issue!

For what it's worth, I tried adding a dependency to bundleVariant while the task is being registered in RulerPlugin to generate the --dry-run diff below. (Ran on a sample app provided by DexGuard.)

I can also see a difference in the generated reports.

Ruler	Download Size	Install Size
1.3.0	1.8 MB	2.0 MB
Local (post-change)	623.7 KB	717.2 KB

For your convenience, here are zipballs of the reports directory.

• Ruler 1.3.0.zip
• Ruler Local.zip

One issue I noticed is that DexGuard mappings are not getting picked up by Ruler. As you can see on the local results, most of the classes are obfuscated still.

[simonschiller]

Thanks for reporting indeed! That's very interesting, it seems like DexGuard only runs when you explicitly call the bundleRelease task (or the equivalent for other variants). We use the APIs provided by the Android Gradle plugin to locate and add the task dependencies for the produced bundle file. This doesn't add the dependency on bundleRelease however, since that by itself doesn't do anything and is only used as a hook for other tasks (tasks like i.e. packageReleaseBundle that are actually doing the work).

It seems to me like that's an issue within DexGuard, as it should also run without the bundleRelease task being called explicitly. Other plugins might also rely on the official AGP APIs (as they should) and therefore would also run on the wrong bundle file. Maybe you have a contact at Guardsquare (I'm assuming you're a customer) that you can ask about this? Looks like the task dependencies that they use are not 100% like they should be.

The mapping files not being picked up is another issue - this is on us and we have to implement compatibility for that.

[MrHadiSatrio]

This doesn't add the dependency on bundleRelease however, since that by itself doesn't do anything and is only used as a hook for other tasks (tasks like i.e. packageReleaseBundle that are actually doing the work).

TIL! Interesting then. I was under the assumption that bundleRelease played a more important role than what you described. I will try to convey this issue to DexGuard. In the meantime, would you consider solving the issue this way as a viable workaround? Or maybe there's another thing that I should look into?

The mapping files not being picked up is another issue - this is on us and we have to implement compatibility for that.

Actually, I've made some progress here too. It looks like the cause is similar. Explicitly setting mappingFile like so works without requiring any further change.

task.mappingFile.set(File(project.buildDir, "outputs/dexguard/mapping/bundle/${variant.name}/mapping.txt"))

[MrHadiSatrio]

Thanks on the clarification! That is helpful indeed. 👍

but to be honest I'd rather wait for Guardsquare to fix this issue

One downside I see from this is that Ruler would have a soft-dependency on whichever DexGuard version Guardsquare decide to ship this fix in. But yeah, that's nothing a statement on README can't fix.

[MrHadiSatrio]

I also realized that DexGuard obfuscates resource file names by default. And it does so in a way that mess with the directory structure of /res as well. Unless this obfuscation is reversed, #86 will not be possible.

Excerpt of the generated resourcefilenamemapping.txt to illustrate:

res/anim/abc_grow_fade_in_from_bottom.xml -> [res/raw/a.xml]
res/anim/abc_popup_enter.xml -> [res/raw/b.xml]
res/anim/abc_popup_exit.xml -> [res/raw/c.xml]
res/anim/abc_shrink_fade_out_from_bottom.xml -> [res/raw/d.xml]
res/anim/abc_tooltip_enter.xml -> [res/raw/e.xml]
res/anim/abc_tooltip_exit.xml -> [res/raw/f.xml]
res/animator-v21/design_appbar_state_list_animator.xml -> [res/raw/g.xml]
res/animator/design_fab_hide_motion_spec.xml -> [res/raw/h.xml]
res/animator/design_fab_show_motion_spec.xml -> [res/raw/i.xml]
res/animator/mtrl_fab_transformation_sheet_collapse_spec.xml -> [res/raw/j.xml]
res/animator/mtrl_fab_transformation_sheet_expand_spec.xml -> [res/raw/k.xml]

We might need to introduce a sanitizer for resource files, just like how one exists for class names. A very rough implementation of it is available here: main...MrHadiSatrio:ruler:dexguard_resource_mapping.

---

Edit: Getting attribution errors even after de-obfuscating file names. All resource files–including those from libraries–are being treated as if they came from the sample module. 😕