uintdev / qrserv

Transfer files with ease over a network.
https://play.google.com/store/apps/details?id=dev.uint.qrserv
MIT License
135 stars 9 forks source link

Google Play All Files Access policy compliance issue #20

Open uintdev opened 6 months ago

uintdev commented 6 months ago

This issue is to document the situation.

Version 2.3.2, build 42, was rejected. Twice. The cited reasoning for this was that it was deemed “access to device storage not required”. It was then advised to use MediaStore APIs instead, unless it can be proven that such access is required.

This is not that surprising, as Google does come across as fairly strict regarding this permission. Thing is, it passed review 3 times in the past.

I’ll give it a few more attempts some time next week and maybe the next few. If it keeps getting rejected despite the further revisions and attempts to have a reviewer who is willing to let it through, then I’ll have to take a look at the options (such as attempting to build or modify a flutter package that could be used to bring up the file picker in hopes it allows for direct access without such permission, or potentially leaving 2.3.1 [build 41] as the final release on the Play Store until it eventually gets booted off due to abandonment or not targeting a more recent Android API version).

Ideally, I’d like to avoid having to build or modify a file picker package. It would be far less painful if the app wasn’t built using Flutter, as then I wouldn’t have to deal with method channels and its own challenges.

A lot of users get the app from Google Play, so it would be good to be able to keep distributing the app and its updates that way.

uintdev commented 6 months ago

Declaration was updated to state that the past 3 releases with such permission that the app update was being rejected for.. were approved. Resubmitted after. It looks like the update finally got approved. Of course, there’s always the risk of it happening again. If it does, I’ll do what I can.

uintdev commented 4 months ago

So, last week, this came up again. I found out that there's an appeal section for policy issues, so I decided to try it out. I finally got a response a few hours ago, but it's pretty much the same verdict. No bueno.

I'll re-attempt at submitting, like what I did before. Declaration was updated again to mention the slight limitations* I'm working with as I'm dealing with Flutter (although, that may not be good enough -- should've just stuck with Kotlin and Jetpack Compose, I guess). Not sure if me having tried out the appeal route might've ruined the chances (even more). I guess we'll see soon enough. If it keeps on happening too often and/or the chances of it getting through is greatly reduced compared to before, then what I've mentioned in the previous posts applies.

I'm not willing to suddenly remove functionality for the version that would be on the Play Store that is kind of important in some cases (even if it ends up being replaced with a message hinting to just get the app from here instead). I don't want to have to maintain two different variants of the app either.

This impacts version 2.4.0.

* It's not so much of a limitation. Rather, regarding the availability of existing (Android) file picker Flutter packages that just don't use "more privacy-friendly" permissions and APIs for internal storage access. And me not exactly wanting to build a package myself to deal with this. I wasn't intending to get deeper into Kotlin for this Flutter project than necessary.

uintdev commented 4 months ago

After further adjustments to the declaration and couple submission attempts, it got accepted. Closing for now. Something tells me that this is going to keep being a thing.

uintdev commented 1 month ago

For almost 3 weeks, I've been unable to get it past review due to this. It did look like they updated the review process. I'll continue attempting, but this isn't looking very promising so far.

uintdev commented 2 weeks ago

v2.5.0 hasn't managed to reach Google Play Store. This is because of the review process appearing to have been made more strict some time ago (maybe when they added some new review process pre-check stuff) regarding sensitive permissions. It can since then also auto-reject if you don't make changes somewhere in the submission since.. well, the last submission.

While I was looking for something I could potentially use for interfacing with the MediaStore API, I did come across the Flutter package media_store_plus. No offense to the maintainer of that package, but: it is terrible to use. In my case, at least. The documentation is lacking in places, the example does not properly demonstrate how various methods can be used, and the supposed new package getFilePathFromUri method that is supposed to help get the real path based on the content provider URI out-right raises an exception at the Kotlin layer (failing to get the data column index, shortly after using the content provider resolver). Try outputting the method result? Blank. As if the line of code was skipped. Debugging mode had to be used to find out why that was happening.. but that's a whole other thing. EVEN if that did work (I instead hardcoded the full path to a test file), while metadata and file existence can be checked for, there is a permission denial on file read attempts despite being a directory that the user will have to manually select and grant access to from the document/files UI (included AOSP application).

Maybe I'm misunderstanding how the MediaStore API works. Or the Flutter package simply doesn't have that much fine control or flexibility. Either way, it is wanted for me to go with a privacy preserving method. I'm really trying, but I have a feeling I'd have to do everything myself at the Kotlin level if so (assuming MediaStore technically would allow it if done right).. and I don't know if I even have the motivation or the time to even go that route.