It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

I don't know much of anything here, but I do wonder if this change could have other implications. Could this break running Flutter on older devices? (edit: lots of typos; good grief)

Also, even with this PR landed, would the issue reported here persist? Specifically, it would occur instead when we try to load the engine binaries (I don't know what the page size there is), no?

@reidbaker (cc @dcharkes)

@zanderso I think you are the most knowledgeable flutter engineer when it comes to 16kb page sizes.

Reading up on this, requiring 16kb alignment of elf sections makes sense. I wouldn't worry about that breaking older devices, but it might add some kilobytes to the compiled binary.

In general, fixing compilation settings in the CMake file for plugin_ffi sgtm. Is this a NOOP for other operating systems? The CMake file is shared across all OSes. If not, we'll probably want to guard in the CMake file on target OS.

Also, we should have a test. Since Android 15 is not yet out, I suppose we don't have devices/simulators in our devicelab @reidbaker?

And note to self: We also need to fix this in --template package_ffi and/or package:native_toolchain_c.

Reading up on this, requiring 16kb alignment of elf sections makes sense. I wouldn't worry about that breaking older devices, but it might add some kilobytes to the compiled binary.

In general, fixing compilation settings in the CMake file for plugin_ffi sgtm. Is this a NOOP for other operating systems? The CMake file is shared across all OSes. If not, we'll probably want to guard in the CMake file on target OS.

Also, we should have a test. Since Android 15 is not yet out, I suppose we don't have devices/simulators in our devicelab @reidbaker?

And note to self: We also need to fix this in --template package_ffi and/or package:native_toolchain_c.

Android 15 is out for developers and we have updated the api levels the engine/framework can call to api 35 (android 15). We dont have emulator support in CI yet because, last we checked, launching api 35 emulators was more unstable than our flake budget.

@dcharkes I am very open to feedback on how we should test. This class of bug stretches what I am comfortable reviewing.

@dcharkes @zanderso do we also need to build the engine with 16kb page size alignment?
https://source.android.com/docs/core/architecture/16kb-page-size/16kb

Maybe we could get our hands on a phone that has an Android 15 beta with the 16kb memory pages and try it locally to see if things work yes or no. If we then verify what changes are needed (for both the engine and plugin_ffi and package_ffi) we could land these without enabling Android 15 tests yet on the CI and leave an open bug for ourselves to enable tests when we deem such infra stable enough. (This is not super satisfactory from a test coverage point of view, but enables us to preempt users running into this being completely not fixed/tested. I presume that once we make the necessary changes to the compiler settings in various places, we're unlikely to break those settings in the meantime.)

I feel fine reviewing an extra compiler flag in a build file after reading what it does, but I would want us to at least locally verify it for ourselves on an Android 15 with 16kb memory pages for ourselves.

I feel fine reviewing an extra compiler flag in a build file after reading what it does, but I would want us to at least locally verify it for ourselves on an Android 15 with 16kb memory pages for ourselves.

You can also use an emulator: https://developer.android.com/guide/practices/page-sizes#test

Maybe we could get our hands on a phone that has an Android 15 beta with the 16kb memory pages and try it locally to see if things work yes or no. If we then verify what changes are needed (for both the engine and plugin_ffi and package_ffi) we could land these without enabling Android 15 tests yet on the CI and leave an open bug for ourselves to enable tests when we deem such infra stable enough. (This is not super satisfactory from a test coverage point of view, but enables us to preempt users running into this being completely not fixed/tested. I presume that once we make the necessary changes to the compiler settings in various places, we're unlikely to break those settings in the meantime.)

I feel fine reviewing an extra compiler flag in a build file after reading what it does, but I would want us to at least locally verify it for ourselves on an Android 15 with 16kb memory pages for ourselves.

I am happy to setup a 16kb page emulator and test this pr (if someone has example code ready to compile I would be grateful). I my question around testing was more about what does a unit test or non integration test look like for this class of change.

For package_ffi: flutter test test/integration.shard/isolated/native_assets_test.dart.
For plugin_ffi: flutter create --template=plugin_ffi ... && cd xx/example/ && flutter run -d ... (I don't know which test does this by heart.) @huanglizhuo is this what you did to reproduce it?

Sometimes the emulators don't behave the same way as devices. So I'd only feel comfortable landing a fix if we can first reproduce the error on the emulator without the fix.

lutter test test/integration.shard/isolated/native_assets_test.dart

Thank you I am working on getting an emulator setup now with 16kb page sizes.

running flutter test test/integration.shard/isolated/native_assets_test.dart from flutter/packages/flutter_tools/ on a tablet setup using the android 16kb page size instructions.
Confirmed by running adb shell getconf PAGE_SIZE returning 16384.
All tests pass without this change.

flutter test test/integration.shard/isolated/native_assets_test.dart
09:39 +22: All tests passed!

Using the following commands I tested on several different emulators.

flutter create --template=plugin_ffi android_page_size 
cd android_page_size
flutter create -t plugin_ffi --platforms android android_ffi
cd android_ffi/example
flutter run

Flutter red screen with error text listed in this pr description

• Android 35 tablet with 16kb page size (same emulator that had the integration tests pass)
• sdk gphone16k arm64 (mobile) aka emulated pixel

Normal template app behavior

• Pixel 8 pro

Next step is to patch this pr and try again on the failing devices.

Confirmed that after patching this pr and regenerating a test app all previously broken emulators show the example code correctly.

diff --git a/android_ffi/src/CMakeLists.txt b/android_ffi/src/CMakeLists.txt
index 8867fa5..fb58e86 100644
--- a/android_ffi/src/CMakeLists.txt
+++ b/android_ffi/src/CMakeLists.txt
@@ -15,3 +15,6 @@ set_target_properties(android_ffi PROPERTIES
 )

 target_compile_definitions(android_ffi PUBLIC DART_SHARED_LIB)
+
+# Support android 15 16k page size
+target_link_options(android_ffi PRIVATE "-Wl,-z,max-page-size=16384")
\ No newline at end of file
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 09a3dcc..1d776b3 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -15,3 +15,6 @@ set_target_properties(android_page_size PROPERTIES
 )

 target_compile_definitions(android_page_size PUBLIC DART_SHARED_LIB)
+
+# Support android 15 16k page size
+target_link_options(android_page_size PRIVATE "-Wl,-z,max-page-size=16384")
\ No newline at end of file

@dcharkes @HosseinYousefi Do you think a migrator needs to be written for apps that use ffi?
Also if we can find the test that verifies the plugin_ffi template launched successfully then I would say that this feature will be tested when the android team migrates to api 35 emulators.

flutter/packages/flutter_tools/test/integration.shard/android_plugin_example_app_build_test.dart I think is the test that checks plugin_ffi.

I think a simple test can be written for this by modifying test/commands.shard/permeable/create_test.dart to check for the new flags in the cmake file.

@huanglizhuo I hope you don't mind I added a test for this change.

@dcharkes holding this merge on your approval and thoughts on if this needs a migrator in addition to the template change.

Related to #149836