The escape hatch is to use the FDroid version rather than the Play Store version.
Almost no apps need this permission, so being skeptical makes a lot of sense. File managers and other such apps are routinely permitted to use this permission, so it's not like Google is locking out utility apps or anything.
The current state of Google Play is the result of years of Google being too permissive by default and trying to patch things later while desperately trying to remain backwards compatible. Give advertisers a finger and they take the whole hand. Your average Android phone's internal storage used to be full of dotfiles, hidden directories, not-so-hidden directories, all full of identifiers and cross-identifiers to break the cross-app tracking boundary enforced by the normal API.
As far as I know, Google has made an API available for picking a directory to sync with. I'm not sure why NextCloud needs to see every file on my SD card when it can ask for folders to sync into and can use a normal file picker to upload new files without going through a file manager, but there's probably a feature somewhere hidden in their app that necessitates this permission.
The policy itself makes a lot of sense and I'd argue is beneficial for Google Play's user base. NextCloud's problem seems to be that Google isn't letting a human with common sense review their upload. Because of Google being Google, outcry is the only way to get attention from an actual human being when it comes to app stores (Apple has had very similar issues, though they claim their reviews are all done by humans).
EDIT: NextCloud states "SAF cannot be used, as it is for sharing/exposing our files to other apps, so the reviewer clearly misunderstood our app workflow." as a reason for not being able to use the better APIs, but I'm not sure if that's true. SAF has a dedicated API for maintaining access to a folder (https://developer.android.com/training/data-storage/shared/d...). I think NextCloud misinterpreted Google here.
Wrong. The current state is a result of Google monopolizing the android apps market. They should be split into 5 different companies.
I do not care about the reasons Google think they are protecting me. They are protecting their absurd profit.
For example, the Kiwix app was able to read .zim files directly from SD card (which you very much want to do since e.g. Wikipedia is >100 Gb). Not anymore.
They haven't implemented the feature yet, at the moment.
That’s exactly what the EUs “digital markets act” was created to address. In a true market there are no walled gardens, the market is accessible to all.
Personally I think it’s not enough and that they should also be split up. Ideally I feel any corporation should be restricted to a single market segment or trade category.
It certainly doesn't have the permission that NextCloud says it needs.
https://developer.android.com/reference/android/Manifest.per...
This permission still doesn’t have the same access as the backup utility, but that is another issue really. If they aren’t willing to open that up then they need to allow for pluggable 3rd party storage backends.
this is the second rebuttal you have made that is covered there.
> SAF cannot be used, as it is for sharing/exposing our files to other apps
What I am saying is absolutely not covered by this statement, which is factually incorrect.
“For example… anti-virus apps… file manager apps, backup and restore apps, and document management apps“
https://developer.android.com/training/data-storage/manage-a...
NextCloud provides backup, restore, and document management.
I guess you may know more about this than the official android docs, but maybe you are just being blinkered by some incorrect assumption?
Maybe we would be best to frame this another way. What permissions do NextCloud need to be able to replicate “Google One”? The complete replacement of Google drive (the service, not the app - you are consistently conflating the two) is what they aim to be. Is that something that can be done with SAF, or are Google using elevated permissions to lock competitors out?
It's true some of our functionality can be rebuilt if we rewrite this functionality with SAF - even though it makes the user experience a bit worse. We have a file manager/document management app, which fits the use case for the full permission. There are some functions that are popular with some users like syncing a whole SD card, the download folder or the data of specific apps (in Android/data - some users use our app in a way as backup) that are just not possible with SAF. We get the security concerns from Google, but Box has this permission, so do quite some others, so our preferred solution is to re-gain the permission rather than bring back part of the functionality.
The good news is that this morning Google got back to us and told us that on resubmission we will regain the permission we need and our users regain all functionality within a few days.
So, this seems to have been resolved in a nice way. Thanks, all for the support!
Bad guys should be thrown into jail.
Also, unsurprisingly, data/ and obb/ are also forbidden, so the API is unusable for a backup tool.
The available APIs are a pain to work with and have terrible performance. And it doesn't work at all with native code.
Also what about people using Nextcloud to back up their phones? It would need access to everything.
If I want to give an app access to all my files, google shouldn't have a say in that. Their paternalism is pervasive and palpable.
File managers Backup and restore apps Anti-virus apps Document management apps On-device file search Disk and file encryption Device-to-device data migration
This Nextcloud app seems to be an app that mirrors your Nextcloud storage to your device, and I cannot understand why it would need all access to any other data stored on the external device -- with the enormous risk that entails -- much less that can't be selectively picked by the user. It isn't a file manager, it isn't a backup utility, it's a cloud provider with local mirroring. I get why Google told them to do things otherwise.
Another comment mentions this is "bad faith" security and that's just overly cynical. Android and iOS both suffered from basically trusting app developers, and both were burned for it. Hardening down and making apps only request precisely what they actually need seems to be a massive user positive.
[1] - https://developer.android.com/training/data-storage/manage-a... - the exclusions can be found at the bottom.
> what they actually need seems to be a massive user positive
So positive for the user that they filed a bug report about it?
>I suspect people want their entire photo folders mirrored into Nextcloud from the device
That isn't remotely the contention, nor do photos even qualify for this as they use a different API. Further, the reason this company gives for refusing to use the obviously more suitable structured storage API is that they don't want their files -- presumably mirrored from the cloud storage -- visible to other apps. Their complaint is technical nonsense and doesn't pass an ounce of scrutiny.
The argument by this company is nonsensical, and their argument seems to be "we did it this way before and we don't want to change". Firstly they can have their own app storage without granting access to any other app, and they can go through a system UI process to get access to additional folders (for instance "I want to back up my WhatsApp folder to this cloud provider"). They argue against the latter because they seem to think it somehow reveals the former, but that isn't the case whatsoever.
[1] - Well it's a bug in the Nextcloud product where they seem to just ignore that the instance lacks a permission
I think they're trying to keep their story simple, for the sake of clarity. I believe the nextcloud team when they say they need the permission.
Part of the issue is that nextcloud has many use cases, including ones where your files don't get synced to your mobile device until you touch the file, replacing them with a reference to a file. It's cool cause you can access and manage a tb of pictures or documents from a 64gb android.
I don't (and I do use NC). The sentence "SAF cannot be used, as it is for sharing/exposing our files to other apps" is simply wrong and llm_nerd is right that SAF should be able to handle that use case,see
https://developer.android.com/training/data-storage/shared/d...
There are some restrictions regarding which directories you can access, but for most use-cases it should be perfectly fine. It's also not that this should come as a surprise to them. In fact, there's an issue about this from the NC team themselves from August '22:
https://github.com/nextcloud/android/issues/10123
Why they still think SAF cannot be used is a mystery to me.
Even if that interface is insecure and harmful to users ?
As an industry we've learnt a lot about how apps siphon and sell your data. And I appreciate this probably doesn't apply to NextCloud but it can be difficult to build an API that is flexible and secure so you will get casualties.
It's obviously not a security problem or a harm when used by an open source file synchronization app, and Google is being unsophisticated with its policy here.
https://www.bleepingcomputer.com/news/security/apps-with-15m...
https://www.zdnet.com/article/phantomlance-spying-campaign-b...
https://www.welivesecurity.com/2023/05/23/android-app-breaki...
There are also examples of apps using the filesystem to try to detect rooted devices, an invasion of user privacy:
https://www.reddit.com/r/Android/comments/g6cdl6/apps_have_a...
But does the policy solve this problem? The first link is a file explorer app. In theory that app should be granted the permision by Google. They could get established and then start collecting data later. So how does the policy help?
In practice the only way it helps is by Google basically telling everyone other than big trusted orgs no, and that's not an open ecosystem.
Why not just give the user a big fat warning, even telling them that apps which request this permission have been known to steal data in the past, then let them decide for themselves?
> that's not an open ecosystem
No, it is not. Did someone claim it was?
The open ecosystem of Android is that users can choose to install apps from any source they like. Apps like Syncthing-Fork and (full-featured) Nextcloud are available from other sources including F-Droid. Google does a couple things to privilege its own store, though I think those are being mitigated due to legislation and litigation.
No, we said that's what we want it to be.
(btw, not singling out Google - IMHO Apple is bad here too. This duopoly in the smartphone space is a major PITA)
So a backup app should add support for every Android application that the user is likely to back up?
For example, without using Google'' backup you can't backup the data of other apps, such as games' progress.
Exactly. Many people use Nextcloud's auto-upload to backup important data from their phone. In addition to photos, I use it to backup FreeOTP and WhatsApp, for instance. This does not work with the version from Google Play, see
https://github.com/nextcloud/android/issues/14334
EDIT: After some research, I think even that use case should be possible with SAF, you just need to move your backups to external storage that you can access via SAF.
it stopped working well or at all over the last 2 years or so. I think if a simple "allow access to the photo folder" would have fixed it they out have used it. maybe it doesn't get the events when a photo is made?
Then request access to their media folder. You don't need full disk access.
PDFs that I download live in downloads folder (which you can't give access to for some reason anyway).
Music lives elsewhere and so on.
Downloads is blocked because it would include everything you download, possibly including private stuff you don't want other apps to access. Just save the stuff that you want synced to a different folder.
I guess if you really want everything synced (e.g. doing a full device backup) then that would fall under Google's exception for backup apps and it would be allowed full disk access. Those are kinda separate use cases though. Maybe Nextcloud could make a separate "Nextcloud Device Backup" app which does that?
- If you want to lose time for 2 hours, please do yourself this questionable favour but I do not want to do that because some "wise" people cannot comprehend that some people want copy of entire thing, not one folder, entire thing.
> Downloads is blocked because it would include everything you download, possibly including private stuff you don't want other apps to access. The point: This is cloud application that connects to server that sits on my desk on NUC.
Do you understand that in the (Google)-(Open Source)-(Own Server) the Google part is one that most reasonable people consider not private.
> Just save the stuff that you want synced to a different folder.
Do you move entire folders or every file each time you download something because app cannot backup it - or do you change app. What if that's the only app that does it privately?
> Those are kinda separate use cases though.
Maybe it is not system developer job to decide for me that I want to give application the permission to do what I want application to do. It is not system nor developer job to stop owner (administrator) from what owner decides to do.
> Maybe Nextcloud could make a separate "Nextcloud Device Backup" app which does that?
Maybe competitors should not have permission on deciding what their competitors should do.
Google essentially makes everything private so cumbersome to use that it own solution seems easy.
>it makes sense to let the users give it access to all the files on the phone
It doesn't even pretend to be a backup app, and further the permission we're talking about is limited to external storage (though that is a nebulous term on many Android devices where internal storage is split-brained on being internal and partly external).
Further saying "let the user decide" works great in theory and with a considered, rational userbase. In reality it means that everyone just says sure to everything, and soon all of the user's data is exfiltrated and everyone is whining that Google/Apple/et al should have forseen this.
I see your point, but why isn't this the case for document management apps? Also, Nextcloud can be extended with plugins, some of them falling in the document management category.
> Further saying "let the user decide" works great in theory and with a considered, rational userbase.
Nextcloud is mostly used by people that like to self-host their services, so in this case we fall into the rational userbase category.
https://play.google.com/store/apps/details?id=com.simplemobi... or on github.
What they do after opening the files is very different, and irrelevant. FWIW I use both Nextcloud and that gallery app.
https://www.androidauthority.com/simple-mobile-tools-acquisi...
Use the Fossify fork instead:
https://play.google.com/store/apps/details?id=org.fossify.ga...
I'm sure they would happily allow you to select the folders you want to give permissions to, but I think that's not possible anymore.
So if you want to sync a local data folder that stores, for example, the tracks you record with your GPS, you cannot do it without full access unless your GPS app allows you to select a shared folder to store its data.
0: https://developer.android.com/about/versions/11/privacy/storage
1: https://www.theregister.com/2025/05/13/nextcloud_play_store_complaint/
You can select any file you could before on shared external storage. You can't select private app directories which were always off limits from other apps just like on iOS.
---
[0] On Android 11 (API level 30) and higher, you cannot use the ACTION_OPEN_DOCUMENT_TREE intent action to request access to the following directories:
- The root directory of the internal storage volume.
- The root directory of each SD card volume that the device manufacturer considers to be reliable, regardless of whether the card is emulated or removable. A reliable volume is one that an app can successfully access most of the time.
- The Download directory.
Furthermore, on Android 11 (API level 30) and higher, you cannot use the ACTION_OPEN_DOCUMENT_TREE intent action to request that the user select individual files from the following directories:
- The Android/data/ directory and all subdirectories.
- The Android/obb/ directory and all subdirectories.
[1] On Android 11 (API level 30) and higher, you cannot use the ACTION_OPEN_DOCUMENT intent action to request that the user select individual files from the following directories:
- The Android/data/ directory and all subdirectories.
- The Android/obb/ directory and all subdirectories.
0: https://developer.android.com/training/data-storage/shared/documents-files#document-tree-access-restrictions
1: https://developer.android.com/training/data-storage/shared/documents-files#document-access-restrictions
edit: fixed readability and a link
Google Play, or at least that's what they say in their docs, might allow the use of the MANAGE_EXTERNAL_STORAGE "all files" API call "...if your app includes a use case similar to any of the following: File managers, Backup and restore apps, [...] Document management apps ..." [0][1]. And the Nextcloud app sounds very similar to that.
Of course, it's all "Subject to Google Play review and approval.", but why they used to grant that permission to Nextcloud with no problem and revoked it suddenly... I have no idea.
---
0: https://developer.android.com/training/data-storage/manage-all-files#all-files-access-google-play
1: https://support.google.com/googleplay/android-developer/answer/10467955#zippy=%2Cpermitted-uses-of-the-all-files-access-permissionThing is, Nextcloud doesn't need that permission since they can do what they do now with SAF which is how Google determines eligibility for the exception. That is - if you can do it with SAF, you don't need complete access to all private data via MANAGE permission.
It is correct that you cannot access private app folders, meaning stuff like /data/data, /Android/data, /Android/obb. But this is nothing new and you basically need a rooted device to access them. You can however access anything on external storage, which is typically where apps would store data you would want to sync and which would cover by far most use cases from users. At the moment, users are mostly complaining that only media files are synced, but not documents. SAF would solve this.
> I'm sure they would happily allow you to select the folders you want to give permissions to, but I think that's not possible anymore.
That is absolutely possible:
https://developer.android.com/training/data-storage/shared/d...
So, following a bit the example I was giving, if you want to sync data from another app to backup it (or whatever), and that App stores its data in the default data folder assigned by Android, since Android 11 it's going to be very difficult to do it.
I used to sync some of those folders with Syncthing in Android, and since Android 11 things have gotten complicated (meaning, you need 'all files' access, and even then, some things might not be accessible). [0]
0: https://forum.syncthing.net/t/android-11-and-syncthing-what-can-be-synchronised/17100/2The Google Play store (not Android the OS) is now limiting access to the old API, it has nothing to do with Android 11.
The new API does not work with Linux open(). Some projects (like Syncthing) don't want to put in the work to switch to the new API.
I hope that clears things up.
Not very familiar with the NextCloud client, as I haven't used it much, but in the case of Syncthing (and this is totally guessing from what I remember from reading the forums back when the Android 11 upgrade happened): I don't think they don't want to put the work to switch to the new API, I think they want to access places they won't be able to access with the new API, so that's why they won't change the calls.
From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that, doubly so when you're using a library that expects regular files, plus performance is somewhat lacking, too (judging from complaints and bug reports I've seen, both in that it is easy to run into performance pitfalls, but also that even best-case performance is still worse than classic file access).
[1] I think something like that was actually implemented for Android 11 onwards, judging from https://source.android.com/docs/core/storage/scoped#using-sc...? Although possibly still at some noticeable performance cost.
That pretty much matches my experience. Single file picker flows can often be implemented with a simple callback.
But for folders it falls apart.
Thanks for mentioning scoped storage. Maybe that provides some sort of solution. I vaguely remember when I was first dealing with this circa 2021 that they had some sort of a low-performance solution that was supposed to work for NDK code.
SAF provides both provider and consumer APIs, and from the language NextCloud uses, I get the feeling they might've missed the consumer API here. Had NextCloud said "we want the user to be able to select the Download folder and certain external media directories" then I would've thought the restrictions are the main problem, but that doesn't seem to be the case here.
I went through the same with Syncthing, and now I install it from out of Google Play, where it doesn't need Google approval to do the All Files Permission API call.
I understand why the API changes and the hardening of the Android system, but it's also true you're locked out from certain folders even when on developer mode and it feels weird.
Meanwhile google drive gets to be installed as a system app
Right, so you don't know the app. What about getting informed first?
I use Nextcloud to backup files to the cloud. I want it to access my files.
Perhaps you should get informed as well.
In the end this is again app developers refusing to do the work to protect privacy and trying to push through the laziest most privacy voilating solution because it's less work.
What did I say that was wrong? The comment I was answering to - that I assume you read - says: "This Nextcloud app seems to be [...] It isn't a file manager, it isn't a backup utility, it's a cloud provider with local mirroring."
Which is wrong, isn't it?
So let me ask you, how does this:
> Hardening down and making apps only request precisely what they actually need
Relate to Google Play Services? It seems to relate only to third party apps, doesn't it?
File sync tools need to go through scoped storage where you as a user select directories which they sync and then they can read them at will as well.
The performance is a bit worse but for background syncing it's not material.
How would one use the Java APIs from a Go application?
I'm used to the reverse, Java calling external library.
Usually you'd make a Java/Kotlin/Whatever class that does the JVM code (e.g. calls out to Android, retrieves the list of files, processes that and prepares the most reasonable subset of data to be passed into Go world) and then use JNI APIs to instantiate it and call it.
(Alternatively, you can instantiate such a proxy class at app startup and pass it into Go world when you call into it for the first time.)
Still, that would be a very large change to incorporate, given the current Syncthing app is just a light wrapper of the main Go application as I understand it.
An alternate spin on this is that a project than runs on around ten operating systems would like to maintain a common codebase for its core functionality.
And perhaps using GrapheneOS while at it.
It could change in future devices, but currently there's not much stopping you from doing whatever you want with your Pixel's software.
I just find it ironic that I mostly deGoogled my tools, but still I would consider a Pixel with GrapheneOS :-).
As long as Google doesn't remove the ability to sideload apps, Android users are fine.
Not really in the EU? https://support.apple.com/en-us/118110
And distributing apps like that requires paying an annual per-install fee:
https://developer.apple.com/support/core-technology-fee/
So yes, IOS apps in the EU require both Apple review and a recurring per-install fee.
> The DMA requires that app developers should be able to inform customers of alternative purchasing options outside of the App Store, and direct customers to those alternative payment options, free of charge. Apple’s rules currently do not allow for this …
(plus: criminal contempt referrals for "willfully" violating court order to stop doing that in the US too and lying to the judge and trying to cover it up!)
> Separately, the commission has taken a preliminary view that Apple has not complied with its obligation to allow for the distribution of apps outside of the App Store, i.e. its support for third-party app marketplaces in the European Union is not good enough. The commission says developers are disincentivized from doing so due to the required agreement of alternative business terms, which includes the Core Technology Fee. It also says Apple has purposely made the process of using alternative app marketplaces too difficult and burdensome on end users.
https://9to5mac.com/2025/04/23/apple-fined-500-million-euros...
b) Apple is charging a fee for their SDKs similar to Unreal Engine, Square, Mapbox, Microsoft etc. Has been the standard in the industry since forever.
Apple is using all power-plays to keep their market controlled firmly by them, and EU doesn't like it.
Having to pay 99$ per year to develop apps for your own devices that you've already purchased is also outrageous.
I get that Apple is doing a good job keeping app-store safe for it's users, but it doesn't make up being so actively hostile to user freedom.
"sounds outrageous" is a pretty weak justification for regulator action. Paying for a browser probably sounds equally as outrageous, but with the way anti-trust is going with Chrome/Google, that seems like a very real possibility. Moreover, why should the government should be in the basis of regulating business models? If Apple wants to charge for access to its SDKs, and it pays the price through less apps for its users, so be it.
If Apple wants to be on the EU market they will have to comply with EU regulations, and if regulations are lacking regulators will regulate.
Whether you suck up to Apple or the EU is your opinion. I live in EU and I'm happy to see the otherwise sparsely regulated megacorporations from USA be regulated to not exploit my fellow union citizens.
Apple has also shown repeatedly that they're unwilling to comply by implementing their own shitty interpretation of our rules (ship a fucking USB-C adapter with your phone when we're demanding USB-C in the device, this markets act notarizaton and "core fee" bullshit).
I don't know if developers are still not allowed to advertise alternative payment methods, but it's just one step too far.
This is moving the goalposts. Both my comment and the comment you first replied to was making normative statements about government policy, not questioning whether they have the authority to make such laws.
"Pretty outrageous" is good enough for me, if Microsoft tried to start charging for access to Win32 it would not succeed in any way, legal or with customers (it would be abusing market power), but because Apple has a strong hold on their users already they're supposed to just fall over and be fucked by fees that completely ruin any kind of "not very monetizeable" app because of their made up business rules? Markets are regulated everywhere, why should Apple be treated differently because they started from a different position?
You can spare me the reply
Just last week, while looking for a password app, they had a "validator" app with in-app purchases using the old google authenticator logo in the #1 position. Worse it was an ad; someone saw all of that, both as an ad and as an app, and let it go.
Apple's prison actively cooperates with criminals to run scams on you that you cannot avoid.
On second thought, it sounds exactly like a real prison. On second thought, great analogy!
This is false. See https://support.apple.com/en-us/118110#:~:text=a%20combinati...
> It doesn't care about the content or type of app you're building.
But it does care about whether you've paid money to Apple for every install. https://developer.apple.com/support/core-technology-fee/
Android is just a shitty version of iOS now.
I tried to get away from it by talking to my bank's managers. They couldn't get rid of these checks for me. Talked to their developers about access to bank APIs so I could create a literally custom app just for myself. I discovered that due to regulations I need permission from my country's central bank to interface with the banking system. Even a read only app for a single account under my name needs government permission to exist.
It made me wish cryptocurrencies hadn't turned into stocks.
Labels: [MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY, MEETS_STRONG_INTEGRITY]
So I don't think remote attestation is the issue here, but it could be the app detects it by some other way
[0] https://developer.android.com/google/play/integrity/addition...
Cryptography is great when it empowers us. It sucks when it's used against us.
There have been so many examples of companies, especially big tech, rolling out updates in the name of "security", that just turned out to be a way for them to tighten their control over time.
Get outta here.