WAI
Status Update
No update yet.
Comments
ad...@google.com
ke...@gmail.com
This makes Scoped storage useless, a /sdcard/Documents simply equals to /sdcard.
ad...@google.com
We have passed this to the development team and will update this issue with more information as it becomes available.
sb...@gmail.com
Well, people who use their Android devices as PC alternatives would probably call scoped storage useless in the first place - along with harmful, and even endgame. These users are perfectly fine with the current state of storage permissions, and don't need a "fix" that breaks functionality they rely on.
This proposal is a constructive attempt at a compromise between two different audiences. Reducing clutter and enhancing security may be valid rationales for those who use Android as just an app launcher, but it comes at expense of those who see Android as more. An isolated folder for people who want to do more with their devices would not interfere with others' experience; that folder would be used only by people who really need the freer content access, and its files would not clutter devices globally the way that current practice allows. Isolated access is not global access, and "/sdcard/Documents" is not "/sdcard".
In the end, reducing platform scope at a time when devices with large internal storage and foldable displays promise expanded roles would be a downright tragedy. It's also completely unnecessary when there are alternative ways forward. Whether it's this idea or not, a lot of people are hoping that one of those alternatives makes the cut.
This proposal is a constructive attempt at a compromise between two different audiences. Reducing clutter and enhancing security may be valid rationales for those who use Android as just an app launcher, but it comes at expense of those who see Android as more. An isolated folder for people who want to do more with their devices would not interfere with others' experience; that folder would be used only by people who really need the freer content access, and its files would not clutter devices globally the way that current practice allows. Isolated access is not global access, and "/sdcard/Documents" is not "/sdcard".
In the end, reducing platform scope at a time when devices with large internal storage and foldable displays promise expanded roles would be a downright tragedy. It's also completely unnecessary when there are alternative ways forward. Whether it's this idea or not, a lot of people are hoping that one of those alternatives makes the cut.
ke...@gmail.com
#4
A public storage path is a public path, a modified path of "/sdcard/Documents" does not change this.
"This proposal is a constructive attempt at a compromise between two different audiences"
"Reducing clutter and enhancing security may be valid rationales for those who use Android as just an app launcher, but it comes at expense of those who see Android as more."
A refined scoped storage mechanism should suits this.
"that folder would be used only by people who really need the freer content access"
No, it will be abused definitely, we have seen this for years since the introducing of runtime permissions in Android 6.0:
Most requests to the phone permission are simply abusing persistent IDs, so google makes none can access them anymore in Android Q, and the similar things will be applied to public storage.
That is why a /sdcard/Documents simply equals to /sdcard, and current fallback(delay forced scope storage to the next major release) is better.
A public storage path is a public path, a modified path of "/sdcard/Documents" does not change this.
"This proposal is a constructive attempt at a compromise between two different audiences"
"Reducing clutter and enhancing security may be valid rationales for those who use Android as just an app launcher, but it comes at expense of those who see Android as more."
A refined scoped storage mechanism should suits this.
"that folder would be used only by people who really need the freer content access"
No, it will be abused definitely, we have seen this for years since the introducing of runtime permissions in Android 6.0:
Most requests to the phone permission are simply abusing persistent IDs, so google makes none can access them anymore in Android Q, and the similar things will be applied to public storage.
That is why a /sdcard/Documents simply equals to /sdcard, and current fallback(delay forced scope storage to the next major release) is better.
sb...@gmail.com
So, in the name of preventing "abuse" you'd deny people the right to store their content on their devices the way they wish? That seems more prison than platform. The argument is especially shaky given that the "abuse" hasn't stopped billions from using these devices anyhow.
But it's clear that arguing this point with the scoped-storage fanfolks who've shown up here is pointless.
Hopefully, Android will consider this and many other constructive ideas over the next year, before changing the platform in a way that makes it unusable for scores of developers and end users accustomed to more open and functional systems. If the proprietary lockdown goes through as is, Android will never be a PC alternative; in fact, it will be something much more akin to the cartridge-based Game Boy of eras past.
But it's clear that arguing this point with the scoped-storage fanfolks who've shown up here is pointless.
Hopefully, Android will consider this and many other constructive ideas over the next year, before changing the platform in a way that makes it unusable for scores of developers and end users accustomed to more open and functional systems. If the proprietary lockdown goes through as is, Android will never be a PC alternative; in fact, it will be something much more akin to the cartridge-based Game Boy of eras past.
ke...@gmail.com
#6
“in the name of preventing abuse you'd deny people the right to store their content on their devices the way they wish”
Yes, such abuse is a real threat to android ecosystem just like the dark age before Android 6.0 when runtime permission did not exist that we had to rely on raw AppOps to deal with permission hungry PUAs(potentially unwanted apps).
The AppOps firstly showed up since Android 4.3 in 2013, and we have waited for another whopping 2 years to see the AppOps based runtime permission mechanism. Such a long delay should not happen again.
“in the name of preventing abuse you'd deny people the right to store their content on their devices the way they wish”
Yes, such abuse is a real threat to android ecosystem just like the dark age before Android 6.0 when runtime permission did not exist that we had to rely on raw AppOps to deal with permission hungry PUAs(potentially unwanted apps).
The AppOps firstly showed up since Android 4.3 in 2013, and we have waited for another whopping 2 years to see the AppOps based runtime permission mechanism. Such a long delay should not happen again.
sb...@gmail.com
That seems an extreme and narrow view which more than a few Android developers and users would naturally disagree with. But there are clearly multiple strong and wildly differing opinions on this topic. Let's hope that Android has the wisdom to reconcile them without truncating its functionality and user base in the process.
ow...@gmail.com
Way to go Google. Instead of compromising, you will screw over every developer and user who depends on the openness, and reliability of the platform for so-called security.
I will not argue whether or not there is a legitimate security concern, for there is. I, however, firmly believe that this action and others like it are not the way to go. You are destroying user choice in interest of slightly enhancing security. Is it really worth it?
I have been with Android, and developed for it, since 2.3 on a Droid X. I'm now on a moto g6 running 9. I'd love to stick with the platform, but I'm running out of reasons to do so
At this point in time I have no intention of supporting any platform beyond 9.0 simply because about two thirds of my current apps cannot perform under such restrictions. I am sorry, but I cannot and will never attempt to support an ecosystem becoming increasingly restricted. This will be a loss for the roughly 1M+ users of my company's apps, but we are left with very little choice
I will not argue whether or not there is a legitimate security concern, for there is. I, however, firmly believe that this action and others like it are not the way to go. You are destroying user choice in interest of slightly enhancing security. Is it really worth it?
I have been with Android, and developed for it, since 2.3 on a Droid X. I'm now on a moto g6 running 9. I'd love to stick with the platform, but I'm running out of reasons to do so
At this point in time I have no intention of supporting any platform beyond 9.0 simply because about two thirds of my current apps cannot perform under such restrictions. I am sorry, but I cannot and will never attempt to support an ecosystem becoming increasingly restricted. This will be a loss for the roughly 1M+ users of my company's apps, but we are left with very little choice
ke...@gmail.com
@9
Sir I have been with Android since 2.3 too.
So it is only because such changes infringes your interest, and yes, you are supposed to speak for yourselves.
"You have no intention of supporting any platform beyond 9.0 simply because about two thirds of your current apps cannot perform under such restrictions.", please manage to do it, however you will not.
Sir I have been with Android since 2.3 too.
So it is only because such changes infringes your interest, and yes, you are supposed to speak for yourselves.
"You have no intention of supporting any platform beyond 9.0 simply because about two thirds of your current apps cannot perform under such restrictions.", please manage to do it, however you will not.
ad...@google.com
In Android 11, apps with justified need for broad access to shared storage can use the new permission MANAGE_EXTERNAL_STORAGE. The storage access framework is another way to get user permission to access different files. Thank you for your feedback, but we do believe the benefits of this change outweigh the challenges.
sb...@gmail.com
The MANAGE_EXTERNAL_STORAGE permission was added after this post, of course. I don't have a problem with it in general, and device security is important too. But why don't you add a way for users to enable this for specific apps directly? A toggle in Developer Options with a clear warning, or even an obscure ADB command would allow people who know what they are doing (including most of us developers) to restore broader permissions for an app, but still not expose naive users to the risks Android seems to be focused on. As it is, C++/POSIX programs must be augmented to use a proprietary Java-based layer, which comes off as a bit dogmatic and exclusive, and means that much prior art will never be available on Android.
sb...@gmail.com
The preceding comment's idea has been posted as a new proposal at
Description
Consider users of an incremental backup tool on Android. They'd like to store heterogeneous content in a single location that's both easily managed by the tool, and accessible to arbitrary apps like file explorers, image viewers, and document editors. They may also wish to process their content with programs which were born on other platforms and won't be converted to use
Android scoped-storage APIs any time soon. The Download shared-media folder won't cut it for these contexts.
A single shared folder ("/sdcard/Documents"?) that is freely accessible and not pruned on app uninstall would enable both generalized usage paradigms, as well as portable software that's impractical to recode for proprietary file constraints. Because this access would be limited to a single folder, this would also solve the goals that scoped storage seems meant to address:
people who don't require general content access would have just one folder to clean if and when needed, and tools could help make this obvious.
To be sure, this developer, like most, would prefer that scoped storage not happen at all because it inherently reduces device functionality. But a single open-access folder could make this change a lot more palatable to many. Why satisfy goals for some users at the expense of others when you can meet the needs of both?