I was lucky to call it a full path then XD
Oh no I was wrong. That was the absolute path. Can't always be right
I do want to note one IMPORTANT thing with the Pro camera extention.
When using the AI companion it worked great but when I downloaded it as .apk it did not work.
When I checked the permissions, camera was denied. When using this make sure to have the following permissions initialized with screen1:
Hope this helps!
Thanks!
1 Like
I have no idea what all of you are talking about here.
What should this have to do with the Play Store and the Google Play Store guidelines?
I think, nothing.
It just ensures that the storage permissions (READ / WRITE) are both declared in the Manifest and specifies how paths are handled by components that can save / read something (e.g. Canvas).
I set DefaultFileScope = Legacy to ensure that WRITE is declared in the Manifest (for devices with Android < 10), and override Legacy for the File component if necessary.
Try this APK on all Android versions (especially Android 6 - 9, 10, 11):
The app saves a text file in the ASD (for devices with Android 10+) and copies it from there to the shared storage (e.g. /Download/myTextFiles/... and read it from there (of course without storage permissions). For devices with Android < 10, the text file is directly saved in /Download/myTextFiles/ and read from there (WRITE permission is required). The same with the Canvas component.
Check it and you might understand.
1 Like
this is strange... because the correct path is /Pictures with uppercase P...
please share a screenshot of the working solution... thank you...
Taifun
@Anke So in your opinion it's good practice to rely on Legacy Scope?
Its name is a bit frightening, that's all 
I don't see any problem with that, least of all with any Google guidelines. From my point of view, however, it remains incomprehensible why storage permissions are declared dependent on FileScope in the Manifest. From my point of view, these should basically (always) be declared as follows:
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" />
I've mentioned this many times:
Yes, I had previously mentioned that I fixed the small errors like 1x "/" too many and the upper case P.
1 Like
I had a working solution but it only worked with Companion, it didn't work as apk sadly.
I will be working on this matter in the next week to try to make it work but honestly I believe the only way it worked well was with the Legacy version and the normal Camera blocks. The pro Camera extentions seems to have some bugs or something... It doesn's save nor show the taken picture. It seems that the Take picture block doesn't even take a picture.
Thanks!
Ha,
You probably solved my problem then, as well, I never did try legacy, as I too had thought that the whole point of the new update was to move away from legacy! I will try your apk and try my aia as well if yours works.
The theory here is that we want to reduce the inclusion of unnecessary permissions wherever possible. For example, if an app is intending to only access say, the private storage, then it really has no need for the READ/WRITE permissions. Obviously, existing apps that aren't programmed to work within that limitation need a way to gain the additional permissions, which is why the Legacy option is provided. That being said, we strongly recommend that folks stop the practice of writing to arbitrary locations as it's already restricted in Android 11 and as newer versions of Android continue to come out, you likely won't have the luxury of writing wherever you want. We are hoping that by defaulting to App scope most people will follow the newer constraints imposed by Android and not get surprised later when upgrading their OS or phone.
Of course, Google has made the permissions system relatively complicated and there are a bunch of exceptions. For example, ASD didn't exist until Android 2.2, and it required read/write permission up until Android 5.0, etc. Starting with Android 6.0 you need to ask for permission but not earlier than that. Etc. So the actual flow of all this is fairly easy for a human to reason about but we don't have a particularly sophisticated static analysis tool in App Inventor to reason about it so we have to draw the line somewhere. Additionally, this is just complexity of the Android side. In iOS, none of these distinctions are really necessary because they had a more restrictive model of the file system from the beginning whereas Google is taking an existing freedom and removing it.
2 Likes
No, READ / WRITE permission were only required for Android below 4.4 (KitKat, API 19).
And what speaks against my suggestion?
It is up to each user whether or not to make use of permissions. So what's the problem?
I am not at all up to speed on the Android road map, and coming from the freewheeling environment of windows, and then the MIT Appinventor Android programming I have done, up until now when Android is beginning to lock it down, it is hard to imagine a OS without some sort of shared Downloads/Docs/Images/Etc folder.
I suppose, it is possible. It could be as your browsing and you see an image, you click it, rather then download, you would select your preferred photo app, and it would download and keep it to itself etc. This would though, effectively force you eventually to only have one app for anything to do with photos
one single app for all of a certain kind of documents, etc.
To me it it still seems like there would always have to be some sort of clearing/sharing ground for apps, without relying on the cloud or another PC as the intermediary. Unless the apps can find each other and agree that they want to share or maybe you can select an app from an app to send a file to, then go into that app and agree to take it. The times are a changing.
My two cents 
You still can, but in Android 11 those paths are fixed by the OS. You can't create arbitrary folders, but you can write to, e.g., the Download folder. This one is particularly challenging because Downloads (note the s) does not work. in fact, it throws an unchecked exception on Android 11, which currently causes App Inventor to crash (I have a fix for this but it's not live yet).
That sequence complies with the latest Google Security Measures - before we could create a folder practically anywhere we chose, which you should still be able to do using legacy mode.
If I understand well all this, it's good practice to rely on Legacy scope for now, and also avoid arbitrary folders, just stick with the shared ones.
Before telling you, I tested it (always in apk).
What I didn't know at that time, is that there's no way to overwrite the shared file if you re-install the app, or if you use another app. Companion to APK counts as different app. Please see this for more info: Problem with create Dir & Save txt file - #6 by anonwins
So what I advise you to do is keep a copy of the photo in the ASD. Work with this. Export to a shared folder only when you're done with the photo. Also, before writing to the shared folder, use TaifunFile.Exists to check if the file already exists, and if it does, save the new file by different name because you can't rely on overwriting it.
1 Like
Exactly. Best practice is to build all new apps with the new android11 rules. And modification of old apps according to these rules. Best to forget that it was ever possible to save files anywhere and save only to shared folders.
4 Likes
Not really - see Patryk's comment.
You wrote that we want to limit app permissions. However, I noticed that adding only the ListView component adds Read permission to the app. Even when we don't use the icons in the ListView. In my opinion, it is not compatible with what you want to achieve.