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
ewpatton.pdf (251.8 KB)
Your offlime MIT AI works except that Yo post does not provide any companion
It's not offline.
It does. The link to the companion is the last two words of the first sentence of my post:
Also, your screenshot shows the About dialog. The Companion Information dialog is the one you are looking for:
I found the
http://pr2268.ai2-ewpatton-temp.appspot.com/#5699303985119232 easier to use, however the claim for suitable Companion as posted does show any result
cf..ewpatton.pdf (251.8 KB)
The Android10 my Samsung TAB A tablet runs on is no obstacle, so I am at a loss about all the Android10 discussion here.
And I have the suspicion that the flle1 help for storing, reading files, hence /file.ext or //file.ext or only file.ext must origin from old ages and is in need to be updated-
Wünsche ein gutes Wochende. und herzlichen Dank für die profunde Hilfe, beste poweruserin
H. Bücher, Mannheim
Well what exactly have you tested with companion 2.59dev1u that doesn't work as expected? Did you check the LegacyMode option for the File component? LegacyMode will make it work using the old paths (pre-nb184) whereas leaving it unchecked will give you the nb184 behavior.
Surely it should still be possible in future for Apps to read files that were downloaded and stored in the download directory? Any idea how that will work, or is it possible with nb184 already?
The end result is not far-off what malicious apps do - render the device less useful. I think it is a lazy approach by Google, they need to make more effort to weed-out malicious Apps. Especially the ones that are actually distributed via Google Play.
Unfortunately, we're a team of four developers against a corporation with a trillion dollar market cap. We need to comply with the store policies otherwise App Inventor won't be available any more, which is arguably more damaging than some folks losing access to files they could just copy to more appropriate locations (and who would also lose out if App Inventor goes away).
In nb184a we are adding a LegacyMode option that will allow this. However, it's possible that it will break in a future version of Android as Google continues to tighten its file access policies.
I checked this with my testStorage_API29.apk (→ GoogleDrive link above) an a Google Pixel 2XL (runing Android R, 11 Beta). It works without any issues (using TaifunFile & EFile extension).
→ @Taifun @vknow360
The folder
/storage/emulated/0/myDir
is created and the text files are saved in and read from this folder.
Right, but if you install the app fresh on Android 11 once App Inventor targets SDK 30 (it only targets SDK 29 right now), then you won't be able to create myDir because it is not in scoped storage.
Edit: More specifically, to ease the transition App Inventor includes the requestLegacyExternalStorage flag in the manifest so that apps can still access files outside of scoped storage. Once apps target Android 11, this will be ignored (ref):
Edit 2: There is also preserveLegacyExternalStorage, which we will turn on when we target SDK 30, but this only holds if the app was installed on the device prior to upgrading to Android 11 and the grandfathering in of the permissions model goes away if you uninstall and then install fresh the app:
1 Like
Ok thanks, I want to check that, but when I set targetSdkVersion="30" in the Manifest, the app is not installed.
Do you see any errors in adb logcat about why it's failing when the target SDK is 30?
Ok, I'll check this later and report ...
I have now used a different de- / recompile tool. That worked. And yes you are right, it only works for the ASD. What I will test later is the private directory:
/data/user/0/<packageName>/files/
Here are the results of my tests on a Pixel 2XL (Android 11 Beta):
android:targetSdkVersion="30"
As shown in this video, when I save a text file in
- the Private directory or
- in the ASD
it doesn't work with the File component without WRITE permission. But it works with the EFile extension (as it should!).
In addition, if the first button (copy dummy.txt ...) is clicked, you get this error, although the file was saved correctly (in the Private dir, and not in the root dir of ext. storage):
To check this on your Android 10, 11 devices:
More and more complicated, my head explodes 
so,
if i must write/delete or rename a file in this position?
/storage/emulated/0/Android/data/(packageName)/files/xxxxxx.txt
I am not clear if this path will work?
I use it on Android10 by extension TaifunFile and work well
Regards
Angelo
2 Likes
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.