I can confirm what @Boban was already whispering. As soon as there is any button, label, image, ... in a tableArr, there is a crash. An empty tableArr does not crash, not even with @Taifun's KeepScreenOn block. Tested on Android 11 and 9 with the same result.
Recommendation: Avoid tableArrs and replace them with horizontal / vertical arrangements.
(Btw, this general advice was also valid before the nb187 release.)
I've identified the underlying problem with the TableArrangement and am putting together a fix.
No, we won't be including the .aar support in this release. Because of the nature of the AAB change and its implications on building apps we thought it might be better to split up additional changes to app building into a separate release. Since these changes only affect the buildserver, we can deploy them separately once we know the upcoming build system is stable.
Does the error appear in the companion app or after building the app in the apk file?
Unfortunately I'm not able to reproduce the error neither in the companion app nor the apk file...
I created a small test project which only uses the KeepScreenOn method during Screen.Initialize on the production server, saved the project, uploaded it on the test server built it and after opening the project everything seems to be normal without error...
Taifun
test187.aia (23.8 KB)
Any specific data / time when the .aar files support would be added? Would love to see it soon!
The error appears in the companion. I can't get my apps to start after installing the apks that were built on the test server. Everything works as it should if I use the current production server -either companion or apk) I don't get any errors when using your extension on new projects on the test server.
Could you try testing the .aia I posted yesterday to see if you get the same error in companion?
I hope Anke is right, that is all stems from tables, but I don't know why that would lead to the errors I get (getValue and KeepScreenOn when I uploaded older projects)
ai2-test.appinventor.mit.edu + Bluetooth LE Extension 20200828 + MIT Companion 2.60t4u
it doesn't work for me with Android 9.
I tried to trip up the new smart text blocks by using the Download Blocks As Image facility to see how a new project would react when a block with dangling references was dragged into it.
(I resolved the red X errors by pulling in missing components and global variables for the blocks with red errors.)
One thing I did not fix was the reference to a missing Screen at the bottom.
It did not appear on the warning or error counts and it showed its status with a new, unique error indicator: a red border.
Using the pulldown list to select a Screen removed the red border.
I wonder why the potential error (opening a nonexisting screen) did not get flagged with a red or yellow X and appear in the error block navigation lists and counts?
(This is not a deal breaker, it's still an improvement over before.)
I tried the supposed fix to type blocking for the dictionary set value for key block.
The one prompt is wrong (set value at) and the prompt list is meager.
postscript 7/30/2021 - this has been corrected in ai2-test - ABG
I was testing the Copy and Delete methods from my file extension... the tests in the companion app did not result in any error... also the files could be copied and deleted as previously...
however after building the project then the errors occurred, because now in SDK30 it is not possible anymore to for example copy a file to a random directory of your choice...
it would be great to get the errors already while using the companion app...
Taifun
testCopyDelete.aia (42.1 KB)
yes, I get the same errors but after deleting all table arrangements, the error
also is gone, which means, it is a table arrangement issue
Taifun
Hmm. Not sure why this isn't accurately reflecting the list of blocks, but I'm looking into it.
More specifically, the bug in the TableArrangement throws an error, so any components that are in the Screen after the TableArrangement won't be instantiated correctly. I've submitted a patch to fix this and it should be in the next test release.
What happened to the apsolute arrangement? I can't see her on the list 
Unfortunately I ran into a bunch of issues that I haven't had time to resolve, so it won't make it into this release. Hopefully once the Appathon is wrapped up I will have more time to devote to getting that finished.
This may be due to the fact that existing apps are grandfathered in during the upgrade to Android 11 whereas newly installed apps will not be allowed to write to restricted locations. If you uninstall and reinstall the companion, it should lose the exception and behave similarly to the compiled APK.
Honestly I don't know why I didn't use errors for this haha. I looked back at the git history, and it seems I just didn't think of that. Maybe it was because I had fixed deprecation around the same time? But yeah this should use errors. Sadly I don't have time to put in a fix for this right now 
but if someone were to put up a PR I'd be more than happy to review it.
Thanks for trying out the new dropdown blocks 
I really appreciate you giving them a look and finding those bugs!
If the file "foto.jpg" already exists in the folder /Download then it is possible to copy it to "foto.jpg" or → foto2.jpg:
If "foto.jpg" does not exists in the folder /Download:
No, un- / reinstalling Companion app doesn't change anything.
It behaves in exactly the same way - as described above.
But if I create the APK and run it, it is (of course) not possible to write (save, copy) to /Download (because on Android 11, targetSdk=30), WRITE permission is ignored - does no longer exists).
So for the Companion app WRITE permission might be declared this way (to avoid this issue with Companion):
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" />
as I already I mentioned here:
We have updated http://ai2-test.appinventor.mit.edu.ezproxy.canberra.edu.au/ with some new fixes based on earlier reports. Thanks for everyone who has reported issues so far.
Bug fixes: