Yes, its true. I have also tried with some extension. What I found is
Case 1: Libraries with a Flexible Path
If a library has a method like Library.loadModel("path/to/model.tflite"), we can use this perfectly. We sould place the model in our extension's assets/path/to/ folder. The build server would place it at assets/your.package.name/path/to/model.tflite. Then, from our extension's code, we would simply call Library.loadModel("your.package.name/path/to/model.tflite"). This is a very common and fully supported scenario.
Case 2: Libraries with a Simple, Root Path
If a library is hard-coded to look for a file directly in the root, like assets/config.json, the solution is trivial. We just upload config.json to the App Inventor Designer's media assets. The build server will place it at assets/config.json, and the library will find it without any issues.
Case 3: Libraries with a Hard-Coded, Nested Path
This is the real problem we need to solve to make this implementation scalable and complete(in my opinion). This happens according to my tests when
A library is hard-coded to look for assets/some/library/file.json.
The App Inventor build server, via AttachCompAssets.java, insists on placing our extension's assets inside a namespaced folder, resulting in assets/your.package.name/some/library/file.json. It just ignore the aar assets it gathered in last steps. It is aware that it has assets from aars but ignored.
The library looks in one place; the build server puts the file in another. The two are incompatible.
@JEWEL has a PR for fixing this. Please Sir @ewpatton, can you please take a look. If it's okay, we should merge this and if it has any conflicts guide us so we can work to resolve those conflicts and have this PR merged in nb202.
I think it's too late for this PR. NB202 will be released tomorrow. But there's nothing stopping it from being added to the next version. The temporary, incomplete solution that's being implemented will allow for adding AAR libraries without native libraries and asset files, which will already allow for the implementation of some extensions.
Status bar & Navbar color on Android 15+
On Android 15+, the status bar and navigation bar colors can no longer be customized (changed) via an extension (such as TaifunTools) since App Inventor released the new targetSdkVersion 35 yesterday (August 17, 2025). Customization can only be made in the AI2 designer via "Project Properties" > "Theming" > "PrimaryColor." However, this will customize the status bar and navigation bar with the same color at the same time.
This might be a challenge even for our top extension developers. @Taifun@Kumaraswamy@Patryk_F @ etc... → @extension_developers
Brief explanation:
On Android 15+, apps are displayed in "edge-to-edge" mode: The app content extends across the entire screen, and Status bar and Navbar become (semi)transparent. Methods like window.setStatusBarColor() or window.setNavigationBarColor() are ignored.
Why is the minSdkVersion still 7 (Android 2.1) for the Companion app (after the targetSdk 35 update)? For apps compiled with AI2, the minSdkVersion is now 14 (Android 4.0.1). @ewpatton
I have got about halfway with this, can set the statusbar or nav bar colours (but they currently overwrite each other, or one makes the other transparent), and the status bar "background" sometimes gets added to the bottom of the status bar, doubling its height. Other strange behaviours also occur when hiding status,nav and title bars... I could do with "cleverer" eyes on it...
The way to do it, I don't know, is to create an .xml file that replaces or substitutes that property in styles.xml, possibly with Jetpack Compose, but that's a bit far off. I tried to recreate the color change in the bars, very similar to the app that has internal themes, using the activity.recreate() method, but well... it was ignored in Android 15... I think the app needs to be adapted first
But once compiled or before?
Didn't it require root permissions to modify the apk files?
And if it's before, I don't think the extension will reach that level, since the permission it's given is like a guest on the platform. AI2 would have to provide a way to change the xml to its own, otherwise the default would always be integrated when compiling.
Hmm, because I tried to do something similar to a temporary replacement and Android 15 rejects it, but later versions of Android work well with the idea you mention. Maybe I'm missing something else.
From the extension level, i.e., before compiling the APK. Additionally, recompiling the extension is not required when changing colors. You can use a script, such as JS, to edit the color in the compiled extension.
