All files access switch greyed out when trying to grant files permissions

[theredbaron05]

EDIT BY CATFRIEND1; TL;DR: To everyone reading this issue. You are advised to switch to the GitHub release (APK can be downloaded from here) or the F-Droid release to get the full features of the Syncthing-Fork app without G's restrictions.

If you're stuck on the welcome assistant because of Android restrictions, please read https://github.com/Catfriend1/syncthing-android/pull/747 and use the emergency config export button to export your existing Syncthing config to "/storage/emulated/0/Android/media/com.github.catfriend1.syncthingandroid[.debug]/" for migration to another release channel of the app.

======== ORIGINAL POST ==============

Description of the issue

all files access switch greyed out when trying to grant files permissions

Reproducer

open a fresh install of syncthing fork and try to grant files permissions

Version Information

App Version: 1.9.0.2
Syncthing Version: v1.9.0
Android Version: Android 11 full release
Device manufacturer: Google
Device model: Pixel 2 G011A

``` ### Device platform info [ro.product.board]: [walleye] [ro.product.brand]: [google] [ro.product.build.date]: [Wed Jul 29 23:26:21 UTC 2020] [ro.product.build.date.utc]: [1596065181] [ro.product.build.fingerprint]: [google/walleye/walleye:11/RP1A.200720.009/6720564:user/release-keys] [ro.product.build.id]: [RP1A.200720.009] [ro.product.build.tags]: [release-keys] [ro.product.build.type]: [user] [ro.product.build.version.incremental]: [6720564] [ro.product.build.version.release]: [11] [ro.product.build.version.release_or_codename]: [11] [ro.product.build.version.sdk]: [30] [ro.product.cpu.abi]: [arm64-v8a] [ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi] [ro.product.cpu.abilist32]: [armeabi-v7a,armeabi] [ro.product.cpu.abilist64]: [arm64-v8a] [ro.product.device]: [walleye] [ro.product.first_api_level]: [26] [ro.product.locale]: [en-US] [ro.product.manufacturer]: [Google] [ro.product.model]: [Pixel 2] [ro.product.name]: [walleye] [ro.product.odm.brand]: [google] [ro.product.odm.device]: [walleye] [ro.product.odm.manufacturer]: [Google] [ro.product.odm.model]: [Pixel 2] [ro.product.odm.name]: [walleye] [ro.product.product.brand]: [google] [ro.product.product.device]: [walleye] [ro.product.product.manufacturer]: [Google] [ro.product.product.model]: [Pixel 2] [ro.product.product.name]: [walleye] [ro.product.system.brand]: [google] [ro.product.system.device]: [walleye] [ro.product.system.manufacturer]: [Google] [ro.product.system.model]: [Pixel 2] [ro.product.system.name]: [walleye] [ro.product.system_ext.brand]: [google] [ro.product.system_ext.device]: [walleye] [ro.product.system_ext.manufacturer]: [Google] [ro.product.system_ext.model]: [Pixel 2] [ro.product.system_ext.name]: [walleye] [ro.product.vendor.brand]: [google] [ro.product.vendor.device]: [walleye] [ro.product.vendor.manufacturer]: [Google] [ro.product.vendor.model]: [Pixel 2] [ro.product.vendor.name]: [walleye] ``` ### Android Log [android log.txt](https://github.com/Catfriend1/syncthing-android/files/5190810/android.log.txt) 

[imsodin]

Ah didn't see that yet. Beautiful move indeed as usual from google. Raises the stakes with 2 weeks notice from: Hey, starting 5 May you can apply for manage_external_storage to hey, starting 5 May. you won't be able to use requestLegacyExternalStorage anymore. I mean you can start applying 5 May, and in the same instant are barred from updating your app. Basically until they decide, you can't update at all. Has google play ever heard of this thing called security? /rant

Edit 1:

Actually re-reading the message is conflicting. The following sounds more like the status quo:

For apps targeting Android 11, the requestLegacyExternalStorage flag will be ignored. You must use the All files access permission to retain broad access.

I.e. as long as you target android 10, this won't apply to you. Which in my view conflicts with the earlier wording:

Developers with apps on devices running Android 11+ must use scoped storage to give users better access control over their device storage. To release your app on Android 11 or newer after 5 May, you must either:

That does talk about running on android 11, not targeting android 11. However preventing updates on the same day as you can start applying for the change is so incredibly insane, that I am inclined to believe it affects only apps targeting 11. Which means the deadline is November when play stops accepting targeting 10. Lets hope that's the case.

Edit 2:

And from the preview article it becomes clear that it is indeed only affecting apps targeting android 11:

Google Play restricts the use of high risk or sensitive permissions, including a special app access called All files access. This is only applicable to apps that target Android 11 (API level 30) and declare the MANAGE_EXTERNAL_STORAGE permission, which is added in Android 11. Also, this policy does not impact the usage of the READ_EXTERNAL_STORAGE permission.

So "just" bad wording on googles side.

[Catfriend1]

@imsodin Thanks for the detailed information. I'll just sit comfortable and wait how things develop. Currently, Google blocks new releases of the fork anyway, because of a so called "non compliant" app description. I hope that removing "GitHub/syncthing/syncthing" clears the non compliance up - even though from my side it was correct mentioning the original native code repo. Google just commented it with "release blocked due to repetetive wording in full app description". There's nothing wrong with a GitHub reference in my eyes, nothing unusual a project name and the owner name are the same there. This text was fine accepted by gplay since years and now - out of the blue - they block releases because of it. silly.

[Catfriend1]

Sent this to Google Play Console support:

I'd like to fill the form to apply for the MANAGE_EXTERNAL_STORAGE permission. Syncthing-Fork technically cannot do its main job without it under Android 11 OS. It is a file sync app which needs to have access to a full subfolder structure the user selects and not individiual SAF paths. Syncthing(native) is written in go (see syncthing.net open source project) and compiled via NDK. The core devs of the project maintain it ONLY in go and won't introduce JNI bindings which leads this app ("the wrapper to run syncthing") to the requirement of all files access. The app currently is on API level 30, so there is no longer a way on Android 11 to use the legacyExternalStorage exception. Upload of APK including the MANAGE_EXTERNAL_STORAGE permission is rejected by the google server. How to apply for the permission?

[Catfriend1]

Soon, it's May 5h 2021. I'll then try to re-submit an APK to Gplay which contains the ALL_FILES_ACCESS permission.

[Catfriend1]

I now get:

Execution failed for task ':commitEditForComDotGithubDotCatfriend1DotSyncthingandroid'.
> A failure occurred while executing com.github.triplet.gradle.play.tasks.CommitEdit$Committer
   > 403 Forbidden
     POST https://www.googleapis.com/androidpublisher/v3/applications/com.github.catfriend1.syncthingandroid/edits/XXX:commit
     {
       "code" : 403,
       "errors" : [ {
         "domain" : "global",
         "message" : "Your scoped storage permission declaration needs to be updated.",
         "reason" : "forbidden"
       } ],
       "message" : "Your scoped storage permission declaration needs to be updated.",
       "status" : "PERMISSION_DENIED"
     }

[Catfriend1]

https://support.google.com/googleplay/android-developer/gethelp

[Catfriend1]

Contacted gplay console dev support again and asked where the permission declaration form is. I cannot find it on the web page.

[Catfriend1]

Okay, found a way to upload the AAB (android bundle) through the gplay console web UI. If done so, a red error appears linking to the application form of ALL FILES ACCESS.

[Catfriend1]

v1.6.0.3 (which is the exactly the same as github/f-droid v1.6.0.1) was submitted to gplay for review including the all files permission.

[auanasgheps]

It's the end of the story, I guess?

For those on Android 11 it's still better to stick with the F-Droid release? (Which works great, the custom file picker is a neat addition)

[Catfriend1]

@auanasgheps I think staying on the fdroid release is going on under a better "umbrella". From my point of view, the fdroid team is much more friendly both in regards of users privacy and towards app developers. Google might have the next nitpick made up somewhere in the future when one is successfully solved.

[Catfriend1]

Google response:

After a recent review, we found that your app Syncthing-Fork (com.github.catfriend1.syncthingandroid) is not compliant with one or more of our Developer Program Policies. See below for more information about your app's status and how to correct the issue.

Publishing Status
App Status: Rejected

Your app has been rejected and wasn't published due to a policy violation. If you submitted an update, the previous version of your app is still available on Google Play.

Issue: Access to device storage not required

The feature you identified does not require unrestricted access to device storage. There are other privacy friendly options for accessing files in shared storage, such as using the system file picker, or, depending on the use case, you can follow the recommendations for receiving data from other apps listed here.

Please update your app so that the feature uses a privacy friendly alternative and remove All Files Access (MANAGE_EXTERNAL_STORAGE) permission.

Policy: All Files Access Permission

Files and directory attributes on a user's device are regarded as personal and sensitive user data subject to the Personal and Sensitive Information policy and the following requirements:

Apps should only request access to device storage which is critical for the app to function, and may not request access to device storage on behalf of any third-party for any purpose that is unrelated to critical user-facing app functionality.
Android devices running Android "R" (Android 11) or later, will require the MANAGE_EXTERNAL_STORAGE permission in order to manage access in shared storage. All apps that target R or later and request broad access to shared storage ("All files access") must successfully pass an appropriate access review prior to publishing. Apps allowed to use this permission must clearly prompt users to enable "All files access" for their app under "Special app access" settings. For more information on the R requirements, please see this help article.

Read more about Use of All Files Access Permission
See Android storage use cases and best practices and how to open files using storage access framework
Address this issue in the Play Console.

Issue: Need to use Media Store API

You have requested access to All Files Access permission but it appears that your app's core feature requires access to only Media Files. With the MediaStore API, apps can contribute and access media that's available on an external storage volume without the need for the access all files permission.

Please update your app so that the feature uses Media Store APIs and remove All Files Access (MANAGE_EXTERNAL_STORAGE) permission.

Policy: All Files Access Permission

Files and directory attributes on a user's device are regarded as personal and sensitive user data subject to the Personal and Sensitive Information policy and the following requirements:

Apps should only request access to device storage which is critical for the app to function, and may not request access to device storage on behalf of any third-party for any purpose that is unrelated to critical user-facing app functionality.
Android devices running Android "R" (Android 11) or later, will require the MANAGE_EXTERNAL_STORAGE permission in order to manage access in shared storage. All apps that target R or later and request broad access to shared storage ("All files access") must successfully pass an appropriate access review prior to publishing. Apps allowed to use this permission must clearly prompt users to enable "All files access" for their app under "Special app access" settings. For more information on the R requirements, please see this help article.

Read more about Use of All Files Access Permission
See Android storage use cases and best practices and how to access media files from shared storage
Address this issue in the Play Console.

Issue: Not a core feature

The feature you identified that is dependent on this permission does not appear to be critical to the core functionality of your app.

Core functionality is defined as the main purpose of the app. Without this core functionality, the app is "broken" or rendered unusable. The core functionality, as well as any core features that comprise this core functionality, must all be prominently documented and promoted in the app's description.

Please update your app so that the feature does not use this permission or ensure that the core functionality is prominently documented and promoted in the app's description and resubmit your app on Play Developer console.

Policy: All Files Access Permission

Files and directory attributes on a user's device are regarded as personal and sensitive user data subject to the Personal and Sensitive Information policy and the following requirements:

Apps should only request access to device storage which is critical for the app to function, and may not request access to device storage on behalf of any third-party for any purpose that is unrelated to critical user-facing app functionality.
Android devices running Android "R" (Android 11) or later, will require the MANAGE_EXTERNAL_STORAGE permission in order to manage access in shared storage. All apps that target R or later and request broad access to shared storage ("All files access") must successfully pass an appropriate access review prior to publishing. Apps allowed to use this permission must clearly prompt users to enable "All files access" for their app under "Special app access" settings. For more information on the R requirements, please see this help article.

Read more about Use of All Files Access Permission
See Android storage use cases and best practices
Address this issue in the Play Console.
Contact support

If you've reviewed the policy and feel our decision may have been in error, please reach out to our policy support team. We'll get back to you within 2 business days.

Thanks for your continued support in helping to make Google Play a positive experience for both developers and consumers. We look forward to seeing an updated version of your app on Google Play.

Please complete a two question survey to help us improve this experience.

The Google Play Team

[matt-palermo-optum]

Is it possible to conditionally request access?

<= Android 10 FULL
>= 11 shared only

? I mean, Fork is 100% useless to me on my Pixel as it stands now so I went back to SuncThign proper some time ago. I can't even get past inital setup. It would be nice to go back to using Fork since I only sync stuff in my shared (music, etc).

[Catfriend1]

@matt-palermo-optum You can use the fork, just install it from Github or F-Droid.

[mpalermo73]

@Catfriend1 The point more is that having Fork in the Play Store is getting closer and closer to 100% pointless. Phones that Fork runs on are becoming fewer and fewer. If the permissions were "dynamic" based on Android version, many more phones can run Fork again with zero fuss or nonsense (GitHub, F-Droid, etc).

[Catfriend1]

@mpalermo73 The gplay version currently supports Android up to 10.

[mpalermo73]

@mpalermo73 The gplay version currently supports Android up to 10.

I get it. I really do - because that's my point. With Google getting 12 ready, that'll be FULL Android versions behind. Devices running <= 10 will/are becoming fewer and fewer.

Knowing what the implications of doing that were, I 100% and completely do not understand why Fork was retargeted at all. But here we are. What's the way out? If dynamic permissioning is an option, then the answer is simple. If the target level can be dropped back, then there's another solution.

If Fork is really only for "tinkerers" - that <=1% of users - then sideloading, etc etc etc is a valid solution. For the other 99% of users, this is broke and the presented solutions are not sane.

I am NOT NOT NOT trying to defend Google here. At all. Period.

I AM questioning the scope and goal of this app, though. Is it for "all" users to have the (much much) better SyncThing experience over the stock app which Fork provides? Or is it only for that <= 1% of Android users that are into multiple app sites, developer mode, USB cables, etc etc etc.?

Whatever. It's your app. I'll defend it to the end. I'm just not getting the direction of it as of late, largely because I haven't been able to use it since it ws rescoped to not be functional on any OS version I use.

Thank you.

[Catfriend1]

It's already the 6th review round with Gplay. Submitting the all_files_access application form over and over again, no luck. First, Google team rejected the permission because of 3 issues:

• Issue: Access to device storage not required
• Issue: Not a core feature
• Issue: Need to use Media Store API

I'm now down to 1 issue in my last three rejection mails I've received from them:

Issue: Access to device storage not required

The feature you identified does not require unrestricted access to device storage. There are other privacy friendly options for accessing files in shared storage, such as using the system file picker, or, depending on the use case, you can follow the recommendations for receiving data from other apps listed here.

Please update your app so that the feature uses a privacy friendly alternative and remove All Files Access (MANAGE_EXTERNAL_STORAGE) permission.

Policy: All Files Access Permission

Files and directory attributes on a user's device are regarded as personal and sensitive user data subject to the Personal and Sensitive Information policy and the following requirements:

Apps should only request access to device storage which is critical for the app to function, and may not request access to device storage on behalf of any third-party for any purpose that is unrelated to critical user-facing app functionality.
Android devices running Android "R" (Android 11) or later, will require the MANAGE_EXTERNAL_STORAGE permission in order to manage access in shared storage. All apps that target R or later and request broad access to shared storage ("All files access") must successfully pass an appropriate access review prior to publishing. Apps allowed to use this permission must clearly prompt users to enable "All files access" for their app under "Special app access" settings. For more information on the R requirements, please see this help article.

Read more about Use of All Files Access Permission
See Android storage use cases and best practices and how to open files using storage access framework
Address this issue in the Play Console.

I don't think they'll accept in the end. So any Android 11+ user is currently advised to use the F-Droid or GitHub release.

[Catfriend1]

Btw if anyone has knowledge how to convince Google - aka fill the application form the right magic way - I'd be happy to hand over the Syncthing-Fork publishing on Google Gplay. It would be no problem for me if I get a service access token to his/her google play dev console with appropriate access to still build and upload Google Play releases of the fork then. What I'm not sure thinking about this alternative idea is security. Maybe GPlays next coming enforcement of using app bundles would put users at risk in such a model "publishing the app through anyone elses account" as then my developer signature no longer protects the app not being tampered with 🤔 ... just wanted to say it's hard for me to lose time in the gplay publishing process summed up again and again over years blocking me from doing what I really like to do have done - improving and maintaining the app itself.

[leo60228]

I don't think Google will ever accept Syncthing-Fork. My interpretation is that, based on Google policies, Syncthing-Fork should either be exposing synced folders through Storage Access Framework itself or access the target folders via Storage Access Framework. The latter is infeasible, and the former would both be a huge amount of work and heavily reduce Syncthing-Fork's utility...

[leo60228]

heavily reduce Syncthing-Fork's utility

Actually, this might be less of an issue, considering that this change is pushing a ton of apps to support Storage Access Framework anyway. It's still a huge amount of work.

[Catfriend1]

@leo60228 Yes, Google went dead on the other side after sending automated looking "issue with your app" mails 7 times telling SAF/MediaStore should be used. Filed an appeal to contact gplay dev console support, the form said "they'd get back within 2 business days". Nothing heard from them. It's no longer worth to publish to GPlay for me. This costs just precious time.

[Catfriend1]

According to: https://www.reddit.com/r/androiddev/comments/aw32gy/deleting_your_developer_account/

If you've published apps using your developer account and want to delete your account, you'll need to:

Sign in to your original account to backup or download your information before requesting an account deletion. If you delete a Play Console account, you won't be able to use it anymore.
Contact our support team to transfer your apps to another account.
Reply to the app transfer confirmation to close your existing account.

Is anyone willing to take over the Syncthing Fork google play dev console app publishing? Then please raise your voice. I'd like to close my dev account and transferring the app to someone else is the only way to do so.

(And keep the F-Droid, GitHub releases)

[Catfriend1]

Interesting, I've again removed the fork from the gplay store and told google I've quit . Reveived an email today that the fork app got all files access approved , sounding like "hey dev why do you complain so much, we have approved , please come back". Before that, not a single of my seven reachouts to google support found an open ear. Anyways, the GPlay Release v1.16.0.3 is live now for everybody.