An AppInventor with the a version before nb184 should be made available, to allow working on APP developed before July 7th, until the reported bug issue has been solved. Keep in mind, opening a working APP with the nb184 Versions renders before flawlessly working APP useless.
LC_Abfrage_60.aia (132.5 KB)
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).
However, if you want to update an app published before Aug. 3, you can use the offline version. Otherwise you can use the EFile extension (until the bug is fixed), as I said earlier.
Dear Anke,
thanks for the comprehensive reply.
How "soothing" not to receive "a wise crack" answer but a clear statement, that the bug exists and a remedy is promised.
Again thank You.
Hermann Buecher
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.
(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.
@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.
