Adobe-Runtime-Support icon indicating copy to clipboard operation
Adobe-Runtime-Support copied to clipboard

Android 16kb page requirement

Open hardcoremore opened this issue 6 months ago • 3 comments

@ajwfrost What are you thoughts on this?

https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html

Is this going to be a problem?

hardcoremore avatar May 09 '25 13:05 hardcoremore

Hi

This shouldn't be a problem, we already support 16kb / variable virtual memory page sizes (had to make some changes a while ago, for Raspberry Pi iirc). Internally AIR has a memory management system that should configure itself based on what the OS reports as the page size - we will just need to make sure that the Android builds are correctly hooking up with this value, and see whether there are any other packaging updates to make.

I'll ask one of the team to do the testing/validation as outlined in that article..

thanks

ajwfrost avatar May 12 '25 10:05 ajwfrost

That are great news! Thanks @ajwfrost

hardcoremore avatar May 12 '25 11:05 hardcoremore

Hi

We've done further analysis on this. The internal memory management within AIR is already able to use 16kb virtual memory page sizes, we've confirmed that part which is the big/concerning area that could have been problematic. We're just checking on the zip alignment things but that's something that should be solved by using an appropriate version of the AGP, which is a relatively trivial thing for us to change for the default settings (and can already be overridden by developers).

The 32-bit .so files are not showing as 16kb-aligned but we don't know that this is a problem (the documentation just says that it's a problem if arm64-v8a or x86_64 binaries are not 16kb-aligned...).

The other slight question is that although our binary is 16kb-aligned, it may be linking to a shared library that may not be, from an early Android NDK. So we're still doing some further validation on this. They've apparently got some 'canary' versions of the shared library available to work around this.

But - regardless - we are also wondering if it's time to do an update and move up to a newer NDK. Until now we've stuck with the (very old) version of NDK that we've used for building with, because we had needed to support older devices. Now that we've set Android 21 as a minimum version, it means we can actually upgrade to a newer NDK, CMake (and Gradle/AGP) versions - which would mean that all of this becomes academic, the whole toolchain is already configured to ensure it will work on the 16kb page size Android devices. So this might be the simpler option to just be a bit more sure that everything is ready and configured how Android actually want us to have it!

thanks

ajwfrost avatar Jun 02 '25 15:06 ajwfrost

To ensure your app is all compatible with the various 16kb-related updates, there are a number of changes you can make in the environment/configuration and app descriptor file, which should result in a build that is suitable for Play Store deployment to these devices.

  1. The library files .. appear to already be okay (but we are going through a general update in all our build environments per the above). But the tools Android are providing show that the 64-bit libraries are all 16kb-aligned already.

  2. To ensure the .so files are not compressed when they're packaged, you can use the adt.cfg file UncompressedExtensions setting, or the app descriptor uncompressedExtensions value, to include so in the comma-separated list of file extensions to not compress.

  3. To ensure the .so files are aligned appropriately within the zip file, build with a minimum of AGP 8.5.1. You can do this via the androidGradlePluginVersion app descriptor entry, and also update the Gradle version and set the build/compile values... e.g.:

     <gradleVersion>8.7</gradleVersion>
     <androidGradlePluginVersion>8.5.1</androidGradlePluginVersion>
     <androidBuildToolsVersion>35.0.0</androidBuildToolsVersion>
     <androidCompileSdkVersion>35</androidCompileSdkVersion>
  1. Plus of course you need to be targeting the Android API level of 35, and have the 35.0.0 build tools installed (via Android Studio's SDK Manager, or the command-line equivalent if you prefer). So e.g. include in the manifestAdditions the line: <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="35"/> within the <manifest> section.

This should create an appropriate output.. if not, please let us know and we can investigate further.

Bear in mind though that if you create a bundle (aab) file, then if you generate an APK file from that, it won't be appropriately aligned (the bundletool tool doesn't appear to support the automatic zip-alignment?) - you can adjust the output zip using the below command, see https://developer.android.com/tools/zipalign

zipalign -P 16 -f -v 4 infile.apk outfile.apk

You will then need to use apksigner to re-sign the APK file.

Hope that helps! As mentioned, we are preparing a build that switches to all these values as defaults, but it should still be possible to configure everything per the above to get a conformant release package.

thanks

ajwfrost avatar Jul 02 '25 08:07 ajwfrost

Hi @ajwfrost - Is it also possible to make these changes in the 33.1.1.935 SDK as well. Some of us haven't felt the need to upgrade to the later versions yet. Thanks.

manishpatel0404 avatar Jul 02 '25 13:07 manishpatel0404

@ajwfrost
AIRSDK_Windows 51.2.1.6

Image

The following error occurred: error 105: application.android.uncompressedExtensions contains an invalid value

Additionally, the settings you provided for building API 35 only work when building AAB, not when building APK.The version used is AIRSDK_Windows 51.2.1.6 ver.

pengyangjin avatar Jul 03 '25 08:07 pengyangjin

Hi

Yes we just found the same error in that app descriptor tag; there's a release we've just kicked off to fix that... so in the meantime please use the configuration file to add the 'so' extension to UncompressedExtensions.

But the other changes should be valid regardless of what you build: we basically generate an Android gradle project structure - in the same way for aab and apk (and android-studio) targets - and then trigger the build from gradle. I just ran it here and the APK file looks like it's built with the right tools/versions etc, and has the right zip packaging/alignments etc.

I do get a few warnings, having just updated Android Studio:

  • it's now embedding Java 21, and the 1.8 Java compatibility flags are obsolete now..
  • it says that AGP 8.5.1 was only test up to compileSdk 34, so recommends that to be updated (so I guess we could have compile versions of 34, with target version of 35..? or else just move to later Gradle/AGP versions now...)

Can you build the APK whilst looking at the AIR SDK Manager's "troubleshooting" tab, to see what's happening in there?

thanks

ajwfrost avatar Jul 03 '25 09:07 ajwfrost

Is it also possible to make these changes in the 33.1.1.935 SDK as well. Some of us haven't felt the need to upgrade to the later versions yet. Thanks.

@manishpatel0404 I will check this: we don't support the flags in the app descriptor file until 50.0 but we could perhaps update the default values that it uses in order to create a 33.1.2 version that can be compatible with this...

ajwfrost avatar Jul 03 '25 09:07 ajwfrost

Hi

Yes we just found the same error in that app descriptor tag; there's a release we've just kicked off to fix that... so in the meantime please use the configuration file to add the 'so' extension to UncompressedExtensions.

But the other changes should be valid regardless of what you build: we basically generate an Android gradle project structure - in the same way for and (and ) targets - and then trigger the build from gradle. I just ran it here and the APK file looks like it's built with the right tools/versions etc, and has the right zip packaging/alignments etc.aab``apk``android-studio

I do get a few warnings, having just updated Android Studio:

  • it's now embedding Java 21, and the 1.8 Java compatibility flags are obsolete now..
  • it says that AGP 8.5.1 was only test up to compileSdk 34, so recommends that to be updated (so I guess we could have compile versions of 34, with target version of 35..? or else just move to later Gradle/AGP versions now...)

Can you build the APK whilst looking at the AIR SDK Manager's "troubleshooting" tab, to see what's happening in there?

thanks

I received a warning from Google Play that applications must be compiled with API 35 or above before August 31st.I am currently working on this adaptation.Packaging APK files still cannot be compiled using API 35.

pengyangjin avatar Jul 03 '25 09:07 pengyangjin

Packaging APK files still cannot be compiled using API 35.

I would be interested to know what problems you are having with that?

But the requirement from Android for the Play Store is to target the API 35 so you should be able to conform if you just add to your manifest additions:

<uses-sdk android:minSdkVersion="21" android:targetSdkVersion="35"/>

thanks

ajwfrost avatar Jul 03 '25 10:07 ajwfrost

the apk compile with this configuration does not using api 35, but still uses api 34.Takes effect only when compile an aab file.

---Original--- From: "Andrew @.> Date: Thu, Jul 3, 2025 18:41 PM To: @.>; Cc: @.@.>; Subject: Re: [airsdk/Adobe-Runtime-Support] Android 16kb page requirement(Issue #3800)

ajwfrost left a comment (airsdk/Adobe-Runtime-Support#3800)

Packaging APK files still cannot be compiled using API 35.

I would be interested to know what problems you are having with that?

But the requirement from Android for the Play Store is to target the API 35 so you should be able to conform if you just add to your manifest additions: <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="35"/>
thanks

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

pengyangjin avatar Jul 03 '25 10:07 pengyangjin

How are you telling what API level it has? If you open the APK in Android Studio (build -> analyze APK) and look at the AndroidManifest.xml file, you should see the uses-sdk tag in there the same?

I've just been re-reading the requirements, it looks like also "The value of targetSdk must be less than or equal to that of compileSdk" but with everything set up per the above, my APKs show a uses-sdk targetSdkVersion version of 35...

thanks

ajwfrost avatar Jul 03 '25 13:07 ajwfrost

How are you telling what API level it has? If you open the APK in Android Studio (build -> analyze APK) and look at the AndroidManifest.xml file, you should see the tag in there the same?uses-sdk

I've just been re-reading the requirements, it looks like also "The value of targetSdk must be less than or equal to that of compileSdk" but with everything set up per the above, my APKs show a uses-sdk targetSdkVersion version of 35...

thanks

Image

target sdk is 35 ,but compile sdk is 34

pengyangjin avatar Jul 03 '25 13:07 pengyangjin

@pengyangjin is it possible to get your APK file so we can check this, as well as the adt.log (or AIR SDK Manager's "troubleshooting" output) from when you build it? Upload link: https://transfer.harman.com/requests/jJIXV2BiodDekVS1YLqmuB thanks

ajwfrost avatar Jul 05 '25 06:07 ajwfrost

Anyone using the new SDK 51.2.2.1 are having trouble starting the app and it closing instantly?

lwmirkk avatar Jul 22 '25 22:07 lwmirkk

@lwmirkk on Android, with an app descriptor namespace of 51.2? Yes we found this yesterday.. our test cases were still using an older namespace so we hadn't picked this up initially. We'll create a new release shortly, in the meantime please use the below patched version of ADT (unzip into the SDK's "lib" folder):

adt_51.2.2.1.patch.zip

ajwfrost avatar Jul 23 '25 05:07 ajwfrost