Alignment issues in patched APK

[kitadai31]

I would like to report three alignment issues.

1. resources.arsc should be uncompressed and aligned across all Android versions

Currently, resources.arsc is saved uncompressed only on Android 11+.

Manager/app/src/main/kotlin/com/aliucord/manager/patcher/steps/install/AlignmentStep.kt

Lines 30 to 36 in ff345fb

	// Align resources.arsc due to targeting API 30 for silent install
	if (Build.VERSION.SDK_INT >= 30) {
	container.log("Extracting resources.arsc to be aligned later")
	resourcesArscBytes = ZipReader(apk)
	.use { it.openEntry("resources.arsc")?.read() }
	?: throw IllegalArgumentException("APK is missing resources.arsc")
	}

However, this should be applied to all versions.
Android 11 now enforces resources.arsc to be stored uncompressed, but the uncompressed arsc had been recommended from earlier versions.
Reference: https://stackoverflow.com/questions/23260194/why-dont-compress-resources-arsc-in-apk-files

I suggest modifying this part of the PatchIconsStep to save the arsc here uncompressed and aligned.
Because this is a only part which writes resources.arsc.

Manager/app/src/main/kotlin/com/aliucord/manager/patcher/steps/patch/PatchIconsStep.kt

Lines 198 to 201 in ff345fb

	container.log("Writing resources unaligned compressed")
	it.deleteEntry("resources.arsc")
	// This doesn't need to be aligned and uncompressed here, since that is done during AlignmentStep
	it.writeEntry("resources.arsc", arsc.toByteArray())

- it.writeEntry("resources.arsc", arsc.toByteArray())
+ zip.writeEntry("resources.arsc", arsc.toByteArray(), ZipCompression.NONE, 4)

I confirmed this is fine by building aliucord manager myself.

2. Custom app icon is not uncompressed and aligned

This is a png resource, so it must be stored uncompressed aligned

Manager/app/src/main/kotlin/com/aliucord/manager/patcher/steps/patch/PatchIconsStep.kt

Line 195 in ff345fb

it.writeEntry("res/ic_foreground_replacement.png", options.iconReplacement.imageBytes)

3. dex aligning part is not efficient

This is not an important issue, but currently, the Manager stores the dex once as unaligned in ReorganizeDexStep, then deletes all the dex and writes it again in the AlignmentStep, this time aligned.
I think this is not efficient and you can write all dex uncompressed and aligned at ReorganizeDexStep.

The zip.deleteEntry() and zip.deleteEntries() functions are slow and these take up most of the time in AlignmentStep.
Reducing the number of the use of deleteEntry can potentially improve speed.

[rushiiMachine]

1. Thanks for the info

2. Where does this info come from?
   I'm looking through a few APKs now and it seems that some image resources are compressed and some aren't. Is alignment actually used?

3. Unfortunately there is no point in writing aligned, since I later delete files physically located earlier in the zip, which breaks alignment.I know that AlignmentStep takes a lot of time, and this is due to inefficient deleting I implemented in my zip lib wrapper. Fixing it right now through isn't really that crucial, so I'll do it later.

[kitadai31]

2. After looking into it further, it seems it's a should, not a must. Sorry.

3. The Discord 126 APK does not seem to break alignment even if you delete files at the front.
In fact, the current Manager removes the classes*.dex and libs/* files at the beginning of the APK, but the alignment of the uncompressed files in res/ that follow is not broken.

Actually, about two months ago, I actually implemented 3. with the intention of sending a pull request, and confirmed that the alignment would not break. (But I lost that code, so here I am opening the issue now...)

In fact, the problem you are concerned about became an actual problem with the Discord 268 APK first.
This confirms that for Discord APKs up to 267, deleting files near the beginning was not a problem.
https://discord.com/channels/1196075698301968455/1205101050739167272/1349929345963131041
bunny-mod/BunnyManager@a5def51