Targeting Android 11 required Signature V2 Signing.

[rupeshkumar22]

Currently, the packages are being exported with Signature V1 signing. According to the official android documentation here -

Apps that target Android 11 (API level 30) that are currently only signed using APK Signature Scheme v1 must now also be signed using APK Signature Scheme v2 or higher. Users can't install or update apps that are only signed with APK Signature Scheme v1 on devices that run Android 11.

There is a need to provide the functionality to export the packages with V2 Signing, But first, need to make sure that it won't create compatibility issues.

Testings are required to verify the exported packages on Android 11 devices or emulators with build target version 11.

Below is one of the methods to check the Signature Version of the packages:

[farhazulMullick]

After a successfull gradle sync why I cannot this application like simple android application on mobile
why I cannot run this appliction like other application on emulator

[rupeshkumar22]

@farhazulMullick Hi, According to what I understand from your comment, Are you trying to build and install 'processing-android' project on an emulator through the Android Studio? If yes then this is not a native android app project which you can run on an emulator. The project builds the Processing Android Mode and related libraries i.e Processing Core, AR, and VR. For more information on building the project, you can refer to this page.
Also, For such queries, I would recommend you to use the official community website of Processing Foundation https://discourse.processing.org/
Thanks

[rupeshkumar22]

References for V2 Signing

Google Source Code for V2 Signing
More About V2 Scheme
APKSigner from SDK.

[codeanticode]

I'd see this is critical because apps built with Processing won't be compatible with Android 11 devices unless V2 signing is supported.

[codeanticode]

@rupesh-kumar-lpu So I incorporated the source code in the Android project for V2 signing:

e89b0ab

The exported signed bundle option now generates the V1 and V2 signed packages without error, however, when I try uploading the V2 signed aab to google play, I get the error "You uploaded a file that is not a well-formed zip archive" even though the aab file seems to be a valid zip file when I unpack it on my computer. So i must be doing something wrong.

Mentioning this just in case you can take a look. Thank you!

[rupeshkumar22]

Hi Andres, it's strange to get that play console error despite the code for the v2 scheme seems alright.
Are we aligning the bundle after signing? Not sure if we really need to align bundle.
I'll try signing unsigned bundle manually with apksigner and will compare the packages.
Last time I generated universal apk from bundle generated from project and that worked fine on devices. I am looking into it and will inform at the earliest.
After resolving this one, major implementation to work on would be to automate publishing of packages on central repository.
Thanks @codeanticode

[codeanticode]

I tried running the zipalignPackage() function on the signedPackageV2:

https://github.com/processing/processing-android/blob/master/mode/src/processing/mode/android/AndroidBuild.java#L799

but it gave an error, so that's why I only apply zipalignPackage to the V1 package right now.

[codeanticode]

Actually the signed_v2.aab was flagged as a corrupted zip file when I tried to upack using the command line tool unzip:

warning [test_release_signed_v2.zip]:  1574306 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [test_release_signed_v2.zip]:  start of central directory not found;
  zipfile corrupt.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)

I was mislead because I before used a GUI tool on Mac that was able to unpack it. When I get the file type with file test_release_signed_v2.zip it is recognized as a Java archive data (JAR)... so I guess the zipping step is what is missing/wrong. Which is actually encouraging :-)

[codeanticode]

@rupesh-kumar-lpu I thought this function was returning chunks already in zip format:

https://github.com/processing/processing-android/blob/master/mode/src/processing/mode/android/ApkSignerV2.java#L199

Since its doing this:

https://github.com/processing/processing-android/blob/master/mode/src/processing/mode/android/ApkSignerV2.java#L278

but maybe not? I will try zipping the resulting buffer, maybe that's the solution, if you have any other ideas please let me know.

[codeanticode]

With this change 67dcfab seems its closer but not quite there yet, because the resulting aab file still not a valid zip file, but the error from unzip is different:

unzip test_release_signed_v2.aab
Archive:  test_release_signed_v2.aab
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of test_release_signed_v2.aab or
        test_release_signed_v2.aab.zip, and cannot find test_release_signed_v2.aab.ZIP, period.

Like it is not properly closed or something (End-of-central-directory signature not found). Any help much appreciated :-)

[rupeshkumar22]

Hi @codeanticode, The APKSigner sources link I shared earlier was for signing APK as we did not have support for AAB at that time. I think apkSigner is only for signing APK, and for signing AAB we need to sign it either using Java JarSigner present in the java bin folder along with javac and java binaries or bundletool / bundletool sources

"If you want to sign an app bundle from the command line, you can use jarsigner. If instead you want to sign an APK, you need to use zipalign and apksigner as described below."
The above is mentioned here officially on Android Docs

We can also use the java implementation of JarSigner JarSigner.java from open JDK or directly execute the binary by process builder task(Seems a faster option to implement)

Let me know your views on implementing @codeanticode @ranaaditya
Thanks!

[codeanticode]

Ok I see, aab is actually a different file format from apk, as far as I can tell from Google's official docs and other online resources, is that right? I missed that fact originally.

In any case, I think that it could be better just to use the JarSigner & bundletool from the JDK/Android SDK respectively. Sounds like executing their binaries with a process builder task from the Android mode should work, since JarSigner is included in the copy of the OpenJDK bundled with Processing, and I'd imagine that bundletool comes with the Android SDK download as well.

[rupeshkumar22]

Yes, it's a different format I also missed the fact, and yes bundle tool is included in SDK as well. Can I start working on it with process builder if you are not working on the same? @codeanticode

[codeanticode]

@rupesh-kumar-lpu yes if you could look into it, it would be amazing, thank you! I'm trying to at least push one last update of the Android mode for Processing 3 including this and few other critical updates before switching to support the Android mode only for Processing 4.

[rupeshkumar22]

It's great to know Android Mode is moving to Processing 4. I am looking forward to working on the current signing implementation.

[codeanticode]

Awesome! Maybe you can start by assembling the command line calls using JarSigner and bundletool needed to generate the signed packages, so then we can figure out how to properly run using the process builder from the mode itself.

[codeanticode]

V1 signing seems to be enough once setting target SDK to 30:

[codeanticode]

The signing can be done as part of the Gradle build task, see this example:

https://medium.com/automating-react-native-app-release-to-google-play/create-upload-key-and-apps-release-bundle-aab-file-4bf4a17e19a1

Implemented with this commit 11865cd