> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.
I don't think Google was ever buy a "I don't want to use file APIs because writing the code would be hard." excuse for a security issue. I don't know what kind of exact "discussions" were possible here for "give me access to all user data, photos and everything because I don't think I want to use SAF APIs". It's like that dude in your company that will have a meltdown in PRs over his better way instead of fixing the comments and having code submitted.
Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
I used to develop Android professionally (at Dropbox in the 2010s, so I have some familiarity with older Android filesystem APIs) and made a very conscious decision to switch to devx and backend work and get out of Android (as did most of my former Android colleagues). The unending hoops you had to jump through and API changes to keep your app working were too much of a pain.
As a fun anecdote, in 2014 when the "secure" Storage Access Framework was new, I found a trivial directory traversal vuln that allowed writing to any app's private directory by just passing a "../../" file name to the system [0, 1]. It was so trivial I noticed it while just browsing AOSP source to understand SAF better...
Android also used to grant world execute bits to app folders for the longest time, allowing malicious apps to create hard links to other apps' files by name, which could then be handed back to that app for a confused-deputy attack to gain access to the file contents.
All that to say - I'm glad Android has been working on security, but it was built upon such a loose foundation that tons of apps used and abused that it's going to drive developers out of the ecosystem as they have to keep adapting to a continuous stream of major breaking changes as things are locked down.
"Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app."
I've been using that one for a long time now. I recall that when I got started with Syncthing (some months to a year or two ago?), it seemed to have been the folk wisdom to use Syncthing-Fork, but I don't recall what the reason was.
Seems to work. Exported the config of the other one and imported it in this one. Seems all the settings are there. Sync seems to work too. Kudos to the devs.
In this case the author doesn't want to use Storage Access Framework APIs to access the file system which were mandated a few years ago as the way to access data outside the app sandbox.
They're Java-only APIs and since Syncthings core isn't written in Java, the author would have to write JNI glue to call Android when writing/reading files (and honestly this would be quite tedious, because the way SAF works is to assign Uris to each file and you need to keep querying it to get folder structure since you can't just concat paths like with files).
The author didn't want to do that and tried to persuade Google to continue letting them access all files, all photos and all documents directly and Google said no. That was the "difficulty" - turns out it's really hard to publish on Play if you refuse to follow the guidelines. Just like on AppStore.
While I don't know about this developer's specific issues, I can comment on my own issues with Google Play as an Android developer. Google Play continues to become more and more stringent with app permissions and the approval of these permissions is very vague. With my own app, from one minor release the next, one day I'll receive approval for my app's permissions and the next week I will not even though only minor changes to the app have been made. When I reach out to Google Play support, the answers are always extremely vague, canned and repetitive and I never know if an update to my app will get approval or not. It's a horrible way to develop anything.
I've done a few apps as part of my day job. And my best explanation and/or analogy is government regulations. The store requirements, apis and rules are documented up to the upteenth degree in 49 pages spread across many areas, and unless you're "in the know", you have no way to implement it to a reliable degree. And then all this ends up doing is punishing small / low-budget / low-time developers, leading to consolidation around the big players.
The big players can push their weight around to some degree, they get an element of built-in trust, and they have the sheer budget/time to implement all the ridiculous and sometimes onerous requirements. All in all, they're cementing their market position and trying to make "sticky" and invested players that will prop-up the play store for the coming decades.
The KeePass2Android app gains a bit of functionality if you use it with SFTP instead. You get the ability to, for example, merge changes in the event that there's a conflict. I recommend using SFTP to a machine that then runs SyncThing to the rest of your devices.
I would think that a user competent to use and want sync thing, is perfectly capable of depending on f droid as a source for the apk.
Can that not be enough of a distribution channel.
Well, I'll be putting the APK in a safe place, along with my Turbo Pascal floppies. ;-) Syncthing for Android has been vital to managing my sheet music collection.
That's a bummer! Can anyone suggest an alternative way I can get files from my macOS laptop to my Android phone? I "just" want to put my folder of music files and m3us there so I can play them (with PowerAmp).
I've been considering making a new Android app for a while. A simple one to interact with a couple of my web services with some on-device storage, nothing complicated. More than anything, the thing that's stopping me is that I _know_ if I make it, a few Android versions later, it either won't work or won't be allowed on Play. I can't predict what random piece of the Android API/policy will change, but I know something will. And I'll have to waste my time fixing something that worked fine until Google arbitrarily broke it.
I built one app before for JellyBean. I haven't been able to install it for years and I can't compile it for a new version because of a cascade of errors and required changes that I'm unwilling to do. JellyBean hadn't even reached 10 years old before my app broke, it's pathetic that app support crumbled and rotted away that quickly. It'll happen again, so I've been turned off of Android development.
I totally understand the discontentment. It makes you feel powerless.
For everyone using Android and fearing not to be able to use Syncthing anymore: fear not. This is only affecting the Google Play Store version of Syncthing. You can get Syncthing-Fork here on F-Droid http://f-droid.org/packages/com.github.catfriend1.syncthinga...
The catfriend fork works great (I use it) but to be clear, this post is about the official version. The official version will cease all development, it's not just limited to the Play Store.
If the Catfriend fork goes, I'll have no use for Syncthing at all, and it will be a very sad day in open source. I'll probably move to some proprietary app, since I'm definitely not interested in self hosting anything, and there's not really any FOSS equivalents other than Syncthing itself.
Android really needs to just allow direct file access to any file which is under a user selected folder.
This is disappointing. SyncThing is one of my reasons for picking Android over iPhone. I hope the author reconsidered. Would any GoFundMe-style donation goal make the hassle worthwhile?
When I migrated from Android to iPhone, syncthing was my main pain point. There is Möbius Sync, even though not open source, at least it’s an one-time small payment, which is fair considering the dev license cost. Unfortunately it’s not as reliable as the Android official app or the fork, I guess Apple is very strict with background processing, but hey it’s better than nothing.
I'm using Syncthing to sync documents between devices and I own a mac fleet and an iPhone. The Möbius Sync[1] client (no affiliation) works great for me.
[+] [-] jasonjayr|1 year ago|reply
> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.
[+] [-] izacus|1 year ago|reply
Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
[+] [-] scottbez1|1 year ago|reply
As a fun anecdote, in 2014 when the "secure" Storage Access Framework was new, I found a trivial directory traversal vuln that allowed writing to any app's private directory by just passing a "../../" file name to the system [0, 1]. It was so trivial I noticed it while just browsing AOSP source to understand SAF better...
Android also used to grant world execute bits to app folders for the longest time, allowing malicious apps to create hard links to other apps' files by name, which could then be handed back to that app for a confused-deputy attack to gain access to the file contents.
All that to say - I'm glad Android has been working on security, but it was built upon such a loose foundation that tons of apps used and abused that it's going to drive developers out of the ecosystem as they have to keep adapting to a continuous stream of major breaking changes as things are locked down.
[0] Bug 18512473 fixed in https://android.googlesource.com/platform/frameworks/base/+/...
[1] Proof of concept video: https://www.dropbox.com/s/8dpd8visrttqbfo/poc.mp4?dl=0
[+] [-] jsiepkes|1 year ago|reply
[1] https://github.com/Catfriend1/syncthing-android
[+] [-] ajb|1 year ago|reply
"Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app."
[+] [-] felurx|1 year ago|reply
[+] [-] krick|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] oakpond|1 year ago|reply
[+] [-] SeriousM|1 year ago|reply
[+] [-] _fat_santa|1 year ago|reply
> Reason is a combination of Google making Play publishing something between hard and impossible
Can someone expand on what's going on here?
[1]: https://forum.syncthing.net/t/discontinuing-syncthing-androi...
[+] [-] izacus|1 year ago|reply
They're Java-only APIs and since Syncthings core isn't written in Java, the author would have to write JNI glue to call Android when writing/reading files (and honestly this would be quite tedious, because the way SAF works is to assign Uris to each file and you need to keep querying it to get folder structure since you can't just concat paths like with files).
The author didn't want to do that and tried to persuade Google to continue letting them access all files, all photos and all documents directly and Google said no. That was the "difficulty" - turns out it's really hard to publish on Play if you refuse to follow the guidelines. Just like on AppStore.
[+] [-] binkHN|1 year ago|reply
[+] [-] zo1|1 year ago|reply
The big players can push their weight around to some degree, they get an element of built-in trust, and they have the sheer budget/time to implement all the ridiculous and sometimes onerous requirements. All in all, they're cementing their market position and trying to make "sticky" and invested players that will prop-up the play store for the coming decades.
[+] [-] treve|1 year ago|reply
[+] [-] lgbr|1 year ago|reply
[+] [-] Groxx|1 year ago|reply
[+] [-] replete|1 year ago|reply
[+] [-] greenavocado|1 year ago|reply
[+] [-] fuster|1 year ago|reply
[+] [-] cja|1 year ago|reply
[+] [-] pomian|1 year ago|reply
[+] [-] KetoManx64|1 year ago|reply
[+] [-] amelius|1 year ago|reply
[+] [-] greenavocado|1 year ago|reply
[+] [-] analog31|1 year ago|reply
[+] [-] Symbiote|1 year ago|reply
[+] [-] suprjami|1 year ago|reply
[+] [-] eightys3v3n|1 year ago|reply
[+] [-] krick|1 year ago|reply
[+] [-] thenoblesunfish|1 year ago|reply
[+] [-] eternityforest|1 year ago|reply
[+] [-] momo777|1 year ago|reply
[+] [-] TwoNineFive|1 year ago|reply
If you don't have root, it's not your phone.
[+] [-] RadiozRadioz|1 year ago|reply
I built one app before for JellyBean. I haven't been able to install it for years and I can't compile it for a new version because of a cascade of errors and required changes that I'm unwilling to do. JellyBean hadn't even reached 10 years old before my app broke, it's pathetic that app support crumbled and rotted away that quickly. It'll happen again, so I've been turned off of Android development.
I totally understand the discontentment. It makes you feel powerless.
[+] [-] rcarmo|1 year ago|reply
[+] [-] redleader55|1 year ago|reply
[+] [-] opengears|1 year ago|reply
[+] [-] JeremyNT|1 year ago|reply
[+] [-] kertoip_1|1 year ago|reply
[+] [-] eternityforest|1 year ago|reply
Android really needs to just allow direct file access to any file which is under a user selected folder.
[+] [-] nixosbestos|1 year ago|reply
[deleted]
[+] [-] sabbaticaldev|1 year ago|reply
[+] [-] krick|1 year ago|reply
[+] [-] 1over137|1 year ago|reply
[+] [-] izacus|1 year ago|reply
[+] [-] xnx|1 year ago|reply
[+] [-] andreldm|1 year ago|reply
[+] [-] atmosx|1 year ago|reply
[1] https://mobiussync.com/
[+] [-] exabyte|1 year ago|reply