There is an Android Syncthing fork [1] which is active and 1.3K stars (for whatever that's worth).
replies(6):
> 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’m not sure why it can’t continue to be. Does anyone know why?
> 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...
That's gone very fast from "oh yeah!" to "oh no!"
> without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance
https://forum.syncthing.net/t/discontinuing-syncthing-androi...
Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
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.
Likewise they will be rather surprised to insist in targeting iOS/iPadOS/watchOS as if they are UNIX clones.
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 :/
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.
Granted, SAF is quite a shitty API.
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.
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.
I really can't agree with Google in this particular case.
It's in the description on GitHub. Get F-Droid.
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.
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 want to be able to get all data from my phone - regardless of what it is and what app put it there.
If I decide to only sync specific folders. So be it. But I want to be able to sync "/"
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).
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.
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.)
Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html
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.
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.
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.
---
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 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.
n.b. it wasn't arbitrary
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.
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.
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.
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.
FolderSync can do "on-demand" very well if you mean that you just want to tap a sync button to trigger it.
There's very few permissions on android that are system/privileged/preinstalled.
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.
Android really needs to just allow direct file access to any file which is under a user selected folder.
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.
NDK is only for writing native methods, reuse C and C++ libraries, and better performance for 3D and real time audio.
Anything else, is not officially supported by the Android team.
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.
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.
Also with services, there's additional requirements to keep them running that weren't there early on.
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.
> to do a full rewrite
No ones demanding this
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.
> The last release on Github and F-Droid will happen with the December 2024 Syncthing version.
but not even a hint as to whether that APK is likely to work in say 2027.
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.
The truth is Syncthing doesn’t have the resources to keep up with Android platform changes and Google’s review process.
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.
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...
Privacy and security are literally the reasons for these APIs. I don't see how you could possibly call that a strawman.
> I would have assumed there was a middle ground like asking for permission to a specific folder's contents,
Isn't that what OPEN_DOCUMENT_TREE does? https://developer.android.com/reference/android/content/Inte...
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.
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
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).
Syncthing-android is already written in Java, so shouldn't there already be JNI glue code? https://github.com/syncthing/syncthing-android
> It does.
No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with a `DocumentFile`, which isn't a `java.io.File`.
From their docs:
> It offers a simplified view of a tree of documents, but it has substantial overhead
https://developer.android.com/reference/androidx/documentfil...
----
Your fork uses `MANAGE_EXTERNAL_STORAGE` which Google Play heavily restricts:
https://github.com/Catfriend1/syncthing-android/blob/main/ap...
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.
https://github.com/Catfriend1/syncthing-android?tab=readme-o...
EDIT: The dangerous permission for `MANAGE_EXTERNAL_STORAGE` doesn't appear in the "App Info", which may be what you're seeing.
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
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!
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.
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.
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.
But don't expect the same polished user experience as with SyncThings
> 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.
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.
https://ia.net/topics/our-android-app-is-frozen-in-carbonite
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.
Workspace is also (at least partially) FedRAMP compliant (https://support.google.com/a/answer/13190816?hl=en). So similar questions arise as to whether iA needs to access federal data.
It really makes me nostalgic for the vision of webOS (although not the implementation of webOS from 14 years ago).
It's hard to fathom just how much damage smartphones have done to personal computing, but statements like these are a grim reminder.
There really is: https://puri.sm/products/librem-5.
And it's my daily driver.
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.
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.
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.
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.
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.
Google and Microsoft provision this stuff, even for consumers, with secure authentication and good protections.
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.
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.
> 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.
I feel like theyr'e doing this just to minimize storage costs or something lol. Android dev sucks for a hobbyist
> You're posting too fast. Please slow down. Thanks.
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.
If you don't have root, it's not your phone.
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!
4 years ago, there would have been zero friction for these use cases.
However: - You can't pick the root of a storage volume, only its subdirectories. This is presumably for your own good. - The application is still forced to use the SAF APIs, which are slow (each call requires an IPC) and overcomplicated. For working with multiple files, directory listings, etc, naive use of SAF can be a couple orders of magnitude slower than standard File APIs. This can be sped up, but it's never going to be anywhere close to native speed.
Apple accepted it with no questions.
Could you please review https://news.ycombinator.com/newsguidelines.html and use the site as intended instead? I don't want to ban you but it's not cool when people keep posting like that.
Btw, if you (or anyone) don't want to be rate limited on HN, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
(ps: I tried to get support about it and was willing to provide the company info just to keep getting on the platform, but the only answers that I got were "you must use this (non free) system to have your company verified" and then I tacitly said "screw this")
I can understand why the developers can't be bothered with a badly thought out new system.
Other than that, it boils down to:
" - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.
- Reuse your own or other developers' C or C++ libraries. "
From https://developer.android.com/ndk/guides
And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files.
Build your app in the recommended way, don't do weird stuff, read the guidelines. Accept drawbacks. That's more or less what you have to do, then the Play Store/App Store will be happy.
Build tools are mostly good with 1-2y old code, after that, yeah be ready to upgrade a lot.
One example of an API where we lost power in exchange for security was UIWebView -> WKWebView.
It can end up being far more annoying than usual, even for smaller APIs, because you must maintain both versions of APIs until you get the green light to raise the minimum permitted iOS version.
An app that syncs your files just needs access to those file, not the entire filesystem - which is what MANAGE_EXTERNAL_STORAGE gives it. Scoped storage and the SAF would allow syncthing to do exactly what it needs to do. The problem is that the app maintainer is unwilling to do the work to bring this app into the modern era.
> It's hard to fathom just how much damage smartphones have done to personal computing, but statements like these are a grim reminder.
Grim? Really? Personal devices containing highly personal information, coupled to a virtually friction-free global app marketplace, need on-device and supply-chain protections. As an Android dev I can find plenty to be critical of when it comes to Google's api designs and app review criteria. But in this case I agree with them.
And SyncThing can be implemented using SAF - it's "just" a lot of work and that's usually not enough for Play Store to grant exception.
That's not true at all though, `ACTION_OPEN_DOCUMENT_TREE` gives app permanent access to shared directory using the file chooser dialog. It needs no extra privileges or permissions outside user choice of dir.
If I make a new account it'll be free of the limit until dang gets upset again.
Android has been pushing to restrict the usage of such features for a while. It sounds like now they finally pushed hard enough that Syncthing broke.
As a longtime Syncthing user I'm personally fine with this. I think its fair for Google to demand a certain minimum bar of polish for apps on the Play Store. I'll continue to use Syncthing on F-Droid so long as its feature set continues to make it superior to those more polished alternatives. Hopefully the absence of Syncthing on the Play Store will create an opportunity for another file syncing app to fill that void, or incentivize contributors to eventually bring Syncthing up to snuff to get back on the Play Store. (Or possibly, incentivize Google to develop tools to make it easier for low-budget apps like Syncthing to meet their quality standards.)
[1]: https://github.com/syncthing/syncthing-android/issues/1048#i...
It's all those little convenience features that make KDE Connect a great tool for my needs. It's only the file transfer features of it that don't live up to my needs, but for that we've got SyncThing (and probably tons of other perfectly valid options that I've never tried, too). For continuous file sync / transfer, SyncThing has been just "set it and forget it" simple for me. It just "does the thing" and keeps on doin' it reliably. :)
At least the parts it can access, anyway: /storage/emulated/0
Try asking an elderly user of an Android phone where the attachments from gmail they have tried to save are stored in.
I think they'd cope a lot better with a standard folder/file hierarchy as opposed to saving into a folder/file hierarchy but never at any point telling the user where in the hierarchy they saved to!
And every app saves to a different location. I've been using computers my entire life and I generally have to resort to a file manager to find what I'm looking for.
> And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files
You might as well just axe the entire NDK if you're worried about unsafe code.
If I want to back up my entire filesystem, accessing all my files is not too much permission. If I don't want to back up my entire filesystem and I don't want to allow an app all those permissions, there is a very simple solution: don't install the app. There's also a more complicated workaround: use GrapheneOS and set up storage scopes for the app. Now instead of these perfectly functional options that already existed, the choice has been removed.
> But in this case I agree with them.
I am not an android dev but I'm reading in this thread that there are other apps like file managers that still get this permission approved? If google were removing the permission entirely I could see an argument from an api maintenance burden perspective, but if it's a permission they're still granting to some apps then I simply have to disagree.
This perfectly encapsulates the modern tech enshittification treadmill that I loathe.
Redesigning the wheel every 2 years because some braindead MBA dreamed up another way to arbitrarily ruin things that work.