Thank you. I 'll go with efile until de bug is fixed.
when you say " There is an offline version of AI2 (nb183c), but it won't help you because it still targets API 28. Since Aug. 3, all new apps must target API 29 (Android 10) (targetSdkVersion = 29)." . That is if I pretend to publish in play store, but if I only want to install it myseft with the apk I should by fine with offline version , don't I?
Yes, of course.
For those of you encountering issues reading files on Android 10, you should try loading your app into this test server and test it with the corresponding companion.
In this version, the File component gains a LegacyMode property. You will need to set this property to true in order to read files from outside the app-specific directory.
Note, this will only work for another year or so. Starting with Android 11, Google will no longer allow apps to read outside of their app-specific directories. You should read "Migrate data to directories that are visible when using scoped storage" to understand the implications of what you need to do. App Inventor cannot migrate your data for you, but this flag will allow you time to update your app over the coming year to be compatible. If you fail to migrate, an upgrade to Android 11 may cause your app to stop working and there will be nothing we can do for you.
3 Likes
(added to FAQ)
Right, so in some use cases in this thread leaving LegacyMode enabled will work. In other cases, it won't (e.g., the root directory is NOT valid under the new regime so the app installed on Android 11 will fail if not grandfathered in). You can also only read files created by your own app using the quoted approach. You can't, for instance, enumerate all of the pictures and read/write them arbitrarily on Android 10+. You have to use the MediaStore API for that in order to get a content URI that the app can then interact with. The File component therefore isn't a valid or useful tool in that situation.
There are also potential gotchas that involve uninstalling/reinstalling apps on Android 10 and higher since Android will consider newer versions of the app different than older versions even though it's the same package name. Overall, I don't think this will be a problem but it is a possibility that even if you read/write to the media store paths it will break in the future.
If the user uninstalls and reinstalls your app, however, you must request
READ_EXTERNAL_STORAGEto access the files that your app originally created. This permission request is required because the system considers the file to be attributed to the previously-installed version of the app, rather than the newly-installed one.
2 Likes
@ewpatton But what sense does it make that the File component always places the ASD path at the front (of the path set with the File component)?
So if I set the path of the File component like this /myDir/text.txt, the File component points to /storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/files/myDir/text.txt. (Of course, this path doesn't exist and cannot be created.)
So I basically have to set the path like this: /text.txt to get the correct path for the ASD:
/storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/files/text.txt
`
It's not just Android 10. In Android 9 file read fails too (HTML files tested as they were the first to show the issue).
Can Users safely load an nb184 Project into the Offline nb183C version in order to avoid these issues?
The logic for reading/writing files to the app-specific directory is explicitly for Android 10. For Android 9 and earlier apps will still write to the older paths because there are no constraints on earlier versions of Android. Any issue on Android 9 and earlier related to the WebViewer is likely something else entirely or a misunderstanding of how something is supposed to work.
Well it would be "something else entirely" given that the issue was not present in the App before nb184 was released. 
However, even with the aid of Taifun's file extension, the workaround of moving the html files from App Assets to the ASD does not fix the read error. That sounds very similar to the read-write issues discussed.
What a pity that Google is going to prevent Apps read-write in other directories in the future - I feel they are stifling innovation.
Your test server works fine. Can You give a hint where to find the previous Companion (SK28?) as in the Playstrore only the SK29 is available and Your test server refuses to accept this Companion.
Thanks K.K:Buecher
PS: MY storage/save and delete Problems only occurred after opening my APP with the nc184 Version, even with Android 10. However the file1 operation never stored in the SD Card but directly in the root directory of my Samsung TabletA claiming to run on Android10.
I tried it with may APP developed with nc183c, after is has been rendered inoperable when opened with n184. The Testserver complained that the now modified APP was written with a newer version but it held up to its promise to try making/convert it to a workable nc183c version. However the Companion SK29 does not work with the testserver and I can't find the SK28 version anywhere.
Thanks for that info - I think testing will have to be done as an APK (saved to your PC, moved to the Android Device via USB).
It makes sense that we are going to enforce it from Android 10 going forward in accordance with the fact that all apps published in the Play Store (e.g., the MIT AI2 Companion) are required to do so. The test server I linked earlier in this thread gives an escape in the form of the LegacyMode option that developers can use, with the caveat that it may break apps starting with Android 11 because this will be enforced by the operating system.
Yes, but this has always been true of the File component. It has never made directories that don't exist. The app-specific directory is created when it is requested by the app, and the file utilities in App Inventor will call this in Android 10. I've tested this on a Google Pixel running Android 10 and it does do the right thing by creating the app-specific directory. But if you put an arbitrary non-existent directory in the middle it won't work but that was true before, too.
Only on Android 10+. We considered making this functionality turned on for all versions of Android that support app-specific directories (Android 2.2 and higher), but decided that since it is only enforced by Android 10 that we would only enable it starting at Android 10.
The / as the starting character is by convention for App Inventor. Typically in most APIs a file named this way would cause the app to write to the root file system, which is clearly off limits.
I agree it's a pain. I also thought the removal of texting/phone call permissions was as well. In the end, these are justified (Google claims) due to malicious app creators and unfortunately it affects everyone. On the plus side (if you can call it that), this does bring the Android more in line with iOS where each app lives in its own sandbox and the leaking of information between apps isn't nearly as much of an issue.
That makes no sense to me. The test server is newer than nb184 because it is nb184 plus my fix, so importing your project should not trigger a warning.
The test server has its own corresponding companion version 2.59dev1. You need to download it from the link in my post and install it. Alternatively, in the test server go to Help > Companion Information and then scan the QR code it provides with the companion app to upgrade.
I solved my problem by installing the offline version as you suggested. Thank you. My app is working again , no changes needed. The app is for internal use so I don't need to publish, so
this solution is enough por me . But I undertand that I will have to rethink the app storage given the limitations of android 10 if I want it to keep running in the future. thank you again