I did some tests on the AI2 test server (Pixel 4XL, Android 13):
Companion:
APK:
1 Like
I just found out that to make it (video/audio) work with the compiled app as well, you have to use a special (absolute) path.
I'll check this later on other test devices.
Seems to be fixed after the last update.
The next bug: Copy files to one of the Shared folders
It is no longer possible to copy a file from the assets or the ASD to one of the Shared folders on Android 13+, at least not with the File component. Well-known Error: "The permission WRITE_EXTERNAL_STORAGE has been denied. Please enabe..."
The ominous DefaultFileScope construct, which among other things incorrectly declared WRITE_EXTERNAL_STORAGE (even under Android 11+, and yet required there in order to function) in the Manifest, turns out (finally) to be what it always was: half- baked and unnecessary, as I have pointed out and explained often enough.
In short: On Android 11+, storage permissions should generally not be required (and therefore not requested) for any file types (media & non-media) in the Shared folders created by the app itself.
2 Likes
Next bug: Open an image from one of the Shared folders (copied from assets there e.g. with TaifunFile ext):
You need to incorrectly and unnecessarily grant READ_MEDIA_IMAGES to open/view the image.
1 Like
What is your proposed solution to this exactly? We have no guarantee that any file we attempt to read from shared storage was created by the app in question, so requesting READ_MEDIA_IMAGES seems like a logical action when reading from shared directories.
As I've suggested so many times, leave it to the app developers to request storage permissions. Just like, among others, Taifun and Sunny did years ago with their file extensions.
1 Like
At least since the introduction of the (idiotic) Scoped Storage concept by Google, no developer can avoid familiarizing himself with the Android file system. Once you've done this, which is admittedly tedious and annoying, it should be possible and bearable for the developer to request the necessary storage permissions themselves. One cannot shift/leave this to the responsibility of a platform operator (like MIT/AI2, Kodular, Niotron, ...).
1 Like
In my opinion that is not an acceptable solution.
First and foremost App Inventor is an educational tool--not a general purpose app development platform. Asking new users to reason about Android's permission model is not an appropriate introduction to app development for the goals we are trying to accomplish. This approach also makes zero sense on iOS, so curriculum would have to take different paths depending on which platform a student is using, increasing the burden on teachers.
As you have already noted there are workarounds for people who are advanced enough to have an understanding of what Android permissions make sense for their apps. However, beginners do not have that experience so our team must make decisions that work for as many as we can in our target audience.
I will look into alternative approaches to see if there isn't a more balanced medium where we can be more selective about when we ask for permissions, but the less we can push the cognitive burdens imposed by Google's permission model onto novice users, the better.
1 Like
As I have already explained and proven, the problem already arises as it currently is, namely that no file can be copied from the assets into one of the Shared folders. That would mean AI2 would have to decide that it's fundamentally no longer possible to do this on Android 13+. However, this was previously possible on Android 11+ (if WRITE permission was declared in the Manifest). This is absolutely absurd and makes no sense at all.
Whether AI2 is primarily intended for learning purposes or not, it is reasonable and appropriate for users to also learn new requirements (whether they make sense or not).
By the way, may I remind you that there are plans to merge AI2 and Kodular. The latter is a - essentially commercially oriented - platform that has certainly not had the aim of serving educational purposes up to now. So how is that supposed to fit together?
Doesn't the term already imply that it's about learning and practicing something with it. In order to practice something well / successfully, it always requires knowledge and practice. However, successful practice of Android / AI2 is NOT possible without knowledge of the file and storage permission system. Why would AI2 try to spare users this work and thus the necessary knowledge – and in a flawed way at that?
Honestly, that seems like the opposite of "educational" to me.
I'd like to add my two cents here. I don't want to put words into Evan's mouth, but I believe that when he talks about App Inventor being an educational tool, he doesn't mean that it's a tool for learning about Android (and its permission system). It's a tool for making mobile app development as easy as possible and learning C.S. concepts.
From the beginning, App Inventor has tried as hard as possible to simplify the computational model and explicitly enable users to worry as little as possible about the details of the Android model. This is even more important now that App Inventor supports iOS as well as Android.
-Mark
My tuppence...,
in support of @Anke's identifcation of, then pleadings and repeated outpourings with regard to bugs in the AppInventor handling of the file system.
Given the above there appears to be a complete reluctance to resolve some of these "glaring" bugs, which many of us find difficult to understand.
I feel for "little Tommy" who has worked hard on his first app in class, only to find, on compilation, that he and his users are faced with the dreaded Error 908, or similar, with no explanation of how to resolve it, and his educators left similarly non-plussed.
Fixing these issues, would I am sure, improve immeasurably the experience for younger developers in education, given your statement quoted above.
4 Likes
Please explain this term for an ignorant one. 
I agree with you.
If you have specific example project files (AIAs, not APKs) that continue to exhibit error 908 with relase nb194, please attach them here with the Android version exhibiting the issue and the expected outcome.
My main contention was around the idea that the framework should foist the permission management onto the end users. If users want that approach, they are welcome to use Android Studio as that is Google's approach to permissions. We are trying to avoid having novices reason about the permission model. Therefore, examples that force them to use the AskForPermission block, etc., are great for us to improve App Inventor.
I think it doesn't matter if you use AI2 (Kodular, Niotron, ...) or Android Studio. All app developers must familiarize themselves with the Android permission system(*) regardless of whether they are children, students, teachers, professors, etc.
However, the situation is different when it comes to the question of whether AI2 should also consider Play Store-specific permission requirements. Here one could well argue that it is not the job of a learning platform to help create apps to be marketed.
(*) Example (bug - tested also with the new nb194 release):
You can save a text file in one of the Shared folders with the File component also on Android 13+ (now). But when you try to read it you get an error (Companion + APK).
Such - for everyone incomprehensible - errors only cause confusion and frustration and do not help anyone by hiding permission questions.
1 Like