I'll see what we can do but the AAPT output is already pretty ridiculous in its verbosity.
I think we can only display the error message if it occurs. Compilation logs are not needed. I think this will be helpful once we can add dependencies from the AAR.
These are sample errors from the console.
[java] C:\Users\Patryk\AppData\Local\Temp\1755267374753_9214396759987929088-0\youngandroidproject\..\build\intermediates\res\merged\layout\media3_notification_template_media.xml:41: error: Error: No resource found that matches the given name (at 'layout' with value '@layout/notification_media_cancel_action').
[java]
[java] C:\Users\Patryk\AppData\Local\Temp\1755267374753_9214396759987929088-0\youngandroidproject\..\build\intermediates\res\merged\layout\media3_notification_template_media_custom.xml:88: error: Error: No resource found that matches the given name (at 'layout' with value '@layout/notification_media_cancel_action').
I got stuck in an error loop trying to drag in a Clock from the Designer search result in a new project.
All the Project had was a slider (full width) and a Notifier.
(I wanted to see how the new log would show slider drag timing.)
Here's the prequel, leading up to the bug:
Here's the Project aia:
slider_log.aia (1.1 KB)
Dragging in a Clock from its home in the Sensors Drawer works okay, so I am guessing the problem is with the search box filtered result.
Thanks for the report. I've been able to replicate this on my end.
I was able to test the new console logging feature:
The log appears under the new Toggle Console button.
Unfortunately, new entries are added at the bottom, and there is no scroll bar, making new entries unreachable.
Attempts at scrolling result in the entire Designer screen being pulled down, without exposing the bottom of the console log.
I've implemented a fix for that.
This pull request is intended to address this issue. It would be great if we could get it with nb202.
mobilefuse-sdk-mraid-1.9.2.aia (133.6 KB) (AAR)
For example, this library read its assets like below:
Unfortunately, the existing system does not merge resources in this manner.
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.
The nb202 update is looking half baked, for Companion availability.
There's an scan code but no link for us desktop users:
This was taken on ai2 server at 10:40 PM EST
Polar bear in a snow storm
I'm using the classic theme.
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.
I have added the Companion download link to this board's Canned Replies, for those who need it.
https://ai2.appinventor.mit.edu/companions/MITAI2Companion.apk
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...
Will make a topic in OSD/Extns category.
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