Nextcloud cries foul over Google Play Store app rejection(theregister.com)
theregister.com
Nextcloud cries foul over Google Play Store app rejection
https://www.theregister.com/2025/05/13/nextcloud_play_store_complaint/
232 comments
This permission has been a security issue since its introduction. Random apps have been caught iterating over used media to extract geolocation history based on EXIF information and other such metadata (for no good reason, data collection for data traders), so Google did the right thing and made file access permission-first.
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.
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.
What permission does Google drive have? That is the permission that NextCloud should be able to use in order to provide comparative features. People use NextCloud because they want to host their own “cloud” at home. If Google don’t let Nextcloud use the same permissions as their own services how are they supposed to do that?
Not allowing third parties to use all of the platform features is the kind of behavior that people used to call Microsoft a monopolist. In that lens I'll never understand anybody who thinks Microsoft was a monopolist in the 90s but think that Google is not now.
Google absolutely is, but through lobbying they have managed to retain an antiquated definition of what the “market” is. I.e they would say it’s the mobile market, whereas the reality is that it’s now an “android” market and an “iOS” market.
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.
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.
Does Google Drive have the ability to synchronise arbitrary locations? I haven't used it in ages, but I don't think GDrive has any special features or abilities that NextCloud doesn't have.
It certainly doesn't have the permission that NextCloud says it needs.
It certainly doesn't have the permission that NextCloud says it needs.
When referring to google drive, I meant whatever the app/service is that backs up your device to Google Drive. As you cant switch out the backend that uses (it is hard coded to use google drive), you would need the same permissions in order to replicate it.
Device backups are an entirely different system, not handled by the Drive app, that produces opaque backup archives which aren't accessible via the Drive UI. Nextcloud isn't complaining about lack of access to this system, but to the file-level APIs (e.g. java.io/java.nio classes) that allow for full backups of whatever the app has system-level permission to read.
According to the article they are complaining about not being granted the MANAGE_EXTERNAL_STORAGE permission.
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.
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.
Define "storage backend". You can implement a FileProvider to plug into the Storage Access Framework as a provider, so other apps can browse and request permissions for all of your app's files. You can use the Storage Access Framework as a consumer and ask the user for permissions to read any directory on external storage that is not Downloads/ or Android/{data,obb}, and any files exposed by other apps. Google's own apps use these APIs and do not declare MANAGE_EXTERNAL_STORAGE.
Maybe you need to actually read the article…
this is the second rebuttal you have made that is covered there.
this is the second rebuttal you have made that is covered there.
I have read the article, thoroughly, as well as Nextcloud's blog post. This is the extent they have to say about why they cannot use SAF:
> 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.
> 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.
“some apps have a core use case that requires broad access to files on a device, but can't access them efficiently using the privacy-friendly storage best practices. Android provides a special app access called all-files access for these situations.”
“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?
“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?
Hi folks,
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!
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!
[deleted]
On Samsung devices you can backup to a Samsung account also.
> Google has made an API available for picking a directory to sync with
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.
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.
NextCloud currently has to copy all files that it wants to upload & back up to its own app directory which is pain to actual usability. I'm guessing this annoyance is also related to these fun permission limitations.
NextCloud can request permanent access to a folder on internal storage and read & sync those directly. That's how KDE Connect does it.
They haven't implemented the feature yet, at the moment.
They haven't implemented the feature yet, at the moment.
Yep, and it extends to many other apps.
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.
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.
The API seems to have some peculiar restrictions, specifically that you cannot share the Downloads folder and no entire SD cards (only subfolders on the card). Maybe Nextcloud offered this functionality before and so couldn't restore it with the new API?
Also, unsurprisingly, data/ and obb/ are also forbidden, so the API is unusable for a backup tool.
Also, unsurprisingly, data/ and obb/ are also forbidden, so the API is unusable for a backup tool.
data/ and obb/ also weren't accessible with the "manage all files" permission, nor were they accessible to built-in apps from Google (except the ones that own the files, of course).
Google broke backup, so the only way to get an e2e setup is with nextcloud. Obviously, a nightly backup of the phone can’t rely on user intervention.
SAF only requires user intervention once.
SAF documentation seems a bit misleading: takePersistableUriPermission part only talks about files, but other sources seem to indicate that it also works for directories so it should be possible to request permissions to a directory and then maintain it correctly.
Good guys should be able to iterate the files to help users achieve their goals.
Bad guys should be thrown into jail.
Bad guys should be thrown into jail.
> The current state of Google Play is the result of years of Google being too permissive
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.
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.
Google specifically allows the use of the permission[1] if the app falls in a set that truly require it to function.
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.
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.
Depends how you use it: I suspect people want their entire photo folders mirrored into Nextcloud from the device, which would fit under the "backup utility" category.
> what they actually need seems to be a massive user positive
So positive for the user that they filed a bug report about it?
> 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, which would fit under the "backup utility" category.
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.
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.
yes, exactly - it has an "AutoUpload" function that worked super well. Make a photo and by the time you put the phone down its on a folder on your desktop read for say putting something on eBay.
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?
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?
> people want their entire photo folders mirrored
Then request access to their media folder. You don't need full disk access.
Then request access to their media folder. You don't need full disk access.
WhatsApp media lives in separate folder.
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.
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.
You can grant permission to multiple folders you know.
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?
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?
> You can grant permission to multiple folders you know.
I had to deal with another application (the only one that I found that for using my webdav solution does not automatically want to collect data and send it somewhere else) which instead of make backup of SD card was backup one folder - set server, password etc. for ONE folder PER backup action.
- 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.
- 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 is a long-standing policy, not a "bug"[1]. Further it isn't the users complaining, it's a company of a fringe "cloud" product. I'm going to be gentle here and say their app looks incredibly shitty, and I suspect they saw an opportunity to get some free press on the "Google the monopolist" angle.
>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 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
It is the users complaining, or rather specifically a user: https://github.com/nextcloud/android/issues/14135
The user is complaining that the app isn't using the proper APIs. For instance in the case of the "exactly" guy, the app would use structured storage APIs to let the user grant permissions to backup their WhatsApp folder. Instead of fixing their app the company instead whines to the press and gives technically nonsensical rationale for why they can't just do the work necessary because "we did it this way before and they let us for a while, so..."
> to let the user grant permissions to backup their WhatsApp folder
So a backup app should add support for every Android application that the user is likely to back up?
So a backup app should add support for every Android application that the user is likely to back up?
No, not at all. The new API simply presents a directory picker to the user. The user can give your app access to any directory.
Any directory that Google lets you access, which is very far from every directory.
For example, without using Google'' backup you can't backup the data of other apps, such as games' progress.
For example, without using Google'' backup you can't backup the data of other apps, such as games' progress.
9 years of the api working, then Google shuts them down. I expect an interface to be consistent after working for 9 years.
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 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 believe the nextcloud team when they say they need the permission.
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.
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.
> I expect an interface to be consistent after working for 9 years
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.
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.
How is this interface "insecure and harmful to users" ?
Shady apps use file access to do tracking of various sorts and simply ingest private data that has nothing to do with their nominal purpose. Sophisticated users probably wouldn't install those apps, and certainly wouldn't agree to their request for filesystem access, but that's not who Google is trying to protect here.
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.
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.
Maybe they should not remove APIs for open source apps then. If you can vet the source code and the app has been built from the source code you vetted, then there is no point in removing capabilities for reasons other than market monopolization and extinguishing features for non-Google developers. After all, these security rules don't apply to Google themselves.
(btw, not singling out Google - IMHO Apple is bad here too. This duopoly in the smartphone space is a major PITA)
(btw, not singling out Google - IMHO Apple is bad here too. This duopoly in the smartphone space is a major PITA)
It really could.
Do you have links to stories about any of these shady apps that have now been stopped by this policy?
Most of the time, when apps are caught doing something really shady, they're removed from the Play Store for doing the shady thing. A story wouldn't report that they stopped working because of a policy change, but some of these wouldn't make it into the store now:
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...
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...
I'm a user. I install through fdroid, but I am complaining. This also makes corporate roll-outs more difficult.
The app is a competitor to google drive (app). It is used to upload/download, backup, syncronize (one or two way) files, media and documents between the device and the cloud. Doesn't that cover more than one of the mentioned uses? Why would FilesyncPro (example) get to have the permission but not nextcloud client? Even for media files specifically there are a lot of gotchas without full file access, like risk of location being stripped from all images synced trough the app (unless user gives media location permission) or similarly missing exif.. To upload on change it needs to be allowed to watch the filesystem
Meanwhile google drive gets to be installed as a system app
Meanwhile google drive gets to be installed as a system app
It's not just mirroring of your remote storage, you can also upload local files manually, turn on auto-upload for some directories (the main use case is uploading pictures) ant there was recently work being done to enable two-way-synchronization for directories that the user would like to sync. IMO it makes sense to let the users give it access to all the files on the phone, if they whish to do so.
For those scenarios, structured storage fits the bill. The app requests folder permission and the user, using system UIs, grants permissions on the folders they want to enable.
>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.
>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.
The problem lies that in newer Android versions (11 or higher) you cannot give permissions to arbitrary folders, it's only "shared folders" or "all the files" [0][1] (It's also explained in TFA)
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.
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/
KDE Connect allows me to browse the folder I picked and upload/download files just fine, using SAF. You point the app at a directory, click "grant access", and you have permanent access. The only problem I can think of is that some directories are restricted (https://developer.android.com/about/versions/11/privacy/stor...) because they're a dumping ground for files already.
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.
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.
This is all guessing by me, but I think that, traditionally, there's been a certain quantity of users that synced folders out of the /Android/data or similar locations and/or needed some extra flexibility. When Android 11 arrived, it was difficult to break that workflow for all those users (and I guess there was also some re-architecture needed for the app, but I don't know how much would it be).
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.
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.
It's worth noting that SAF does not work with native code.
I think TFA is wrong.
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...
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...
Well, it used to be possible before Android 11, that's the thing.
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]
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/2Hello, we and TFA are talking about the new API where the user picks what directory an app has access to vs. the old API where the app has access to almost everything as you pointed out.
The 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.
The 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.
Yeah, I'm not saying that you're in the wrong, I'm saying that they might want to access further than the new `ACTION_OPEN_DOCUMENT_TREE` API call allows. For example, the Downloads folder (you can only open individual files with ACTION_OPEN_DOCUMENT, not the whole folder). And that can be reached with the `MANAGE_EXTERNAL_STORAGE` (all files) API. Is that OK? Well, it's not intrinsically bad, but it clashes with Google's Android hardening directives.
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.
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.
It's doesn't work with native code.
Yes, you'll need a little bridge to get a ParcelFileDescriptor. Lots of stuff in Android does not work directly with native code (Permissions, Camera/Media recording, HttpURLConnection, sensors/location services, ...), and storage access is now sandboxed in a similar way and needs a few lines of Java/Kotlin. I fully see that this is annoying, and Android is tiring developers with constant changes like these, but on the other hand, I guess most people would agree that securing storage access is a good thing.
It would not be much effort at all for google to make native hooks into these APIs. Certainly less effort than dealing with constant complaints from developers. It feels like they're trying to force lock-in.
With file access, the sensible solution would have been of course to just overlay the permissions onto the regular files API (like I think every other sandboxing solution does), so everything that uses files could keep working as usual and you'd just have to add some limited code to request the appropriate permissions [1], but I guess that would have been too sensible, and when all you've got is a SAF, everything looks like a nail or something…
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.
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.
> 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
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.
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.
You're misrepresenting things I think.
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.
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.
From what I see (and what I've experienced on different sync apps when upgrading Android versions, although I'm not a developer, just a user), access to /Android/data and /Android/obb changed on Android 11:
---
edit: fixed readability and a link
---
[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
/Android is a private app storage and is documented as such.
Yeah, yeah, I know. I'm not saying that it's good or bad, I just say that some people like to sync/backup/copy their apps data (that sometimes it's located on private directories, or in the Downloads folder...), and they were able to do it before. And that the new API has less permissions than the one that Google wants them to use.
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.
---
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-permissionNote that `MANAGE_EXTERNAL_STORAGE` permission doesn't allow access to /Android anymore either (it's blocked by OS permisisons) so it won't help Nextcloud to retain it either.
Thing 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.
Thing 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.
> For those scenarios, structured storage fits the bill. The app requests folder permission and the user, using system UIs, grants permissions on the folders they want to enable.
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.
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.
It is what e.g. Simple Gallery does. It works well. Nice API.
https://play.google.com/store/apps/details?id=com.simplemobi... or on github.
https://play.google.com/store/apps/details?id=com.simplemobi... or on github.
FYI: The Simple Mobile Tools suite was acquired by an ad network and is pretty much discontinued, see
https://www.androidauthority.com/simple-mobile-tools-acquisi...
Use the Fossify fork instead:
https://play.google.com/store/apps/details?id=org.fossify.ga...
https://www.androidauthority.com/simple-mobile-tools-acquisi...
Use the Fossify fork instead:
https://play.google.com/store/apps/details?id=org.fossify.ga...
It seems I escaped, by paying the original developer €1 a long time ago. https://play.google.com/store/apps/details?id=com.simplemobi...
What are you referring to? Looking at that link, I see little overlap with what Nextcloud offers. There's a lot more in it than just a pretty gallery.
The overlap is precisely that part which matters: The directory access portions. Both need to ask the user to choose which directories to access, and access all the files in those directories.
What they do after opening the files is very different, and irrelevant. FWIW I use both Nextcloud and that gallery app.
What they do after opening the files is very different, and irrelevant. FWIW I use both Nextcloud and that gallery app.
Hello there, it seems I was indirectly mentioned..
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?
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?
> This Nextcloud app seems to be
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.
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.
And you can let it if they use Storage Access Framework to ask for that permission without them requiring blanket access to all your private data.
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.
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.
> Perhaps you should get informed as well.
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?
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?
The person you are replying to has not denied anything you said, nor have they given any indication that they need to get informed. Your comment is wildly misplaced.
File managers are explicitly allowed to have this permission.
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.
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.
As I recall from a similar issue with Syncthing, using scoped storage for this has significant performance limitations.
The issue with Syncthing was that the author didn't want to call out to scoped storage APIs in Java and wanted to use only Go at any cost.
The performance is a bit worse but for background syncing it's not material.
The performance is a bit worse but for background syncing it's not material.
> wanted to use only Go at any cost
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.
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.
Not a Java dev...
How would one use the Java APIs from a Go application?
I'm used to the reverse, Java calling external library.
How would one use the Java APIs from a Go application?
I'm used to the reverse, Java calling external library.
The same way, just with the native side of JNI API.
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.)
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.)
Ah ok.
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.
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.
Yes and it doesn't work with native code, so you have to implement an entire filesystem abstraction using Kotlin or Java.
> The escape hatch is to use the FDroid version rather than the Play Store version.
And perhaps using GrapheneOS while at it.
And perhaps using GrapheneOS while at it.
Which unfortunately requires... a Google phone
Unlike Apple, Google's main business isn't selling hardware, nor do they use hardware as the chokepoint for controlling their ecosystem.
It could change in future devices, but currently there's not much stopping you from doing whatever you want with your Pixel's software.
It could change in future devices, but currently there's not much stopping you from doing whatever you want with your Pixel's software.
Sure, I think Pixels are great devices! The two brands I would consider are FairPhone and Pixel, to be honest.
I just find it ironic that I mostly deGoogled my tools, but still I would consider a Pixel with GrapheneOS :-).
I just find it ironic that I mostly deGoogled my tools, but still I would consider a Pixel with GrapheneOS :-).
Ah yeah but my sony xperia isn't supported!
> The escape hatch is to use the FDroid version rather than the Play Store version.
As long as Google doesn't remove the ability to sideload apps, Android users are fine.
As long as Google doesn't remove the ability to sideload apps, Android users are fine.
Android users are most certainly not fine. Hardware remote attestation enables apps to determine whether you "tampered" with "your" device by doing things like installing apps from "untrustworthy" sources. They want to do this so they can discriminate against you for it. You do things like this and suddenly your bank stops letting you log into your account.
Android is just a shitty version of iOS now.
Android is just a shitty version of iOS now.
Do you have a example/source where side loading an app gets detected by remote attestation?
My bank's apps detect everything from developer mode to debug access to untrusted sources. "Fraud prevention" or some nonsense.
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.
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.
Hmm, I just checked: I have developer options enabled and untrusted sources (F-Droid). I checked my play integrity status[0] and it reports:
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...
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...
Remote hardware attestation is the problem. It's the only thing that prevents me from simply circumventing the bank app's silly checks.
Cryptography is great when it empowers us. It sucks when it's used against us.
Cryptography is great when it empowers us. It sucks when it's used against us.
It's great that your integrity status reports that today, what's the guarantee that it will stay like that in a year?
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.
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.
It's probably Play Integrity, indeed, which most of all checks if the user downloaded the app from the Play Store (and so requires a Google account, and being logged in to it on the phone).
If they ever do that they'll get a hefty fine from the EU and the order to restore such functionality or be banned from the market.
Why? Apple does that. You cannot install an app to IOS without both apple review and paying apple money per install. That review still enforces apple policies (famously the "no non-apple-gets-30%-payments" policy which is now ironically suspended on the US side. Ironically and temporarily)
Isn’t that only for App Store apps?
> Apple does that. You cannot install an app to IOS without both apple review and paying apple money per install
Not really in the EU? https://support.apple.com/en-us/118110
Not really in the EU? https://support.apple.com/en-us/118110
App "notarization" requires apple review, as can be read on the link you pasted.
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.
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.
And, Apple was recently fined €500 million and ordered to comply with the DMA law.
> 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...
> 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...
€500 million eh? Let's see what percentage of that they end up actually paying.
According to Proton's tracker, the fines are paid in full and in a few days [0].
[0] https://proton.me/tech-fines-tracker
[0] https://proton.me/tech-fines-tracker
a) Notarization is an automated process to check for apps that would compromise the integrity of their platform. It doesn't care about the content or type of app you're building.
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.
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.
Quite naive take, you don't have to use any of your examples to deploy to Android, Windows, Linux or MacOS. It would be more like Microsoft charging a per-install fee on using the Win32 APIs which sounds outrageous.
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.
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.
I like the walled garden but its a bit of an exaggeration to say they are doing a good job.
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.
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.
Sorry, Apple iOS is not a Wall Garden, it is a Prison Cell. A Wall Garden / Gated Community allows for the deployment of personal security such as a home security system with monitoring company, video surveillance, and personal security guards. Apple does not allow any if that. You cannot even preemptively block known Command and Control services, best C&C servers operate in plain sight, such as X-Twitter and Facebook on iOS.a
Seems a bad analogy. In a prison cell, it's deliberately made hard for criminals to damage each other, isn't it?
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!
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!
>Quite naive take, you don't have to use any of your examples to deploy to Android, Windows, Linux or MacOS. It would be more like Microsoft charging a per-install fee on using the Win32 APIs which sounds outrageous.
"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.
"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.
Yeah sorry IANAL, the fact stands: EU thinks Apple is exploiting their market position to lock users down, EU doesn't like it and will make Apple comply.
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).
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).
The most egregious behaviour is simply denying consumers the information they need to not pay ridiculous, even recurring, fees to Apple to use someone else's service. Fees they may have coerced the app developer into implementing, like Patreon, whilst simultaneously illegally depriving them of any alternative billing methods. Fees they testified are for doing nothing. Fees they testified carry 75% profit margin.
Yeah it completely slipped my mind, it's brutal and entirely inappropriate that they can force their recurring fees like that.
I don't know if developers are still not allowed to advertise alternative payment methods, but it's just one step too far.
I don't know if developers are still not allowed to advertise alternative payment methods, but it's just one step too far.
>Yeah sorry IANAL, the fact stands: EU thinks Apple is exploiting their market position to lock users down, EU doesn't like it and will make Apple comply.
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.
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.
You jumped in into a question asked to someone else, I won't go into a pie throwing contest over an insignificant detail you care to win about, I don't have the grey text.
"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
"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
> Notarization is an automated process
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/
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/
No, they just use the "security" argument in bad faith, so third party apps can't compete with builtin ones made by Google.
The builtin app is using the more privacy-friendly framework that Nextcloud claims they cannot use.
Right, because y'all didn't scream when Android games could upload all private photos to their servers because they got this blanket permission to download their game files.
Get outta here.
Get outta here.
I don't care about games I don't download. I don't see a problem with the fact that if I download and execute a binary file on linux without explicit sandbox, it can mess up my system, that's my responsibility.
Google pretends to care about my security, but they actually care about cementing their monopoly.
That's my take. And even if they aren't using the security argument in bad faith this time, they have so often in the past that now they can reap the rewards of using that argument in bad faith.
Background:
> Other apps were not allowed to use this permission at all, once it was introduced in 2022. I could convince them back then, that we need this. But nowadays they are more strict on it and thus we needed to remove this permission. Thus is, why it feels now like a regression / problem in UX, while it was only an exception that they allowed it for ~2 years.
https://github.com/nextcloud/android/issues/14135#issuecomme...
> Other apps were not allowed to use this permission at all, once it was introduced in 2022. I could convince them back then, that we need this. But nowadays they are more strict on it and thus we needed to remove this permission. Thus is, why it feels now like a regression / problem in UX, while it was only an exception that they allowed it for ~2 years.
https://github.com/nextcloud/android/issues/14135#issuecomme...
>Attempts to raise the issue with Google resulted in little more than copy-and-pasted sections of the developer guide
My exact same experience. We had two very simillar apps for a brief time, the old version that interfaces to the old hardware, for old phones, and the new version which was basically redesigned from scratch but kept the same UI. We wanted at least to have a fallback version in case users had any issue, for whatever reason.
From the top of my head, i can name at least a dozen apps that i use daily that have multiple versions of them on the store, for the same reason we did.
However, we received a complaint from google, which froze both our apps, because apparently you can't make one app that looks too simillar to another one.
First, it's our APP. We are not trying to copy anyone (the chief reason for this rule, you don't want fake malicious clones of apps) Second, it's only the first page that looks the same (a video was provided showing the differences once you connected to a companion device. Also ALL our apps have the same first page) Third, what about all the free/pro app pairs you can find? Not every developer chose to follow the in-app-purchase route for unlocking features.
For at least two weeks i kept receiving copypasted responses. All the same wording, all copypasting pieces of the guidelines which can be interpreted in many different ways. After two weeks, they either escalated to a human being, or to a less useless one and we started chatting. We could convince them to at least unlock one of the Apps while deciding what to do with the other one.
Re: second point, they were immovable. Re: third point, when i was asking why the other developer's apps are still there, and what could i do to make the same, the answer was invariably the same: "I can't comment for the other apps, but if you think they violate the guidelines you can report them", so the exact opposite of what i was asking. Which is proof enough to me: they don't stop anything unless reported, and we had a third party attack us with a swarm of fake reports on behalf of a competitor, which already happened in the past. Human beings - or at least with a functioning brain - are not working at google's developer support.
In the meantime we had to distribute the APK, which is not great the moment you need to update.
Apple gave zero fuss, we have had both versions on the store since day one.
My exact same experience. We had two very simillar apps for a brief time, the old version that interfaces to the old hardware, for old phones, and the new version which was basically redesigned from scratch but kept the same UI. We wanted at least to have a fallback version in case users had any issue, for whatever reason.
From the top of my head, i can name at least a dozen apps that i use daily that have multiple versions of them on the store, for the same reason we did.
However, we received a complaint from google, which froze both our apps, because apparently you can't make one app that looks too simillar to another one.
First, it's our APP. We are not trying to copy anyone (the chief reason for this rule, you don't want fake malicious clones of apps) Second, it's only the first page that looks the same (a video was provided showing the differences once you connected to a companion device. Also ALL our apps have the same first page) Third, what about all the free/pro app pairs you can find? Not every developer chose to follow the in-app-purchase route for unlocking features.
For at least two weeks i kept receiving copypasted responses. All the same wording, all copypasting pieces of the guidelines which can be interpreted in many different ways. After two weeks, they either escalated to a human being, or to a less useless one and we started chatting. We could convince them to at least unlock one of the Apps while deciding what to do with the other one.
Re: second point, they were immovable. Re: third point, when i was asking why the other developer's apps are still there, and what could i do to make the same, the answer was invariably the same: "I can't comment for the other apps, but if you think they violate the guidelines you can report them", so the exact opposite of what i was asking. Which is proof enough to me: they don't stop anything unless reported, and we had a third party attack us with a swarm of fake reports on behalf of a competitor, which already happened in the past. Human beings - or at least with a functioning brain - are not working at google's developer support.
In the meantime we had to distribute the APK, which is not great the moment you need to update.
Apple gave zero fuss, we have had both versions on the store since day one.
Were these shipped by different developer accounts? Or at least signed with different keys?
Why would they have to be shipped by different accounts?
Again: see the loads of very popular free/pro apps that look exactly the same on the surface, but with different icon/name/screenshots/text on the store page (all things we did) and given the wording that the bots kept writing us back, they are all breaking the rules. And when i made that point the answer was that if i wanted i could report them for a takedown, instead of having an explanation why they are allowed so we can do what they did.
They just don't care, if you receive enough reports you get taken down with virtually no appeal. Have you ever been flagged for using your own logos and copyrights without permissions? because we have, on our company store, verified by legal mail, dusn number, bank account and whatever other bullshittery they require next. Yet from time to time we get flagged
They just don't care, if you receive enough reports you get taken down with virtually no appeal. Have you ever been flagged for using your own logos and copyrights without permissions? because we have, on our company store, verified by legal mail, dusn number, bank account and whatever other bullshittery they require next. Yet from time to time we get flagged
Because the ordinary impersonation detection is looking for apps that are impersonating apps by other developers. I was curious if there was some reason why automation might think that your two apps belonged to different people.
Why doesn't Nextcloud use the scoped storage access introduced in recent years? Users could give Nextcloud access to the particular folders they want synced. Is there some kind of access they need that those APIs don't support?
Google will not let you pick the root folder, making it impossible to sync everything.
Note that Google's and other American Big Tech apps do not have this issue, because Google only cares about taking permissions away from "small" players.
Note that Google's and other American Big Tech apps do not have this issue, because Google only cares about taking permissions away from "small" players.
Google's comparable app (Drive) also cannot pick the root folder. As of Android 11, even apps with MANAGE_EXTERNAL_STORAGE cannot access the root folder.
Nextcloud isn't really designed to sync the entire device, it's meant to sync your Nextcloud folder to a subfolder somewhere which works fine with the new storage access permissions.
It's designed to sync the files the user wants synced, be it files produced by the camera app or some other app that operates on a directory on your device, such as your Downloads folder, audiobook folder used by your audiobook app, or the notes folder where your notes app writes the notes.txt, or just straight up everything.
It can do that just fine with the new permissions, you just can't sync the root folder or Downloads folder which is OK as documents, audiobooks, etc would be stored in their respective folders and not Downloads.
You mean that that's ok for you. Which is fine. It isn't ok for other people, which is also fine.
Some people may not want to have to reopen Nextcloud any time a new directory appears on their device so they can add it to Nextcloud, while the other American bigtech backup apps can just pick it up automatically no problem.
Some people may not want to have to reopen Nextcloud any time a new directory appears on their device so they can add it to Nextcloud, while the other American bigtech backup apps can just pick it up automatically no problem.
Often it's because setting up a David versus Goliath story is good for business.
Spotify did this all the time where they would complain about Apple not allowing them access to some private API and then when they did didn't even bother to use it.
Spotify did this all the time where they would complain about Apple not allowing them access to some private API and then when they did didn't even bother to use it.
Nextcloud is about synchronising files. Some people may only sync media files, but surely you can imagine that others want to sync other files, right? It's not that crazy, Dropbox, GDrive, iCloud, etc. all do that.
Do you really think it seems unfair that a file sync app would want to access files?
Do you really think it seems unfair that a file sync app would want to access files?
These APIs don't work with native code.
Nextcloud's app does not use native code.
[deleted]
My point is more that the API isn't a solution for everyone, even if it would work in this case. Even if it would, the API is terrible.
This is the one that only allows access to media files, yes? This is fact the API they are using. They expound in the article that it is insufficient for their use case.
No, this is the one that allows access to any files on shared storage if the user selects them in the dialog.
This is not what the docs claim, but I could be misreading them.
If you're thinking of another API, they support an additional file access api that allows selecting individual files, not entire folders. This is also not what users expect.
If you're thinking of another API, they support an additional file access api that allows selecting individual files, not entire folders. This is also not what users expect.
You're vague, which docs and which API?
Scoped storage via SAF allows directory tree selection.
Scoped storage via SAF allows directory tree selection.
The war on general purpose computing goes on. It will only end when every piece of software could be a web app.
threeseed(2)
I find it deeply ironic that HN users DEMAND that Linux/macOS/Windows all implement this exact sandboxing (where user controls which files apps can access) and then threads like these are full of angry people demanding that Google allows Android apps to just demand access to all private photos, documents and app data with one blanket permission (which was abused by every malware ridden game out there).
Android supports scoped storage which is fine for Nextcloud and requires NO extra permissions. It gives control to user because user then selects which directories they want to give Nextcloud to.
Nextcloud just needs to put in the work to support it properly instead of just demanding full unfettered disk access to all photos and app data with no user control over it.
Android supports scoped storage which is fine for Nextcloud and requires NO extra permissions. It gives control to user because user then selects which directories they want to give Nextcloud to.
Nextcloud just needs to put in the work to support it properly instead of just demanding full unfettered disk access to all photos and app data with no user control over it.
> users controls which files apps can access
> Google allows Android apps to just demand access to all private photos
Your own words betray that you are probably confused about what the problem actually is. From my perspective, I think people generally want the same thing on both platforms: the user be in charge of which files the OS gives access to applications.
> Google allows Android apps to just demand access to all private photos
Your own words betray that you are probably confused about what the problem actually is. From my perspective, I think people generally want the same thing on both platforms: the user be in charge of which files the OS gives access to applications.
As a developer that did many of those migrations, I can claim that it's crystally clear what the problem is.
Storage Access Framework is a framework where user decides which files an app can access and see. That's the API Nextcloud refuses to use.
Old READ_EXTERNAL_STORAGE (replaced with MANAGE_EXTERNAL_STORAGE now) permission gives full access to all shared storage data (where for example DCIM directory with all private photos and their locations lives) without exception or privacy filters like EXIF stripping. This permission was required by many games, malware apps and everyone with 5 minutes of time that could paste that string into the app and refused to allow users to run the app without granting it. It was VERY common to demand access to all storage at startup just to do simple things like download a potential file.
That's the API Nextcloud demands to use and Google is telling them that they can't because they should be using SAF.
Storage Access Framework is a framework where user decides which files an app can access and see. That's the API Nextcloud refuses to use.
Old READ_EXTERNAL_STORAGE (replaced with MANAGE_EXTERNAL_STORAGE now) permission gives full access to all shared storage data (where for example DCIM directory with all private photos and their locations lives) without exception or privacy filters like EXIF stripping. This permission was required by many games, malware apps and everyone with 5 minutes of time that could paste that string into the app and refused to allow users to run the app without granting it. It was VERY common to demand access to all storage at startup just to do simple things like download a potential file.
That's the API Nextcloud demands to use and Google is telling them that they can't because they should be using SAF.
So google did nothing with those malware apps and now is doing something with a legitimate, very popular app? It does not compile.
Is nextcloud malware? Yes or no. Why do they treat it as if it is?
Is nextcloud malware? Yes or no. Why do they treat it as if it is?
They did do something; they introduced a privacy-preserving API to allow users to pick which files the app can access, and only certain apps (file managers, etc) can request the old storage permission and be published on the Play Store.
A cloud sync tool is also a file manager. I don;t know why people act like it isn't.
So you say the user is in control on Android? Like, I can overrule Google when it comes to Google Play Services permissions? I can now deny apps internet access?
If Nextcloud migrates to the API which allows that control, yes.
You can absolutely deny apps internet access. I do it for the Google Keyboard app.
On stock Android? How? I know how to do this on LineageOS.
NetGuard can do it: https://play.google.com/store/apps/details?id=eu.faircode.ne...
Oh I'm not on stock Android. I'm on lineage
> HN users DEMAND that Linux... implement this exact sandboxing (where user controls which files apps can access)
chroot was added to Unix in 1979.
chroot was added to Unix in 1979.
What we want is for the user to be able to choose for themselves.
In reality what happened was that apps and games demanded full access for frivolous reasons. Like Syncthing author which wanted access to all data because they didn't want to call Android APIs and wanted to only use Go.
Then warn the user and let them choose.
Syncthing is written in Golang; the SAF APIs don't work with native code
Syncthing is written in Golang; the SAF APIs don't work with native code
They do if you bother to write bindings.
ie go through a process that's about as painful as re-writing your application from scratch.
Ah so that's probably yhe reason why the Dropbox app has these weird abstraction layers. If it weren't for integration with other apps, I would much prefer Nextcloud. But some apps simply don't offer anything else than "cloud sync"
Probably irrelevant but I gave up on next cloud because I found the syncing apps to be unusable on Mac, windows and Linux. Nothing ever worked the way it was meant to. They crashed all the time, were unresponsive, and the UX was terrible
This article is thick with tribalism, but I personally found it to be a mixed bag. For open source software and self-hosting enthusiasts, NextCloud (OwnCloud, et al) makes you feel really empowered to sort of build out your own personal cloud and/or groupware, and in many of the most salient aspects it delivers.
But like anything so ambitious in scope, it doesn’t take much before you begin to push up against its boundaries (even as generous as they are). This is the kind of software that the biggest players in the industry devote armies of highly paid developers and billions of capital to. The accomplishments of the OSS community should not be diminished. I personally will continue to use and support these tools in my own capacity. But it’s kind of inevitable that, while they offer lots of cool major features, they won’t ever be quite as polished or refined as competing solutions from industry giants, or even other OSS apps that take a narrower, more uni-tasked approach.
Having read through most of these comments, I think the truth is probably somewhere between competing ideas, and everything else is subjective and context-dependent.
But like anything so ambitious in scope, it doesn’t take much before you begin to push up against its boundaries (even as generous as they are). This is the kind of software that the biggest players in the industry devote armies of highly paid developers and billions of capital to. The accomplishments of the OSS community should not be diminished. I personally will continue to use and support these tools in my own capacity. But it’s kind of inevitable that, while they offer lots of cool major features, they won’t ever be quite as polished or refined as competing solutions from industry giants, or even other OSS apps that take a narrower, more uni-tasked approach.
Having read through most of these comments, I think the truth is probably somewhere between competing ideas, and everything else is subjective and context-dependent.
Coming from Dropbox, OneDrive etc I guess I assumed it would "just work". And if I'm honest my experience was compounded by other issues. I was running my server on a pi4 and didn't initially give it a fixed IP so the clients lost it, but even after I sorted those issues and had a solid server, the tray apps just would not sync. Sometimes even stopping and restarting the app wouldn't help. All I really wanted was to have a shared sync folder like Dropbox, across OS with storage size only limited by what I could configure in my attic, but I gave up after a week of trying to fix it night after night.
Since we're sharing anecdotes: Nextcloud works really well for me.
I'm glad, I wish I knew your secret
I hate the nextcloud ux with a passion and I'm running multiple instances for company and non-profits. Especially their calendar app makes we want to delete that thing every time I have to use it.
If you leave the beaten path it tends to break.
It's free and it feels wrong to complain but it's not good software IMHO.
If you leave the beaten path it tends to break.
It's free and it feels wrong to complain but it's not good software IMHO.
Both major app stores have of late gone further and further down the rabbit hole of enforcing platform entitlements, and it feels like Google is catching up to the point where the Play Store is nearly as hostile to advanced functionality as Apple.
Most people don’t even know F-Droid exists, so the only real way is to fix this at the platform level—-maybe with an additional app review tier for specialized apps, or just a better process that doesn’t feel as if you’re talking to a generalist call center or untrained staff…
Most people don’t even know F-Droid exists, so the only real way is to fix this at the platform level—-maybe with an additional app review tier for specialized apps, or just a better process that doesn’t feel as if you’re talking to a generalist call center or untrained staff…
Just want to say that both things can be true. Google can be acting in the interests of security and doing the right things for the majority of their users, yet still be running the anti-competition playbook by cutting people off with no warning explanation or recourse.
The API that Nextcloud can use it readily available since Android 4.4 (2013).
They just didn't put in the work in 10 years despite repeated deprecation warnings.
This seems modus operandi from many OSS developers (syncthing is the other one that had the exact same issue) - ignore warnings, ignore migration guides, ignore API changes and then scream their heads off 6 YEARS later about how evil people are that they don't get unfettered access to users data anymore. And conveniently ignore that the migration path was available for longer than their product exists.
They just didn't put in the work in 10 years despite repeated deprecation warnings.
This seems modus operandi from many OSS developers (syncthing is the other one that had the exact same issue) - ignore warnings, ignore migration guides, ignore API changes and then scream their heads off 6 YEARS later about how evil people are that they don't get unfettered access to users data anymore. And conveniently ignore that the migration path was available for longer than their product exists.
I'm guessing it was back ported to Android 4.4, so it probably hasn't been available quite that long. (Update: Nevermind, looks like it was in the initial 4.4 release: https://www.youtube.com/watch?v=zxHVeXbK1P4) But they've definitely been warning about the pending API change since at least 2019: https://www.youtube.com/watch?v=UnJ3amzJM94
The devs in the comments of that video do have some valid complaints about the added complexity of not being able to use the standard Java filesystem APIs anymore with the new permissions model, but still, it has been 6 years.
The devs in the comments of that video do have some valid complaints about the added complexity of not being able to use the standard Java filesystem APIs anymore with the new permissions model, but still, it has been 6 years.
There was no backport, it was introduced in API level 19 as the doc itself mentions: https://developer.android.com/guide/topics/providers/documen...
I interpreted that statement as "this is available in API level 19 and up", not "this was introduced on the same date that we originally released API level 19", but it looks like you're correct: https://www.youtube.com/watch?v=zxHVeXbK1P4 That's way older than I was expecting.
Admittedly, there were bugs on the initial versions and wasn't really widely useable until about API 23 or so. But that's still years back.
I think certain performance issues have persisted until today, though?
If you need to do stuff like recursively enumerate files in a shared directory, it's slow without workarounds to avoid the extra IPC calls. For stuff like syncing the shared directory in the background, the performance impact is not material (20-30ms per file).
[deleted]
Does Google Drive have this elevated privilege? If so, seems blatant abuse of app store control. If not, it would seem to indicate there is a workaround somehow the Nextcloud could also leverage.
Drive doesn't sync arbitrary files on Android though. A closer analogue to what nextcloud is trying to do would be syncthing, who also discontinued its Android app due to issues with getting the proper permissions with the play store (see https://github.com/syncthing/syncthing-android/issues/2064).
> syncthing, who also discontinued its Android app
https://f-droid.org/en/packages/com.github.catfriend1.syncth...
https://github.com/Catfriend1/syncthing-android-fdroid
https://f-droid.org/en/packages/com.github.catfriend1.syncth...
https://github.com/Catfriend1/syncthing-android-fdroid
Google Drive, Google Photos do not have this permission but Android Auto and Files by Google have.
[deleted]
Google'a app store policies are very anti-competitive. This kind of behaviour hurts all users.
Google - if you're out there - stop being such absolute effing jerks to your users.
A lot of us actually want to run apps with full access to our system. The kind of access your own backend has with features like cloud backup.
Syncthing already abandoned their Android app because of this nonsense (as jfim pointed out: https://github.com/syncthing/syncthing-android/issues/2064)
A lot of us actually want to run apps with full access to our system. The kind of access your own backend has with features like cloud backup.
Syncthing already abandoned their Android app because of this nonsense (as jfim pointed out: https://github.com/syncthing/syncthing-android/issues/2064)
Another app that abandoned Android for the same reason is iA Writer. It's a plain text editor and Markdown writing app designed around working with, and linking among, tons of text files, so it needs to see all text files (and images etc. for linking) in a hierarchy of folders, and be able to edit any of them.
Google made it so painful and unreasonably expensive to get that access, they gave up. Now it's a Windows, Mac and iOS exclusive, no Android app anymore, despite it existing and having for over a decade been fully functional.
Google made it so painful and unreasonably expensive to get that access, they gave up. Now it's a Windows, Mac and iOS exclusive, no Android app anymore, despite it existing and having for over a decade been fully functional.
Wrong, the iA Writer thing was about Google Drive access, not local file access: https://ia.net/topics/our-android-app-is-frozen-in-carbonite
Working with Google Drive permissions is also horrific sadly.
You must realise there are lots of different user types, and far far more people just want a phone that can't have stuff installed on it that can't do naughty things.
Apple, in macOS, has something called "Full Disk Access". You can grant it if you want, deny if you don't.
If you allow that, the app works like the way the person you're replying to wants. If you deny that, the application works the way you want.
If one company have it, the other can implement it, too. There's no shame in copying a good feature, is it?
If you allow that, the app works like the way the person you're replying to wants. If you deny that, the application works the way you want.
If one company have it, the other can implement it, too. There's no shame in copying a good feature, is it?
I imagine the reason is probably why Apple doesn't copy that feature in iOS: MacOS is much less of a walled garden than a phone ecosystem.
In iOS the same feature appears as "Files integration", which allows you to see an app's files from the "Files" application, and some applications can see all "Files Enabled/Allowed" applications in their file selection window.
Just checked with Dropbox, and yep, that's how it works. Files can access Dropbox transparently, and Dropbox can access any files which can be seen by the Files app.
So an equivalent is present in iOS.
Just checked with Dropbox, and yep, that's how it works. Files can access Dropbox transparently, and Dropbox can access any files which can be seen by the Files app.
So an equivalent is present in iOS.
Oh, that's changed since I last checked. Fair enough.
If google controlled the trade codes, your house would have electrical panels that could only be opened with a tool that was only available to google certified tradies, you know, for safety.
If Google's reputation were on the line if anyone's electrical panel broke, or if someone stole all your personal data from your life that they run through that panel then, yeah. I imagine so.
And that electrical panel would still break and now it would have people like me shitting on their reputation at every chance given whether it breaks for me or not.
Because philosophically its a stain, now I likely pay more and i can't have my knowledgeable family in the trade deal with the issue and me with some of the others.
I suppose, but that's pretty nothingy in the grand scheme of things.
And you can do some things with a phone, e.g. hard reset it if it's really broken. What do you want to be able to do with a phone to fix it that you can't do today?
And you can do some things with a phone, e.g. hard reset it if it's really broken. What do you want to be able to do with a phone to fix it that you can't do today?
Replace misdesigned components. It shouldn't matter than “most people” don't need or want to use a thing in a particular way, but yet I'm constantly prevented from doing things that are trivial on other platforms and used to be trivial on this one.
> Replace misdesigned components
As in software or hardware?
> It shouldn't matter than “most people” don't need or want to use a thing in a particular way
Well, it does a bit. If I buy a Fiat Uno I shouldn't be expecting to be towing a 2-tonne caravan with it.
As in software or hardware?
> It shouldn't matter than “most people” don't need or want to use a thing in a particular way
Well, it does a bit. If I buy a Fiat Uno I shouldn't be expecting to be towing a 2-tonne caravan with it.
>As in software or hardware?
I'd presume he means software
> If I buy a Fiat Uno I shouldn't be expecting to be towing a 2-tonne caravan with it.
Sure but you're basically suggesting people shouldn't be able to tow caravans. That since most people won't do it and some who do will overload or take stupid turns and damage their vehicle so it shouldn't be possible for nearly any road vehicles.
>I suppose, but that's pretty nothingy in the grand scheme of things.
Not for me. For me it's another general computing device that can't do general computing. Some random person installing dodgy apk's and giving em stupid permissions on the other hand doesn't bother me in the grand scheme of things.
I'd presume he means software
> If I buy a Fiat Uno I shouldn't be expecting to be towing a 2-tonne caravan with it.
Sure but you're basically suggesting people shouldn't be able to tow caravans. That since most people won't do it and some who do will overload or take stupid turns and damage their vehicle so it shouldn't be possible for nearly any road vehicles.
>I suppose, but that's pretty nothingy in the grand scheme of things.
Not for me. For me it's another general computing device that can't do general computing. Some random person installing dodgy apk's and giving em stupid permissions on the other hand doesn't bother me in the grand scheme of things.
The problem is the naughty/nice dichotomy in terms of software that needs effectively global permissions to accomplish it's task, like apps like this arguably would. I have also compromised the ever loving hell out of my household ubuntu box to make it do various things, but I'm also doing that on purpose, knowing full well that it's kept safe by other means.
The problem is casual users aren't interested in learning about this shit so they can make informed choices. They just click through and give apps access to the entire device without thinking or reading, and then bitch at Google when their data is breached. Google doesn't want to deal with that so they lock everything down.
I dunno isn't this why Android users root their phones?
The problem is casual users aren't interested in learning about this shit so they can make informed choices. They just click through and give apps access to the entire device without thinking or reading, and then bitch at Google when their data is breached. Google doesn't want to deal with that so they lock everything down.
I dunno isn't this why Android users root their phones?
> I dunno isn't this why Android users root their phones?
No, because it would be like using dynamite to drill a small hole in the wall - effectively destroying the platform's entire security model as well as locking yourself out of vital apps (finance/banking), and many non-vital apps that pretend they need the same level of security and refuse to work on rooted devices.
No, because it would be like using dynamite to drill a small hole in the wall - effectively destroying the platform's entire security model as well as locking yourself out of vital apps (finance/banking), and many non-vital apps that pretend they need the same level of security and refuse to work on rooted devices.
> locking yourself out of vital apps (finance/banking)
My controversial take here is that Google's creation of a remote attestation scheme is also anticompetitive, intended to reduce the commercial viability of any non-blessed Android distributions.
Everyone could see the bad intent when Microsoft proposed the same thing about a decade earlier under the name Palladium, but Google's Safetynet didn't prompt much outcry from the tech community. I'm disappointed by that.
My controversial take here is that Google's creation of a remote attestation scheme is also anticompetitive, intended to reduce the commercial viability of any non-blessed Android distributions.
Everyone could see the bad intent when Microsoft proposed the same thing about a decade earlier under the name Palladium, but Google's Safetynet didn't prompt much outcry from the tech community. I'm disappointed by that.
Well sure I don't disagree with you at all, but the way I always hear it from Android fans, that's why they want it. I don't get it personally, I'm quite happy with a "locked down" iPhone.
I don't know how it is on iPhones, but many Android phones come with a crap-ton of unwanted software that is uninstallable unless you have root. I'm exaggerating but it feels like buying a car with all the stations pre-programmed in the radio.
edit: s/it/the radio
edit: s/it/the radio
Depends on the phone. This is the un-walled garden.
I use OnePlus, which has very little/no bloat.
I use OnePlus, which has very little/no bloat.
Huh. I have a OnePlus 8T and it has some stupid stuff on it that I can't remove.
> The problem is casual users aren't interested in learning about this shit so they can make informed choices.
That's a good point. And for non-casual users there is F-droid. It sucks for app developers who lose a giant audience for sure. But maybe in the long run it's good that power users have a place to go?
That's a good point. And for non-casual users there is F-droid. It sucks for app developers who lose a giant audience for sure. But maybe in the long run it's good that power users have a place to go?
At least the permission exists and users can sideload.
As opposed to on the Apple side...
As opposed to on the Apple side...
Ohhh, what a insightful comment! Thank you!
edit: next cloud is available from the app store, soooo, have fun on the otherside. And from the author:
> Apple gave zero fuss, we have had both versions on the store since day one.
edit: next cloud is available from the app store, soooo, have fun on the otherside. And from the author:
> Apple gave zero fuss, we have had both versions on the store since day one.
Interesting. As an Apple user on both mobile and desktop, I fully expected a solution like NextCloud to be unusable on their platform.
Especially since i was a pCloud user but Apple in their infinite wisdom deprecated the extension they were using to offer a 'virtual drive' for syncing. On desktop.
Especially since i was a pCloud user but Apple in their infinite wisdom deprecated the extension they were using to offer a 'virtual drive' for syncing. On desktop.
interesting.
The escape hatch is to use the FDroid version rather than the Play Store version.