As part of the Gradle transition, we want to verify that we don't corrupt the resources of the final signed APK files -- especially during multi-locale builds and l10n repacks. maliu had the clever idea of writing some code that would run on device and use remote contexts and reflection to enumerate org.mozilla.gecko.R and - verify that the resource sets are the same - verify that the types of the resources haven't changed In order for this to work, the APK that has this functionality has to be signed like the APKs that will be inspected. But we have such an APK -- the Robocop test APK. So this ticket tracks implementing this enumeration and sticking it into robocop.apk. We might do this with an Android Intent that can be invoked via adb to look at an arbitrary package.

I tried to make a POC to validate the correctness between resource.arsc and the resource enumerated as R.java . The simplified process look like this. 1. Create a remote context from target package(ex. org.mozilla.fennec) 2. Find out all classes in every R.java(ex. anim, bool, color, dimen. drawable, layout, string, etc. ) 3. Iterate through all the resource type with Resources.getidentifier with target remote package name 4. Use resources from remote context to get corresponding resource by the id from step 3. 5. Raise/Log the exception Resources.NotFoundException. The actual result is not quite useful for the following reasons: 1. Some resources requires extra xml parsing step to get the actual resources. (ex. ColorStateList/StateListDrawable) 2. Some resource is exist in R.java, but not available between different runtime platform version. (ex. resources with -v23 or -v25) 3. Couldn't load some resources from support library, (ex. abc_dialog_fixed_height_minor/highlight_alpha_material_dark). Possible reason is that these resource are not with normal format. line:60~68 [https://android.googlesource.com/platform/frameworks/base/+/015e96c/core/res/res/values/colors_material.xml#60] The only resource we can be certain about is the strings. Because we already have a lint tells us if one string is in certain language but not in the default. Other than that, we cannot be sure if the reason unavailable is because of the api level or not. unassign myself if any one interested digging into this deeper.