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.
It sucks that the ongoing maintenance cost for the native mobile platforms is so high. Who wants to develop on top of a platform that is constantly changing out from under you?
It really makes me nostalgic for the vision of webOS (although not the implementation of webOS from 14 years ago).
But that's Scott's point. If the OS devs had thought through this from the beginning, app devs wouldn't have to keep dealing with breakage. iOS devs have other issues, but not these.
Apple and Google approached the mobile OS from opposite sides. Apple locked everything down and has gradually been adding access/features. Google left the barn door open, and is now trying to shut it. I know which OS/API I'd rather program against.
Heh, I never worked on iOS but based on what I heard from our iOS team at the time, I don't think iOS was any better. Though a lot of the frustrations back then were largely app review issues rather than API stability, like trying to push out a big feature release or bug fix and getting rejected because the reviewer found a new way to follow 20 links to get from the help center website to a page allowing you to sign up for a subscription outside the app store...
Web might be a better counter example - it started super locked down, but has slowly gained useful functionality like notifications, USB, serial, GPU, etc within the sandbox model. It just encourages more investment over time as new functionality is added, rather than annoying devs as useful functionality (documented or undocumented) is taken away.
> 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.
There's going to be loud, destructive friction when a 10-15 year old platform reduces the functionality available to its apps. Security models do need to evolve, but Android was introduced as a platform suitable for deep personal customization with few mandatory boundaries.
This was a competitive distinction against Apple's closed "safety first" platform design in iOS and led to an ecosystem of applications that took advantage of all these extra possibilities. As Google tightens its grip over the platform and pursues more aggressive limitations for security reasons (and whatever other ones), it's inevitable that many publishers and users are going to be deeply frustrated when the features that made their device theirs are no longer available.
(And incidentally, the restrictions on the Apple side have nothing to do with the application development language. I don't know where you would get that idea from or how to even make sense of it. It's just the nature of Apple's original design philosophy for iOS, where apps were deeply isolated and had no more capabilities than were necessary. Largely, Apple has been gradually adding capabilities to heavily-restricted apps over the lifetime of iOS, while Google has been moving in the opposite direction because they each started from opposite ends of the design space.)
Google's app process requires active developers and just makes it plain impossible to make an app and have it work with minimal updates. You're not allowed to "feature complete" an app and just exist. Every few months they threaten me to upgrade this, upgrade that, fill out this form, submit this info and I eventually gave up this year and they've already deleted my developer account and removed the app from search.
I feel like theyr'e doing this just to minimize storage costs or something lol. Android dev sucks for a hobbyist
It sucks for small software entrepreneurs too, as the cost of keeping a trustworthy developer on retainer for that kind of maintenance work can easily eat the modest revenue for a good niche app. And iOS is fundamentally no better.
It's why both App Stores are now dominated by corporatized growth chasers compromising their UX with endless feature treadmills and pushing for subscription IAP to fund it all.
Building a personal/family lifestyle business from the long tail on a few good niche apps, sold at a modest and respectful upfront cost, is pretty much a thing of the past now; and all the software we loved has been delisted or sold to those corporatized growth chasers.
Yeah, I'm sure it can. The app I was talking about was an app that handled appointments for my mom's business. 80% of her customers used the mobile website but a few liked the app for notifications and just liked apps but I eventually gave up as I'm not a fulltime android dev, just a backend engineer that can hunt and peck my way through an android app. It was fine for many years but the past 2 have been horrible and I eventually told my mom I give up
Most changes seem to come down to "the sandbox APIs aren't sufficiently isolated, let's lock down the sandbox further".
Most file system API changes aren't exactly recent, they're just inconvenient. Most changes were introduced in Android 11, with some going back all the way to Android 4.4. App developers tried to use workarounds, exceptions, and special permissions to work around API restrictions as long as they could and now the holes in the sandbox are finally being closed.
The Syncthing for Android app hasn't had much development in the past few years, so years of minor changes have added up to tech debt that's (too) expensive to fix.
Put a lot of scary warnings around it then. It's for the user to decide if they want to take the risk or not. Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.
They did, the upstading app developers like this one just forced people to give them full access to all data in the app (or the app wouldn't run) and ended up not implementing scoped storage - something HNers outright demanded several times and exposed as a good upside of iOS.
So stick had to come out. The full filesystem access is now reserved for apps that manage full filesystem (e.g. file explorers) and that's it. Scoped storage APIs were introduced in 2013, 11 years ago and Play started enforcing them in 2020, so the experiment with scary warnings was running for 7 years and developers refused to give up on that sweet full private file access.
It's my phone. It's my data. It's my choice to install the app. It's my choice to grant the permissions to all files. Because guess what, I'm using the app to sync all my files.
I really can't agree with Google in this particular case.
I couldn't agree more. Given how much frigging hoops I had to jump through to get my Obsidian over syncthing setup to sync with my company iPhone - I nearly gave up.
I grew up when computers didn't babysit me and tried to act like the good old GDR, knowing every thing better than their citicens.
Nowadays, I feel more and more hindered by computers, not enabled. Computers used to be a production device (I could create things with them).
Phones are not a computer - phones are a just "consume like we want you to" device.
The problem is, I want my phone to be a creation device. A device that allows me to create content, text, to do lists, shopping lists, ideas and store them. And(!) sync them using the tools I decide to use. And not force me to use tools I friggin hate, because they just don't get the job done.
I gave up. My phone now is just a communication and utility device, and thus I don’t feel the urge to upgrade until it can’t do those tasks. I went back to computers (and Linux) to be able to just use them as a computer.
Same. I wish there were an alternative (a practical pocket computer), but there really isn't. So I too gave up on fighting my phone, and have also completely stopped doing mobile development. I now treat my phone essentially as an untrusted, prepackaged walled garden with limited utility. :-/
How did you get iPhone Syncthing + Obsidian working? I was under the impression that it was basically impossible to share Möbius Sync's directory with Obsidian.
Got it working myself. I set up a share inside of Mobius Sync that reaches into the Obsidian folder. (note the entire thing, just one vault). I think there was a popup saying it was unsupported but I haven't had any problems yet.
The java.io.File API isn't removed from Android, nor inaccessible. You can absolutely still use it. Google Play has chosen to not accept it on their store unless you justify it (to their non working bots). In this case, the dev chooses to just drop the entire app because maintaining it just for Fdroid feels pointless.
There's very few permissions on android that are system/privileged/preinstalled.
That’s still not your product though. You only bought a licence.
Flash your favorite open firmware, enjoy and let regular users who cannot do that avoid permission extortion. The world has needs and issues, it is not spinning around your skillset.
Have you considered that it's a plural "you" that you're choosing to pit yourself against, with different people each weighing different complaints?
Almost by definition, the people who argue strongly for free use of their hardware and software are almost never the same people who argue strongly for safety and security restrictions. You seem to be frustrated by a contradiction or inconsistency that doesn't exist.
It's true that Google can't win the hearts of both sides, but they surely know that -- you don't need to get so personally frustrated on their behalf. It's just a company with a product in a market, and the market is never going to be uniform.
It's an open-source program, it shouldn't be held to the same standards as a closed-source program that just shuttles all of your data to someone else's computer.
The risk here isn't misuse of the data, it's that some exploit is found in the code, and the additional protection of limiting its filesystem access is marginal (but nice to have).
Except SAF is slow as hell, working on multiple files means separate calls for every little thing like file size via java API. Means everything going to be VERY slow and drain battery a lot. I've seen test from 2019 where directory listing operation is 25-50 times slower in SAF
In a perfect world, what Syncthing does would be handled at the OS level and all OSes would seamlessly interoperate. In the real world the OS vendors are hostile to interoperability so the only way to get that is with a third-party tool that has OS-level access.
In reality, Syncthing is also pretty good at destroying battery life unless you go above and beyond to configure it in a way that then hampers Syncthing's ability to provide seamless file continuity between devices. I know that there will be disagreement here, but in my own opinion OS vendors are correct in being hostile to these apps under current circumstances. They could provide better ways to have third parties implement it and provide cross platform support for their platform solutions, but I've had Syncthing be the #1 cause of battery life drain on multiple devices and platforms before and it's honestly just not worth fighting with it. To get it under control relegates it to being not much better than rsync.
I think it's important to draw a distinction between OS providers and app store providers here. The fact that they're the same entity in most cases is or should be largely irrelevant.
OS vendors shouldn't make it impossible to create apps that have unlimited access to the filesystem or that suck battery in the background. There are reasons users might want to run apps that do either or both - a file indexer, for example. All the OS should do is ask the user if the app has permission to do those things.
An app store provider on the other hand might reasonably have many criteria for inclusion, such as F-Droid only allowing FOSS. This only becomes problematic when the app store in question is effectively a monopoly.
I want it to be able to browse to another app's private folder to sync the data of that app to my computer. If browsing to there it's not the job of syncthing then I need a file manager with those permissions.
For 3 years now I can't open my Downloads or Pictures folder without root, because their shitty API is unbelievely bad that it would take around 30 minutes to open a folder with that many files.
> Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.
Technically, the guy who inherited Syncthing Android maintenance destroyed it because he didn't want to use the file permission APIs.
Which, of course, is a reasonable decision for a maintainer to make when they're working with limited resources. But I have to say in this case I find some of the maintainer's behavior to be a bit surprising for a project as mature as Syncthing.
Or maybe this, plus Panic removing GDrive support from Transmit, plus iA dropping Android support from Writer because of it, point to a common perception that Google's API for doing things "the right way" suck to the point of unusability. If iA and Panic and Syncthing -- all who've supported Android for many years -- can't manage to make it work, then I suspect it's broken.
Google use to allow just any app to access the whole drive. That's probably too permissive. Now they've obviously swung too far the other direction, where even well intended, experienced devs are unable to work within Google's new constraints.
I guess I'm a bit at a loss about why these app developers feel they need access to things like medical records stored on the work phone of everybody at your doctor's office.
If they do need access to literally everything on the device, then it seems reasonable that they have to pass some minimum security bar. After all, several of the apps whose data they want access to are used to secure things like private medical records, classified information, etc.
At some point, the encrypted data has to be mounted as plaintext so apps can work with it. It seems reasonable to ask for some kind of permission system so that apps have to declare they need to read these files and so users can make a decision about whether to allow that access. But these developers are refusing to even ask for that permission.
We both know that first bit is a strawman, so we can move past it.
From the description of the people who wrote these apps, there are 2 basic APIs at play:
1. Get access to the entire drive.
2. Ask for permission to individual files.
I would have assumed there was a middle ground like asking for permission to a specific folder's contents, yet those same devs insist that's not the case. iA Writer users want to edit everything inside a folder. Syncthing users want to sync an entire folder. Transmit users want to select upload/download to/from an entire folder. If Google made those APIs available then we wouldn't be having this conversation.
> I guess I'm a bit at a loss about why these app developers feel they need access to things like medical records stored on the work phone of everybody at your doctor's office.
...which isn't a strawman. It's begging the question by presuming that authors actually feel such a need. I'm fairly certain the devs involved do not want or care about accessing medical records.
As to OPEN_DOCUMENT_TREE, to my naive eyes that's what it looks like to me, too. That said, I'm confident that the devs we've discussed here, particularly the ones who sell the related apps for their livelihood, are clever enough to read the docs and that they've ruled it out for some reason. I certainly don't think the Syncthing team is too incompetent to use a documented method if it magically did the right thing.
> . It's begging the question by presuming that authors actually feel such a need. I'm fairly certain the devs involved do not want or care about accessing medical records.
iA -- one of the cases you mention -- balked at needing a standardized security assessment to access the full Google Drive.
> In order to get our users full access to their Google Drive on their devices, we now needed to pass a yearly CASA (Cloud Application Security Assessment) audit.
Googe Drive as part of Workspace is HIPAA compliant (https://support.google.com/a/answer/3407054?hl=en), meaning medical offices can and do host medical records on Drive. It's not mentioned in the article why iA needs access to all files on a HIPAA compliant service.
Apple's position is different, because Apple never let you have this kind of access.
Android/Google Play review keep restricting APIs and replacing them with less capable APIs, or keeping the APIs and reducing functionality.
It works again, but I had a USB endoscope that stopped working because Google pulled APIs and took a while to replace them. I can't use location sharing in my choice of apps anymore because something on my phone blocks either app runtime, app internet access, app location, or gps decoding and I don't use it often enough to be motivated to delve through logcat to figure it out, if they even still let me use logcat?. I'm sure it helps my battery life, but it reduces the functionality of the phone.
SAF is a slow, buggy mess, and it only works in Java/Kotlin, so it's understandable that they don't want to use it. GrapheneOS manages to allow native access (via Java or machine code) to only specific user-selected directories through its Storage Scopes feature [1]. They basically did SAF but correctly and without the funding of a megacorp.
>They basically did SAF but correctly and without the funding of a megacorp.
It's also way more clunky for the user than using the file picker, and has the potential for user confusion because the app is silently denied access so it thinks the file/folder doesn't exist.
You're right, it's far from perfect, but it shows that it's not difficult to restrict native access to specific files/folders using the kernel and not weird Java IPC (which I guess should be obvious anyway). Google could've opted to provide native access to files, in addition to access via SAF, when you select a file via the picker, but they didn't. Graphene did it correctly from the low-level implementation side, not the UX side (but they can't really make the UX easier without breaking compatibility with standard Android apps AFAIK).
I think burn out on free projects is a real thing. Heck I get burn out on old projects and I’m being -paid- to maintain them. Good will and accolades only go so far and passion runs out eventually, especially if you’re only one person and there’s no one there to give you respite for a good recharge and you’re facing a hostile entity like Google.
On that note. what is with this modern trend of trying to pretend the filesystem does not exist.
why does google(or apple) need "special interfaces" to access the filesystem in a specific way, why don't they just use the existing file api and improve the file access permission system.
I think the unix single tree filesystem was one of their great innovations and see this multi tree api fragmentation bullshit as a sort of backwards regression.
You're nearly correct, actually. In addition to security, SAF was supposed to provide a consistent interface to access files from various sources, including network sources, not just the local filesystem. Unfortunately the implementation just kind of sucks.
For the overwhelming majority of users, the file system is a confusing implementation detail that often breaks something when they're forced or tricked into directly interacting with it.
it's how the cross platform software works and has always worked. demanding a total rewrite just to publish on a single channel is insane, especially since this used to be the ONLY way to do things.
google could always contribute to the open source app to implement the features they wish to see, but instead of using their billions for good they'd rather use it for evil.
"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."
It's going to be much less of a problem for everyone, with these draconian Play policies, as I imagine more and more people will be installing F-droid.
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.
To be fair, you're making the most used mobile operating system in the world and can't be bothered to make API bindings for more than one language? Or at least make the process easy so that someone else creates them? I am not an Android developer, but that seems also part of the problem.
fopen(), fwrite(), etc. are a part of libc and as such are officially supported [1], but they become somewhat useless with SAF. (It makes sense that you'd at least have to use some Java to open a file picker and request access, but why not provide native access as well when a file is picked?)
Yeah, Android has an immense churn of very low quality APIs with spotty support outside JVM languages and worse documentation.
Combine that with the fact that Android users are magnitudes less willing to fund apps (either by buying them or donating), and the result is an abysmal ecosystem that does not reward continued participation in it.
To be fair, it's really messy to do Go on Android calling back into Java because of how its runtime works. I'm not surprised they don't want to do it if it's a hobby project and it'd require making substantial changes to Syncthing's core logic.
It is - the way I always structured our architecture in this case was to write as much as possible of file handling in Java side and keep JNI surface minimal (it's also better for performance).
But that's really hard to do if you didn't begin with cross platform architecture that doesn't take into account having to modularize the filesystem layer for Android/iOS :/
Since you have such strong opinions on the matter, and experience, why don't you contribute to the SyncThing android app and implement this? Alternatively you could grab your time machine, travel back several years and let them know to anticipate this arbitrary change google would pull in the future.
I think it's because he doesn't have a time machine and doesn't have time to donate to rewrite someone else's project that the owner expressly doesn't want rewritten.
This is what we call "Put up or shut up". It's easy to bash someone for not wanting to spend many hours of their time to work they have no interest in, just because some third party is now demanding it. The change is absolutely arbitrary, also. There used to be no way to grant apps access to specific folders. This is when the app was written. This still works. Google's own apps work that way. But now Google has also implemented additional ways to access the filesystem, and they are demanding people who don't even work for them to rewrite their projects.
It would be understandable if they demanded new apps to adhere to these new policies. But blocking older apps, that were written when there literally wasn't an alternative available, to do a full rewrite or be banned from updating? Absurd.
If you are now claiming your question was rhetorical, it doesn't mean that when answered, it is snark.
> It's easy to bash someone
No one's being bashed. Lets put it in stark relief. Here's the bashing you replied to: "But that's really hard to do if you didn't begin with cross platform architecture that doesn't take into account having to modularize the filesystem layer for Android/iOS :/"
> The change is absolutely arbitrary
No, it isn't.
We can tell you know that, because you immediately say "There used to be no way to grant apps access to specific folders."
> But now
"Now" == "3 years ago"
> demanding people who don't even work for them to rewrite their projects
They're not demanding anything, other than Google demanding Google can't keep taking updates to an app they put on their store, with full filesystem access, 3 years later, unless they patch the filesystem access. As other comments note, there's plenty of storefronts for these situations.
n.b. it's dangerous to take updates with unpatched security flaws, because bad actors buy apps/browser extensions. This is roughly the minimal action Google needs to take to avoid being liable - it's been 3 years, it looks like complicity to claim its store is safe and secure, then repeatedly take updates to products on the store with known security vulnerabilities, for years.
> But blocking older apps, that were written when there literally wasn't an alternative available, to do a full rewrite or be banned from updating
Though interpretative charity, I'm guessing you mean Google won't put updates from the vendor on the store, unless the update includes stopping asking for full filesystem access with 0 alternatives.
Android being linux has exactly nothing to do with the fact that apps can't access resources outside their sandbox if they aren't mapped in somehow. Just like with lxc or docker containers on linux, jails on *bsd, or any other sandboxes.
The only linux thing is always the kernel. Userspace isn't linux by definition on any* system. That might seem like a pedantic point to make, but I would like to point out that gnu utils aren't required to make a system "Linux", and whether you're using a drop-in replacement like uutils or go a more different route doesn't make it any less "Linux".
Android Apps are and mostly always have been restricted to the Java virtual machine (or its modern equivalent) exactly because that makes them portable between sometimes quite different base systems from different vendors. If you insist that makes it less of a Linux system I'd like to know what you think of flatpak apps on top of immutable distros. I hope you agree that, conceptually, they're quite close actually.
I'd just like to interject for a moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!
It certainly makes it less Linux, as most people mean Linux kernel plus GNU userspace with glibc, or possibly muslc as alternative to glibc.
Nothing of that is expected to be supported on NDK, at least officially, Google and partners have the freedom to break those expectations as much as they feel like it.
And perhaps more to the point - you USED to be able to use normal Java file apis and syscalls outside of Java, but that functionality has been gradually whittled away (in the name of legitimate security improvement) over the years, meaning "basic" IO functionality your apps relied upon could be taken away at any point and replaced by less ergonomic Java-only APIs with less functionality.
Fun fact: the official Dropbox Android app used to use inotify to watch for changes to the publicly writeable synced files in order to sync back to the cloud! Had to be replaced by java Storage Access Framework APIs later.
Another fun fact is that the Android sdk came with a JNI wrapper around inotify but it buggily stored inotify handles in a static (global, within an app vm) dictionary, meaning you'd silently lose tracking if you created more than one Java file watcher object that happened to be for the same path, so I had to rewrite that JNI wrapper back in the day to avoid that global state bug.
Wait, I seem to remember this discussion from years ago and thought it was resolved. Back then, Google wanted to drop the "access all files" permission from Android's permission system entirely but IIRC Syncthing & file manager devs then convinced them to keep it. But now Google comes back at them with a Google Play policy that prevents them from using that permission in practice?
You have to ask permission via a form from Google and your app must closely fit a white list of use cases (file manager, etc.) Obviously there's a high chance they just say "nah". Definitely sucks.
> 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
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.
The most annoying requirement is their Play Store delete account url. We have an API where we can delete the user’s account. But no, Google wanted a stupid url.
Is it really that hard to set up a small proxy tool that calls your fancy api when it receives those requests? As an outsider, it does seem quite reasonable to me - Google couldn't possibly support all APIs there may possibly exist for every app there is.
how are you going to authenticate the user? now you need to solve that if you didn't have a web login before.
---
Guess @dang decided to rate limit my account again so I can't post replies :-)
> Some token that every account gets generated? It's really not that much to ask honestly.
How is the user going to know this token when they visit the website on their laptop? Keep in mind that the Google requirement is that you link to this delete page from the play store, where the user is not authenticated with your app. You can't just generate an URL containing this token.
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.
The app will work until Google decides to remove APIs it uses, which hasn't been put on a roadmap yet AFAIK.
This is just removing it from the play store, which is much picker about API use than the OS. The APK will continue to exist and run fine (though not developed, try a fork).
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.
> Android really needs to just allow direct file access to any file which is under a user selected folder.
It does.
Edit: downvotes don't change the reality that I am using SyncThing-Fork with no Storage permission granted to it. It's the very fucking feature this entire thread is about
Take the downvote button away from imbeciles. Or make voting public, god that would solve so many problems.
This is very likely the reason that your fork no longer wishes to be on the Play Store:
> 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.
> No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with a `DocumentFile`, which isn't a `java.io.File`.
You can call `contentResolver.openFileDescriptor` on a a `content://` Uri from SAF, and get a `ParcelFileDescriptor`, which can be turned into a real unix fd by calling `detach()` on it. Passing this fd into native code just works.
That's not to say that, you know, SAF is actually sane, though. `DocumentFile` lazily IPCs to some StorageProvider process every time you retrieve a property of the file (mtime, size, whatever). There are ways to speed this up by retrieving everything via the lower level `DocumentContract` API, but it definitely feels like it was poorly thought out.
>> Android really needs to just allow direct file access to any file which is under a user selected folder.
> It does.
I don't think it does for anything under Android/data/ directory though does it? Which might sound like nitpicking except that there are some apps which only store their data under Android/data with no option to put it elsewhere, which means that there is no way for syncthing to access that data.
People that aren't familiar with Android's proprietary labyrinth of a filesystem API, you mean? If you had provided evidence that it does instead of just saying so in your first revision, you probably wouldn't have been downvoted.
Sharing files? Probably. Reliably syncing files without interaction, and especially without requiring a central server? i don't think so.
The truth is, the android app has existed for over 10 years now and it has never been good. It kinda mostly worked for some use cases, but always-on continuous sync on battery wasn't really one of them. And that's been true even before Google justifiably started restricting filesystem access in KitKat(!) 11 years ago.
If you are looking for an Android app that does syncing in the background well, I can highly recommend FolderSync.
SFTP or SMB depending on your computer/server I guess, or any of the supported cloud options of which there are truly plenty. I'm using SFTP for everything.
FolderSync can do "on-demand" very well if you mean that you just want to tap a sync button to trigger it.
KDE Connect is great, but not for this use-case. SyncThing was absolutely the choice for automated syncing of files between Android and PC. KDE Connect just doesn't do that (AFAIK). The two tools serve pretty different purposes.
KDE Connect wasn't really reliable and easy to use while I did. And Syncthing pretty much eliminated the need to use KDE Connect for me. The only extra-feature of KDE Connect was sharing the buffer, and I just paste to Obsidian now instead (any text editor would do, but I don't know anything better, even though I hate it for being closed-source). Maybe slightly less ergonomic than KDE Connect in this regard, but it's negligible. And I don't need to send files, if I can just share files.
In fact, I think I never even connected the phone via USB since I started using Syncthing. Copying/moving to/from shared folder is amazingly both more ergonomic and much faster (I never learned, why moving files to Android device via USB is so insanely slow).
So I really don't know an alternative. It solved pretty much all my phone/PC sync needs. It also enables backuping the important stuff (I don't use Google for that, or course). Dropbox doesn't cut it either. I really don't imagine how would I use my phone w/o Syncthing, it's pretty much essential.
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).
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.
This is one of the few reasons I was still on Android over iOS. If Android becomes just as bad as iOS why would I keep putting up with Android?
It's exhausting dealing with operating systems that treat you like a child. If that's the choice I may as well not even have a "smart" phone. There's nothing smart about it anymore. It's become a toy with a camera.
I tried Termux and found the application files I wanted to rsync aren't visible in Termux, except maybe by rooting the phone. But I need to use banking and auth apps daily on it, so I assume that isn't an option.
You have to use `termux-setup-storage` to gain access to shared storage. If you're referring to an app's private app data folder, there's no way to access that without root via any app.
that would require you to set up a domain name and use DDNS and trust your registrar, or to just always have your computers at a static IP with no NAT blocking you whatsoever.
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.
I'm a big fan of Syncthing, and use it on Android as well as pc. But it seems they are relying MANAGE_EXTERNAL_STORAGE permission and I can't see a good reason for Google to go on permitting that in 2024. It gives an app too much power.
Android has had scoped storage for a decade now. Time to get with the program and start using the SAF.
It does feel very odd to be actually agreeing with the Goog on something...
Thank you google for killing yet another great app. There should be special category for apps that are "Done, Complete, Perfect as is", as with decent backwards compatibility on Android there should be no issues with them. I bet apk compiled for Android 1 still runs perfectly on Android 15.
Depends on the exact functionality. I'm aware of some battery events you could listen to from the manifest file in 2, that were removed at some point after that and now you have to listen for them from a running service. It broke a bunch of battery monitoring apps when it happened.
Also with services, there's additional requirements to keep them running that weren't there early on.
Android is one of the few platforms on earth where anything interesting actually could be done and finished, since they have actual stable API levels unlike Linux.... And they don't allow it
Once again, Im also in the niche of avoiding pay-for dozens of small services and just getting my simple stuff synced. Bam, another blowback. Im eager to ready what alternatives HN crowd might come up with....
What the heck, I literally come from upvoting another submission's comment about combining LocalSend with Syncthing [1], because the idea seemed great...
I am developing and supporting game engines for over a dozen years. It works pretty much on any device which can run games.
Supporting it for Android is the worst experience ever. This is by far the least reliable OS in terms of compatibility or changes they make. It gets more convoluted and crapier with every exec bonus and 'feature' google invents.
I used Syncthing for a while between various Linux distros, and I used Syncthing-Fork on my Android tablet, and it was okay when it worked, but it often borked up, and there were so many arcane settings and weird failure modes. I realized that the only reason I was using Syncthing was because it appealed to the vestigial, ultra-paranoid crypto-fascist BOFH in me, and I had grown out of those attitudes.
So today I just use Google Drive and MS OneDrive like a normal person. They work great. I love 'em. They don't fail like Syncthing. They're way more secure, and fully supported. Come join me! The water's fine!
Syncthing is peer to peer, the files are already on the device. There's no way requiring one more device to be secure (the server) is better than not requiring it.
...Does the author not understand that the Google Play Store is not the only distribution mechanism for apps? Why not just continue to distribute APKs for users to install manually?
I suspect it could be, however it sounds like the author has lost all motivation to continue work on syncthing android and has formally announced that no further development will be done. And as much as I like syncthing-android I appreciate this sort of straight forward communications more and salute the author for clearly stating intentions.
Now seeing as it is open source (hooray) The way I think that will go is as follows, we will continue using the existing apk(I get mine off f-droid) for a few months to years, in the meantime seeing as the app is so useful to so many a few forks will arise, one will end up being the best, and we will eventually start using that one.
Presumably because most people don't know about F-Droid, and there's a question of whether it's worth continuing to develop the app for a tiny subset of the original audience.
they do, but google play is the main distribution channel for android apps, and without that many people will not use it (and many will complain). from the actual announcement:
> without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance
They do set how permissions on upgrades of Android work so even if it’s on f-droid, when they enforce the SAF protocols fsync will stop working if you keep your Android up to date
The Google Play Store is a massive pain in the ass lately. For whatever reason Google wants me to continuously update my Android apps to use whatever the latest APIs are despite such apps being mostly glorified webpages.
The Apple App Store is a massive pain in the ass lately. For whatever reason Apple wants me to continuously update my iOS apps to use whatever the latest APIs are despite such apps being mostly glorified webpages.
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
reply