IssueTracker

If the existing file has 4k page alignment, --alignment-preserved will still turn that into 16k unless --lib-page-alignment is set to 4k. That doesn't seem correct to me.

Actually, I was mistaken about the latter. It should indeed preserve existing (non)alignment with --alignment-preserved. It just doesn't make sense for it to forcibly replace all padding -- even when alignment is already correct -- otherwise.

From the apsigner code (src/main/java/com/android/apksig/ApkSigner.java):

        if (inputOffset == outputOffset && mAlignmentPreserved) {
            // This record's data will be aligned same as in the input APK.
            return new OutputSizeAndDataOffset(
                    inputRecord.outputRecord(inputLfhSection, outputLfhSection),
                    inputRecord.getDataStartOffsetInRecord());
        }
        int dataAlignmentMultiple = getInputJarEntryDataAlignmentMultiple(inputRecord);
        if ((dataAlignmentMultiple <= 1)
                || ((inputOffset % dataAlignmentMultiple) == (outputOffset % dataAlignmentMultiple)
                        && mAlignmentPreserved)) {
            // This record's data will be aligned same as in the input APK.
            return new OutputSizeAndDataOffset(
                    inputRecord.outputRecord(inputLfhSection, outputLfhSection),
                    inputRecord.getDataStartOffsetInRecord());
        }

        long inputDataStartOffset = inputOffset + inputRecord.getDataStartOffsetInRecord();
        if ((inputDataStartOffset % dataAlignmentMultiple) != 0 && mAlignmentPreserved) {
            // This record's data is not aligned in the input APK. No need to align it in the
            // output.
            return new OutputSizeAndDataOffset(
                    inputRecord.outputRecord(inputLfhSection, outputLfhSection),
                    inputRecord.getDataStartOffsetInRecord());
        }

The && mAlignmentPreserved condition was added to all 3 if statements in 35.0.0-rc1. It seems to me that this is incorrect for the second one: if the record is already aligned correctly in the input APK and will continue to be aligned correctly in the output APK its padding should not be modified regardless of the value of mAlignmentPreserved, which should only affect the first and third cases which are about preserving non-alignment for records whose offset will not change or that are not aligned in the input APK.

Thus the && mAlignmentPreserved check in the second if statement should be replaced with && (mAlignmentPreserved || (inputDataStartOffset % dataAlignmentMultiple) == 0).

Semi-related: --lib-page-alignment 65536 doesn't work (as 65536 doesn't fit in the short used to store the alignment in the extra field); so, unlike AGP and zipalign, apksigner doesn't support 64K page alignment (except by aligning the APK to 64K beforehand with AGP or zipalign and using --alignment-preserved).

I'm not sure why apksigner is the only tool that doesn't use/support zero padding (which AGP and zipalign use), but maybe it should support that as well, at least optionally and for 64K alignment?

FWIW, zipalign.py supports all the padding and alignment variants I know of (except from the broken zipalign versions from build-tools 31.0.0 and 32.0.0).

(src/main/java/com/android/apksig/ApkSigner.java)