Yeah. But it was a lot of time. Apple had already production-tested the idea of asking users for critical permissions and making apps survive a “no”. For years by the time Google belatedly began copying those ideas.
-
-
Replying to @matthew_d_green
Google had AppOps since something like Android 4.3. They started on that a long time ago. It only became something they wanted to deploy in the standard user interface in 6.0 but it had existed as an available (but not exposed to non-power-users) feature for a long time already.
2 replies 0 retweets 2 likes -
Replying to @CopperheadOS @matthew_d_green
They chose not to prioritize making it one of the prominent user-facing features for a long time but it's not like they didn't know it was a good idea. There's essentially a budget of (potentially) breaking changes that can be made in a release and they prioritized other ones.
1 reply 0 retweets 1 like -
Replying to @CopperheadOS
In a world where Google was the only mobile OS developer in the world, or where Google was some scrappy startup, this would make sense. In the real world Apple prioritized these changes and made them all ages earlier. Google just didn’t prioritize privacy.
2 replies 1 retweet 2 likes -
Replying to @matthew_d_green @CopperheadOS
At the end of the day, if management says “we’re going to prioritize [long list of features that aren’t privacy, and oh yeah we’re going to build our own *town*” that’s management saying privacy isn’t that important.
1 reply 1 retweet 2 likes -
Replying to @matthew_d_green
For privacy features, it's not really about resources assigned to it. It's about needing to make breaking changes and only being able to get away with a certain level of that for each major OS version and API version.
3 replies 0 retweets 2 likes -
Replying to @CopperheadOS @matthew_d_green
This is mostly a false narrative. For some things (hidepid/sysmon) it's partly true, but zeroing out call/SMS data would never have broken anything. CM/LOS did it with no problems.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @matthew_d_green
CyanogenMod / LineageOS used the functionality Google wrote. PrivacyGuard is a UI to AppOps, which is the same way Android's own 6.0+ permission toggles work for legacy apps.
2 replies 0 retweets 0 likes -
Providing empty data means the apps stop providing the functionality users expect, and the apps can't check to see that the permission is gone to request it from the user. It's a major usability issue. It works for power users, it doesn't work for regular people.
2 replies 0 retweets 0 likes -
Toggles in an app permissions menu also don't particularly help most people either. Only power users are going to fiddle with disabling as many permissions as possible, and even power users are going to run into issues and forget that it was because they disabled permissions.
2 replies 0 retweets 0 likes
That's where CM/LOS got it right by default: just disabling unless a power user goes in and enables access.
-
-
Replying to @RichFelker @matthew_d_green
They shipped AppOps in the same way that stock shipped it. They didn't ever make any changes to the default experience. And by the way, AOSP has a better way of handling legacy apps called permissions review where it makes them use runtime permissions too.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.