Android Question The Android App Bundle was not signed

Erel said:

No. There are no benefits for AABs. At least not with B4A. If you want to waste your time and energy then ask Google to upgrade your key (the old key isn't compatible with their new requirements). Eventually the result will be exactly the same.

Bottom line:
1. If using old key - submit an APK.
2. If using new key - add the #SignKeyAlgorithm

Click to expand...

Thank you very much for your time and effort

There is a typo on top announcement
B4A developers:

Thank you! Will fix.

Anyone can check with app has native lib (has some .so files in library). I check with local apk test is ok, but when upload as aab and sign new way,and download app from Google Play to test it, these library is error (UnsatisfiedLinkError )
AAB is better than APK is for native lib , but now i has this error, i think has some problems here...

p/s: now i can update new aab without
#SignKeyAlgorithm: -digestalg SHA-256 -sigalg SHA256withRSA

(early version i use it to fix can not upload aab , but new version i can upload without it)

I will wait for review and test if native lib can work can cofirm it! Thank you

Edit new:
After live on Google play, aab with native library will crash (

Continue edit: may be relinker library used by B4XGifView make this problem, i will remove it from my app and try again!


===> Relinker aar make our library crashs , not related with signed AAB
Now can use without #SignKeyAlgorithm: -digestalg SHA-256 -sigalg SHA256withRSA too, Google already allow it!

Google answered my ticket.
It took a while because the first answer was just showing that who wrote it didn't read or understand the question.
The second answer contains some technical information that I'll never use but can be interesting for someone.
I put it here, omitting the not useful text:
--------------------------------------------------
To verify the key that each package is signed with, please try the following:

1. Ensure that you have the JDK v6 or higher installed.
2. Extract the CERT.RSA file from the META-INF folder of your AAB. (Note: you can change the file type from .aab to .zip and extract the entire app).
3. Run the following command on the CERT.RSA file:
   $ keytool -printcert -file CERT.RSA
   Alternatively, if you are using Android Studio and have version 24.0.3 or higher of the Android SDK Build Tools, you can use the apksigner tool.
4. To get the certificate information, please use the following command (replace package.aab with your file name):
   $ apksigner verify -print-certs -v package.apk

Next, compare your keytool/apksigner results to the error message you received in the Play Console.

• If the SHA1 results are different, the keys do not match. You'll need to sign the new AAB with the correct keystore in order to upload your new version to Google Play.
• If the SHA1 fingerprints match, you should be able to upload the AAB.

You can visit the Android Studio Help Center for more information about signing your app.
Alternatively, we can reset your upload key with a new keystore and you'll need to sign the AAB with the newly generated keystore.

Erel said:

... If you are using an old key then you can probably still upload an APK instead of AAB. ...

Click to expand...

Just tested.
Old key --> Subject Public Key Algorithm: 1024-bit DSA key
apk upload was accepted for updating an old existing app.

fredo said:

Just tested.
Old key --> Subject Public Key Algorithm: 1024-bit DSA key
apk upload was accepted for updating an old existing app.

Click to expand...

My b4a keystore entry used SHA256 with 1024-bit DSA key.
Earlier, I tried to upload the .apk but rejected by Google as .aab required; this was an attempt to do a new release on an older app in mid Sep (today).
I worked through the steps as documented, but "Your app signing key's encryption strength does not meet Google Play's recommended minimum standard". [please note my next post, solved].
I selected to upgrade my app key, but I'm unsure: if I select "Let Google Play..." how do I then sign my app in B4A, with the old 1024-bit DSA key, assuming the google-server-stored key will replace it when uploaded with the newly generated upload key? Or must I choose "Upload a new app signing key from Java keystore" and manually generate a new one with 2048-bit RSA, update my local keystore, rebuild the app with it, generate the .aab, upload, and release ?

I elected to forge ahead using "Upload a new app signing key from Java Keystore". I'm writing this post because the play store requested to use the following pepk command:
My jdk-14.0.1 installation java with that pepk.jar gave an error "java.lang.IllegalArgumentException: Unrecognized flags: {signing-keystore=...".
I added the parameter --signing-key-alias=myalias and then it proceeded to prompt for the passwords and succeeded.

As a test I tried to upload the .aab signed with the earlier 1024-bit DSA key to see if the above step no longer required B4A IDE signing, but it rejected it as not matching the new key. So I switched to the new 2048 RSA key and regenerated/signed the .aab, and it then uploaded with success.