Topic: Android - Support 16 KB page sizes

[gicci]

In Android 15, Google will introduce the support for 16 KB page sizes and is planning to make 16 KB page compatibility required for app uploads to Play Store next year.
It isn't something super urgent, but currently on an emulator configured with 16 KB page sizes my app crashes when trying to load Bass shared libraries.
Full details on the topic and on the required changes are here: https://developer.android.com/guide/practices/page-sizes
Thank you 

[AlexU]

I confirm this issue.

[Ian @ un4seen]

I haven't tested this myself yet, but if you would like to try it, here's a build using the LOCAL_LDFLAGS setting mentioned in the guide linked above:

   www.un4seen.com/stuff/bass-android-16k.zip

The guide suggests that the LOCAL_LDFLAGS solution won't work with libc++_shared.so, so I've also included a build of that and the BASSAPE add-on (which uses it) for you to try.

[AlexU]

I'm sorry, but it doesn't work on my end on the emulator.
BASS.BASS_ChannelIsActive(mBassChannel) always returns BASS.BASS_ACTIVE_PLAYING

[Ian @ un4seen]

That sounds like a strange issue. Is the new library loading OK while the release version isn't? But the new library also has that BASS_ChannelIsActive issue while the release version doesn't (in other emulators)? In either case, please post some bare-bones code to reproduce the problem with.

[gicci]

I would like to test this build, but it seems that it is missing the libbassmix library.
Shall I use the shared libraries as well?

[Ian @ un4seen]

A BASSmix build has now been added to the package above. Let me know if you have any trouble with it.

[Nicholas]

I was coincidentally just going to start testing 16KB pages on Android, too.  Would it be possible to also include arm64-v8a versions of the libraries in your testing build?

The long version: at least on my machine, Google's own x64 emulator for the 16KB page size test is still reporting 4KB pages through adb ("getconf PAGE_SIZE") for whatever reason.  And the 4KB-page version of my app runs on that emulator just fine (when it shouldn't).  Next, I tried (and failed) to get their Cuttlefish emulator up and running.  As a last resort, I just got Android Studio up and running on an M1 Mac.  The 16KB test emulator on that (arm64) platform does show 16KB pages correctly and my app crashes as expected.  With 16KB-page versions of BASS and BASSMIDI built for arm64, hopefully it'll run successfully.  Thanks!

[Ian @ un4seen]

arm64-v8a builds of BASS and BASSMIDI (and BASSmix) have now been added to the package above, so please re-download that to get them.

[gicci]

At least on my machine, Google's own x64 emulator for the 16KB page size test is still reporting 4KB pages through adb ("getconf PAGE_SIZE") for whatever reason.  And the 4KB-page version of my app runs on that emulator just fine (when it shouldn't).

There is a bug in the emulator (https://issuetracker.google.com/issues/356176653) with the following workaround now listed in the "Support 16 KB page sizes" page (https://developer.android.com/guide/practices/page-sizes):

Warning: in order to simulate 16 KB on x86_64, you need to follow extra steps. In the Device manager, click the 3 dots next to the 16 KB image, and click "Show on Disk". In this folder, you can find the config.ini file. Add kernel.parameters = androidboot.page_shift=14 here. This extra step will be removed soon. Then adb shell getconf PAGE_SIZE should return 16384.

I tested with that workaround applied on X86_64 and with the original libraries the app does not start, while it seems to work with the ones provided with the link.

[Nicholas]

There is a bug in the emulator [...] with the following workaround now listed in the "Support 16 KB page sizes" page...

Ha!  They buried the note at the very bottom of the page way after the section about running "getconf".  Thanks for pointing me to the answer.  That fixed it for the x64 version of the emulator.

arm64-v8a builds of BASS and BASSMIDI (and BASSmix) have now been added to the package above...

As always, thanks for your unreasonably prompt attention!

I can confirm the same as gicci: at least for BASS and BASSMIDI, the 16KB page versions seem to work in every situation, old and new on both arm64 and x64.  Contrast that with the current, official (4KB page) Android build of the libraries which crash the app during launch when the OS is running with a 16KB page size.

I suppose the only question I have left is whether I can help test anything else before this version is released officially?  Thanks again!

[Ian @ un4seen]

Good to hear that the updated builds are working well so far. One thing I'm still unsure about is whether more needs to be done for the shared C++ standard library (libc++_shared.so). Most of the BASS libraries don't use the C++ standard library, but a couple add-ons do, and some such builds are included in the "c++_shared" dir of the package. It would be good if you could test them too. I've also added builds for the other archs, if you would like to check that they're still working properly.

   www.un4seen.com/stuff/bass-android-16k.zip

[Nicholas]

I've never used it, so is there a particular feature in the BASSAPE API that I should run to confirm that the libc++ interactions are happening correctly? (Say, something beyond the initial library load at startup)?  Would it be enough to have a BASS_APE_StreamCreateFile come back with a non-zero return code?  What is libtags.so doing in there?  Is that also required?

Out of curiosity--I've always been impressed that BASS has essentially zero dependencies--what was it in particular in BASSAPE that finally needed something from the standard library?

[Ian @ un4seen]

Yeah, just loading and playing an APE file should be good enough I think.

The BASSAPE add-on requires the standard C++ library because the incorporated decoder from the Monkey's Audio SDK does. The TAGS add-on is the other one that uses the standard C++ library, so that's why it's also included in the package above. It uses more stuff from the standard C++ library than BASSAPE does, so perhaps provides a better test. You can test it something like this (with a file that has a title tag):

Code: [Select]

String title = TAGS.TAGS_Read(stream, "%TITL");


[Nicholas]

Alright, sorry for the wait on this.

I was able to get a test up and running where I'm reading some title tags from a couple files and I'm loading+playing an APE file.  It works just fine on a normal device with 4KB pages, but when I tried it in the 16KB page emulator it crashed during library load.

Double-checking the .so files (with "objdump -x libwhatever.so") it looks like the libc++_shared.so files in your package are still compiled with 4KB alignment.  In the output from objdump we're looking for all three of the "LOAD" sections to show "align 2**14" at the end of each line.  They do for libbass, libbassmidi, libbassape, and libtags, but for both the x64 and arm64 versions of libc++_shared it shows "align 2**12" instead.  (Here the "**" is a stand-in for the exponentiation operator.  2^12 = 4K and 2^14 = 16K.)

If you can produce versions of libc++_shared.so where it shows 16KB alignment with objdump, I suspect this will work.

EDIT: This is most likely my fault.  Working on it now...

[Nicholas]

I got a little farther.  (I hadn't realized libc++_shared was provided by Android Studio when you told it to use the shared version of the STL.  My app has always been built against the static version because my only outside dependencies are bass+bassmidi which don't require any STL.)

Curiously, once I link against the shared STL provided by NDK v27.0.12077973, the libtags from your bass-android-16k.zip will segfault inside TAGS_ReadEx the first time I call either API.  This is everywhere I tried, including with 4KB pages and on a real device.

If I remove the libtags part of my test (which was working fine before I switched from the libc++_shared in your zip to the libc++_shared provided by NDK v27), then the libbassape portion of my test seems to work fine everywhere including the 16KB page emulator.

Trying to narrow things down, I just tried the official v19 release of libtags (without 16KB page support) on a real arm64 device and it crashed in the same place:
#08 pc 000000000000ec38  libtags.so (offset 0x934000) (TAGS_ReadEx+100) (BuildId: c3a2eded5e10caee5312af70968bcf8d41a25af1)

Do you know if there are any known issues in libtags when using it with newer versions of the NDK?

[Ian @ un4seen]

I tried building the TAGS add-on with various NDK versions and combining them with the libc++_shared library from other NDK versions, to see what worked. And it seems like there's a compatibility-breaking change between NDK r22 and NDK r23: when the TAGS add-on is built with NDK r22, it doesn't work with later versions of libc++_shared, and when built with NDK r23, it doesn't work with older versions of libc++_shared.

NDK r22 is currently used to build the BASS libraries, including these "16k" updates. I have now put TAGS and BASSAPE builds from the latest "canary" NDK r23 (linked in the 16k guide) in the "c++_shared" folder of the "16k" update package. Don't really want to have to go any higher than NDK r23 because later versions require/assume NEON support in armeabi-v7a builds, while the BASS libraries detect NEON at run-time to use it only when available.

   www.un4seen.com/stuff/bass-android-16k.zip

These updates haven't been tested much yet, so please report what you find.

[Nicholas]

Well, for what it's worth, that latest build seems to be working correctly wherever I've tried it: bass, bassmidi, bassape, and tags on arm64 (4KB pages) and x64 (16KB pages).

The same code that was crashing in TAGS_ReadEx began working properly just by swapping out the .so files, so that's more evidence it was the NDK v22 to v23 breaking change you found.  That type of unstable platform stuff where you have to start jumping through more hoops and keeping track of more things is the worst!  Really, this 16KB page stuff is already in that category of unnecessary megacorp-imposed effort.  I can commiserate and am sorry that Google (and Apple and Microsoft) routinely inflict this type of thing on us.

With my satisfaction that these 16KB page size builds seem to be working correctly (especially bass+bassmidi which is all I use and which don't require the shared STL), would you advise that it's safe enough to release an app update with them?  Or would it be better to wait for the upcoming official release for whatever reason?  Would anything else change in an official build?  Thanks again!

[Ian @ un4seen]

I think these "16k" builds should be fine to use for now.

Assuming all continues to be good with the NDK r23 builds, upon release, I'll add a note in the TAGS add-on docs that NDK r23 or above is required when using the "c++_shared" build.