Google Play rejecting app update without substantive reason | Hacker News Reader

Google Play rejecting app update without substantive reason

github.com

74 pointsproactivesvcs20 comments

Background: Syncthing is an open source automatic file synchronisation project. As such it needs permissions for full access to a device's filesystem. Since Feb 2024 Google Play has been rejecting updates to the app because it requests this permission, but without any sensical reason. The maintainer who handles this has repeatedly re-submitted with clear reasoning, but has no option but to cease requesting reviews as a result of repeated insubstantial rejections.

When I use Syncthing-Fork, it uses the Android storage system to request access to the specific folders it syncs too. Does the OG SyncThing not have this? Is that somehow still not sufficient?

I've been using OG Syncthing from the Play Store for a long time but was just looking through F-Droid and noticed this Syncthing-Fork and then I see this comment about it. Looks interesting. You recommend it?

I absolutely recommend it, at least if you're somewhat tech-savy you'll enjoy the more detailed status display, advanced options etc.

I don't use the fork but I can see it has scope to request storage permissions: https://reports.exodus-privacy.eu.org/en/reports/com.github....

Perhaps it only does this if the user wants to sync data outside the SAF?

FWIW, I just checked and the only permission I have granted to SyncThingFork is "notifications".

I think it optimistically requests all, but I can testify that it works fine without granting it all storage access. I just had to create/select a subdir in my SyncThingFork directory.

I don't really know how the restricted storage access works. Maybe it's that if /another/ app has already claimed a directory, that SyncThing needs more permissions to be able to sync it? But that seems unlikely, just speculating.

Sync in background can be achieved using Storage Access Framework APIs, where Syncthing can get access to directory trees without requesting any special extra permissions - that's right, no need for READ_EXTERNAL_STORAGE or the one I'm guessing the OP uses, MANAGE_EXTERNAL_STORAGE.

The API is available since Android 4.4. The requirement to use it instead of asking for access to all documents, private photos, personal data and other data on the phone is there from Android 10 (that's 4 years now).

It's telling that the author isn't actually saying why they're rejecting him - I bet they're telling him the app doesn't need access all private photos just to sync a directory and that the app should use the API that's been mandated 4 years ago. There's even a fork that does exactly that and is published just fine.

Yes, the ecosystem is full of devs that refuse to adopt the new ways, regardless of how many years Google has been pushing for them.

In other GitHub Issues (I don't have the tab open, they might have closed it) the author discusses using that permission but says they are not able to because the Storage Access Framework is only available for Java/Kotlin apps, where syncthing is written in go.

Is it really surprising that "I want access to all the private data because I don't want to make a JNI bridge for SAF" isn't an answer Google accepts?

Do you think Apple would accept that excuse?

The author has chosen not to use the official programming languages and then complains it isn't a smooth experience?

The author of Syncthing-fork has actually said they've had similar problems with Google and believe it's only a matter of time before their app is locked in a similar way - so much so that they are planning to surrender their Play developer account:

https://github.com/Catfriend1/syncthing-android#about-play-s...

> It's telling that the author isn't actually saying why they're rejecting him

Have you ever tried to publish apps on the play store? They often don't give you a reason that it fails, you're just left to keep trying different things randomly until it works, and then later fails again when you changed nothing... there is a documented history of this happening to many projects.

I know several FOSS projects that do not have the knowledge/time/desire to implement SAF support, and for some projects it doesn't make much sense or might be invasive to the user experience, and their play store versions have since been stuck at old versions and they just moved on to F-Droid and other appstores.

Android is not GNU/Linux, and the use of Linux kernel could be easily replaced by something else POSIX like.

Many of those FOSS projects keep thinking Android is Linux, and then act surprised when it is not.

Yes, I've been doing this for a long time now and I've also helped convert several apps to the new SAF framework when the restrictions came out. I've also helped many companies and people with these kind of issues and in most cases it's been self-inflicted.

The policy there was always very clear - you need to use SAF unless you're building something that absolutely function with it (these are pretty much exclusively file explorers).

Syncthing can use SAF, the author just refuses to according to their bugs. This counts as "self-inflicted" and I'm not sure why they think they can complain their way out of it.

I'm in a similar boat with one of many android app updates on Google Play. Over the last couple of weeks I pushed out updates to dozens of app listings with one app review rejected due to failing to disclose data my app absolutely does not collect. Specifically, a user's phone contacts. An app has to disclose on the store listing that type of data if it's transmitted off of the device. So I have this false positive with my initial appeal denied. I'm not sure how to move forward. Concede and change my Data Safety form on the listing? Insist false positive again? I'm in a bit of deadlock.

How about you check all the dependencies you loaded into your app and determine whichone is a data stealing malware? :P

I like having one-purpose simple apps with no ads, and OSS if possible.

I have switched to FDroid and download apps from there even if the same apps are available from Google Play Store. Like VLC, Syncthing, Ankidroid, etc.

I also switched to OSS alternatives from FDroid, deleting Play Store apps, and I have zero regrets. Some examples-

1. Antennapod is better podcast player than anything on Play Store, like Pocket Casts, Podbean, etc.

2. Voice is the best audiobook player for local files for Android.

3. Feeder is a great RSS reader. Can't use anything else here.

FDroid is not only useful, it is fun, too. I have an app called Bubble which is a spirit level app using the phone's sensors. It's like using Windows in the 00s, and discovering indie apps and playing with them.

It also has apps like Exodus where you can check permissions used by apps to check suspicious permissions.

Getting this right now with Google and Apple. Extremely frustrating, especially after years of working in the space.

honestly just use F-droid. If you're on Android already, might as well use the wonderful feature sideloading is

Reply on news.ycombinator.com