We currently prevent resourceIds from changing, by utilizing the public.xml file which makes the resources public, but
then prevents them to be used in some locations (android:scheme). The correct fix would be to record the resourceIds
and use dexlib2 (no regular expressions) to rewrite them to the new resourceId after the resources.arsc is built.
This would be a lookup table of old->new resourceIds leveraging the API of dexlib2 to do the replacement. Doing this properly would nullify the need to do #191
Suggestions: #244 Discussions: #2062
Currently we have a mismatch between reading the folders and reading the qualifiers which leads to a mismatch between implicit qualifiers like version (-v4, v13, etc).
This was first spotted in bug #1272.
This was attempted to be fixed in !1758, but had to be reverted due to this.
Suggestions: #2237
For some OEMs, past and present. They re-use qualifiers that AOSP ends up using. This with CTS is becoming very rare and pretty much a problem of the past, but now custom modifications and more "off the cuff" OEMs are doing it.
Apktool can't do anything because it stays true to AOSP. It would need a plugin system that controls how to read the qualifiers. Or even an override file.
Some applications may shove resources into the /res folder, but have no references to them. Apktool follows the resource table, so these files are effectively abandoned.
Crawling the filesystem for non-checked files would be slow especially having to cross check with already parsed files.
Suggestions: #1366