-- There is no "set" rules for renaming a manifest, so we must adapt to patterns. There are some apks that have original package names as "android", "miui", "com.htc", etc. These are not meant for renaming, but exist to align that apk to a specific OEM framework system. (EX HTC system apks have a package id of com.htc). However, this pattern isn't true when framework apks are involved, as the intended behavior is to rename the package from xxx to com.htc (as an example).
-- We solve this by first identifying the active package via the packageId instead of package with most ResSpecs (we fall back on that though)
-- then with two hardcoded arrays of UNKNOWN_PACKAGES and ALLOWED_PACKAGES
Issue #526, correctly handles apks where a renamed package is required, by comparing the package name present
in AndroidManifest.xml and resources.arsc. If different, we take the package name present
in resources.arsc (original) and replace it in the <manifest> tag of AndroidManifest.xml. The previous value in
AndroidManifest.xml (renamed) becomes the value to be passed to aapt on rebuild via --rename-manifest-package
Both these values along with the package id of the original are stored in apktool.yml, for use during the
rebuild
I didn't tracked down where the issue comes from and whether this is expected behaviour (actually I doubt). But when building on Windows, the test trys to create a strings.xml in "values-mcc004-mnc4-en-rUS-ldrtl-sw100dp-w200dp-h300dp-xlarge-long-land-desk-night-xhdpi-finger-keyssoft-12key-navhidden-dpad". This exceeds the max length for file/directory names in Windows and therefore the build aborts.
Because this was currently the only issue that breaks building on Windows (when 073019fa54 is applied), this workaround should do the trick (for now).
