I always thought it was insane that any app could just listen to everything that went to the clipboard, even while in the background and without any permission. I'm sure many people copy passwords, credit card numbers, bitcoin private keys, etc.
I'm still of the opinion that apps with focus should not be able to read the clipboard by default. iOS allows this too, but this means that apps can (and do!) read stuff like passwords, links, and other stuff you've been interacting with passively.
I have been highly concerned about this after I opened a certain iOS app, and was immediately greeted with a system alert saying "Pasting from Mac..." even though there was NO reason whatsoever for it to access the clipboard (it was basically the first-run splash screen.)
Thanks to Apple's Continuity feature [0], you can seamlessly copy/paste across iPhones, iPads and Macs, and indeed it can be handy.
But if my network (or something else) hadn't been laggy at that time, I would have never caught that app trying to obviously snoop my clipboard's contents. I'm sure many more apps do this and they must be exfiltrating it.
And yes, I often copy/paste sensitive data to avoid retyping it, so this is practically CROSS-PROCESS, CROSS-DEVICE SPYWARE in an innocuous way that very few people would even think of, or should ever have to worry about.
The solution is simple: Don't let any process read the clipboard unless the user explicitly chooses to paste.
Apps that need automatic clipboard access to offer added convenience (like autofilling certain forms) should require explicit permission, just like we have for camera/microphone/etc., and preferably only while the app is in focus.
After all, such "intent-based security" is the reasoning behind the existing macOS "PowerBox" [1] which lets apps access only the files that the user manually chooses in an open/save dialog. Extend it to the clipboard too.
> The solution is simple: Don't let any process read the clipboard unless the user explicitly pastes.
but how does an OS know that a particular key combination is meant to mean "paste"?
Couldn't the app just pretend that the user wanted to paste because their cursor is in the password field?
Or, you end up with the OS owning all of an app's interaction. Leaving very little room for app innovation or improvement. It's a bit of a rock and a hard place.
> how does an OS know that a particular key combination is meant to mean "paste"?
macOS and iOS can do that easily; every app has a standard menu provided by the system, as well as a mechanism for modifying default shortcuts.
The clipboard should be treated like a potentially sensitive file. There's no excuse not to include it in the explicit permissions we already require for other files, photos, camera, microphone, contacts, location, and so on.
It makes me beyond annoyed that google seems to insist on radically changing the design of their apps every 6 months, for no discernible reason, with no unifying theme or thread or underlying rationale.
"material" itself doesn't support many things on android ie there are no android versions of things. it's crazy considering the same company is supposedly using the spec for their device designs.
You're not the only one. I got yet another update to Gmail on Android a couple of weeks ago - honestly, it looks familar... it's like they've changed it so many times it's back round to how it was at some point in the past!
I agree - there really is a lot of white in the latest update! I'd much prefer a bit of colour to help delineate different sections of the UI, such as the search bar and buttons.
This is the essence of Google. They’re too big to fail so they can pretty much do whatever they want. Kill huge apps (Reader, Picasa), major paradigm shifts in UI, abandoning projects, fragmented efforts... how many messenger platforms do they have again?
Pretty much any other company would die from this kind of wheel spinning and frantic behavior, they’re fortunate to get away with it.
I wish the text was bigger on the Android version, similar to how much more space it takes up on the Apple one. Boosting readability is important, and the font is a little small for my taste.
Agree. This looks like the kind of UI that was designed in Photoshop or perhaps a device simulator and then never vetted on a real device by a real person. It's not great.
I thought you were exaggerating until I went to look. That does look just like the notifications that I get on the ipad. I'm surprised to see them match it so closely, but I'm glad to see improvements in this area on Android anyway.
Other times an adaptation of one animal so radically changes the environment that other animals adapt similar traits because of it. When one poisonous insect becomes red and birds learn to avoid red insects, red is a useful color for other insects to be as well. Innovation is good, but copying good innovation isn't bad; variation let's us explore, convergence let's us carry experiences from one platform onto another. I like that the two dialogs look so similar, though I wish Google would copy Apple's text formatting a bit more closely, and I feel like Apple should copy the location marker at the top of Google's dialog.
Its a white dialog with blue clickable text. The text length makes standard blue buttons impossible. This is just what state of the art "developer ugly" looks like.
iOS and Android design seems to be converging more and more lately.
Starting with material 2, Google has decided to center align a log more elements on the screen (text, icons, etc). Google has also shifted to a lot more white and gray with blue used for actionable items.
In both cases it seems like apple got it right the first time, Google tried to pioneer the opposite and has now gone back and copied Apple.
Meanwhile a bunch of designers at Google have gotten promoted for their diligent work.
It is pretty striking how similar the UI is starting to look compared to iOS. And I say that as someone largely on the Android side of the Android-iOS debate. Also add to that the shift recently to move navigation to the bottom of the screen in the form of tabs.
I guess ultimately there's plenty of examples of this happening both ways, though.
Convergence of UX for the same context and expectations is a Good Thing. This is symmetric to expecting cmd + X and cmd + Z to do the same thing on different OSs and apps. No reason for it to be considered a bad thing.
This is shameful. I have no words. It's practically a verbatim copy. Of course, getting the font sizes wrong, because it's Android. But other than that, just shameful. It doesn't even look like Material design. I seriously hope they change it before release.
It's like the engineer in charge of the feature couldn't get a hold of a designer and so had to make the design himself... so he just took if off his own phone.
This is relative to desktop where traditional apps don't even run in a sandbox and app permissions weren't a thing.
A Linux app can not only create Internet connections, it can read and write all your personal files. (But we thought that was pretty secure since it didn't run as root.)
Linux apps aren't infested with malware and tracking trojans though, if the threat doesn't exist then there's no reason to protect from it. With android collecting this sort of data is it's very reason for existence.
Sure it exists, but it's not an infestation. Even then I'm not aware of it or telemetry enabled apps in any trusted sources like the debian repositories (if you're aware of any please let me know), they'll even disable it from organisations like Mozilla that don't care about privacy. The play store cannot reasonably be considered a trusted source.
If your going to download stuff from random places, which is how most telemetry enabled apps end up on linux systems then no sandboxing will work anyway, it will simply be disabled as part of the installation process. It's not a technological problem, you can't fix it with technology.
Yes, a Linux distro like Debian has some security advantages since they won't ship just any app. But relying on code review isn't the same as having sandboxing in the OS.
There's two successful systems I know of out in the real world, Linux distros that rely on code review and iOS that relies on code review and sand boxing. There's two failures, android that relies purely on sandboxing and windows, which was too gimped by sandboxing to take off.
> But relying on code review
It's not just code review, it's having a degree of seperation between the developer and the packager/authorizer.
Some things are more successful than others, but it's not a one-bit distinction. Arguing over whether to set the "success" bit would be silly. But it seems arbitrary to say that Android is a failure when it has more users than iOS or Linux.
Browsers are another important example of sandboxing.
> But it seems arbitrary to say that Android is a failure when it has more users than iOS or Linux.
I'm not saying android is a failure, I'm saying it's sandboxing has not prevented malware and spyware being ubiquitous. This was a problem way back before android itself was a huge success.
> Browsers are another important example of sandboxing.
This has been pretty effective at preventing malware, but the web is a privacy nightmare and constantly getting worse.
Ok, I see what you mean. Caveats: Android doesn't rely solely on sandboxing. They also do automatic scanning and do often find stuff [1]. I also wouldn't say malware is so bad it's "ubiquitous" on Android since it's in the news quite often but I don't think the average user is likely to encounter it?
My take on it is that current-generation sandboxes have permissions designed for security (preventing takeover by hackers), not privacy. In particular, preventing an app from phoning home isn't something they try to do. You can't have privacy without security so sandboxing is a prerequisite, though.
That's just because few people use Linux, not because Linux has some inherent ability to stop people downloading malware. In fact it has less than any other major OS. Mobile OSes have vaguely curated app stores and proper permission systems. And Mac and Windows have at least attempted to help with their code signing systems (even if they are pointless and annoying).
Linux has "run this `curl | exec` command as root".
> Linux has "run this `curl | exec` command as root".
You've clearly not used Linux much of you think that's the normal software installation method. That's the normal installation method on windows, minus the GUI to download and run for you.
> That's just because few people use Linux, not because Linux has some inherent ability to stop people downloading malware
You can't stop them downloading it, you have to direct them to trusted sources to get software, that's where Linux and iOS work, they have same approach but different implementations, it's where windows and Android fail.
> Windows have at least attempted to help with their code signing systems
Their best attempt so far is the windows store, but that was still born because they went for the sandboxing instead of verifying approach.
> That's just because few people use Linux
And all those servers aren't high value targets? We'd be seeing a lot more issues if "curl | Sudo exec" was how things were done.
> Android was designed with security and privacy at the center.
iOS does enforces code signing to avoid app modification since it was last signed while Android allows the code to be modified even after installation.
Under a lot of aspects I do agree Android was built as a secure by design system, but the aforementioned problem seems to be in the opposite direction, at least IMHO.
Can someone up on current Android tell me how things like this are still common?
https://news.ycombinator.com/item?id=19380012
Personal interest: I’ve been using Linux since the early 90s, and was psyched to see what the Danger HipTop people could do with Google backing. The first time I looked closely at Android phones I ran into multiple articles on the topic “what anti-virus software should you run on your new Android phone”, and I haven’t done more than play with Android since then.
It's just apps including tracking code to make money. These days that's how apps monetize. They upload whatever amount of data they can get in exchange for pennies. There's not much you can do short of not allowing apps to do literally anything.
Adwares are just that, ads. Sadly, the mobile app economy runs on ads.
>Starting in Android Q, apps must have the READ_PRIVILEGED_PHONE_STATE signature permission in order to access the device's non-resettable identifiers, which include both IMEI and serial number.
While I welcome this improvement, I can't help but think that app developers will respond by refusing access to the app unless the user grants the permission. Both android and ios need to be able to "silently deny" permissions.
> I can't help but think that app developers will respond by refusing access to the app unless the user grants the permission. Both android and ios need to be able to "silently deny" permissions.
iOS doesn't need this because Apple rejects apps that demand access unnecessarily.
> Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.
>iOS doesn't need this because Apple rejects apps that demand access unnecessarily.
In my experience, that doesn't seem to be working. I've so far encountered a food pickup app that refuses to let me order without location permission (their website works fine without location, however), and a finance app that refuses to process a transaction unless I give them access to location for "fraud prevention".
I can't think of any issues in revoking app permissions on Android, going back to Android 4.something at least.
I think google is carefully saying "non-resettable identifiers", because App developers will still be able to access the Google Advertising ID, for example, which is resettable. My guess is 99.9% or more of users never actually reset it, though. I just reset mine for the first time recently (Settings -> Google -> Ads -> Reset advertising ID).
The permission is signature|privileged. Only apps signed with the same keys as the OS itself or pre-installed in /system/priv-app can get the permission at all.
On Android there's a great Xposed module called XPrivacy that can do this - produce an empty contact list, block network connections, zero out location, etc.
Cryptographically strong, secure identification coming from the ProtectedAPIs are a double edged sword. On one hand, these APIs let you build critical real world apps like ones required to remote control a medical assistance device or act as a electoral vote casting machine, but on the other hand provide very strong tracking cookie to data hungry ecosystems (Mac addresses could be spoofed but not these).
I have been thinking a Linux/Desktop fork similar to elementaryOS needs to exist for Android. ChromeheadOS was close enough, may be e.foundation would be that, may be Daniel Micay will restart his crusade again.
IIRC, signature permission means that 3p apps can't request it at all. They have to be signed with the same key as the OS, so practically only your handset manufacturer can use it.
Of course. Google's own apps already do something similar by popping up warnings. Why do I need location, Mic, and camera preferences to use gmail or other Google play services apps that shouldn't be using any of those features? That's obviously a rhetorical question when talking about Google.
Gmail does not require location, mic, or camera access. In fact, the Gmail app does not even request any of those permissions, so I'm not sure what you're talking about.
There is nothing to suggest that Vulkan is now required.
> Speaking of which, it is going to be the usual partial Java 8 variant, and Java 12 is going live next week.
Java's version number has been hijacked to mean OpenJDK's runtime version & handful of non-core library updates that don't exist on Android anyway.
It has vanishingly little to do with the actual language or core libraries these days.
The only thing of interest at all between Java 9, 10, and 11 are var handles (compiler-only, no runtime support needed - should work fine on Android), and the Flow class. Which is unfortunately missing, yes, but not particularly significant. Might work better as an AndroidX addition anyway.
Since Twirrim already tackled Vulkan, I will only answer on the Java part.
The only thing of interest for Java developers, is being able to use any standard Java library out of Maven central, instead of having two versions or minimal common code, and not excusing Google for having successfully created a fork in the Java eco-system, aka Android J++.
Rest assured when Valhalla and Panama finally land, it will only get worse.
The only thing that matters for library interop is the bytecode version, not the "Java" version. Binary version & source version have been different attributes in Java going all the way back to the J2ME days.
> Rest assured when Valhalla and Panama finally land, it will only get worse.
You're assuming that Android won't have support for those, but that assumption is unfounded. Android has so far gotten support for all the bytecode-level changes that have happened like invoke-dynamic.
Java 9, 10, and 11 have not changed the bytecode. Nothing about the compiled binary has changed to require support. And outside of Flow none of the core libraries have changed, either.
There's no forking or hijacking in play here. Oracle just hasn't done anything that needs support from a runtime since Java 8.
Ah my mistake then. Is there any way to actually use that instruction from Java though? Or is this just bytecode support for a potential future feature?
It gets used by the compiler, so unless ART gets to understand it, those nice Java 11 libraries at Maven central that might make use of it are a no go on Android.
And yes, it is also related to the ongoing Valhala efforts.
So where is Android support for constant pools or nested class changes?
Of the complete Java standard library for that matter.
Of course I am assuming the worse from a company that insists in getting away with Android J++, while having fanboys supporting their agenda, many of which were even on the first row against the old J++.
But I get it, the "Do no evil" company has lots of SV love.
> There is nothing to suggest that Vulkan is now required.
From the article:
"We're working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices."
Which means it's not required as long as 32-bit devices are allowed to ship as well. It will be a large percentage, like GLES 3 is, but not required, like GLES 3 isn't.
I googled around and honestly can't find a single phone introduced in 2019 that's still 32-bit.
Sure, embedded non-phone Android devices could still be built with 32-bit CPUs to cut costs, but those devices typically don't let user install 3rd party apps in the first places so they're not relevant to the discussion.
Preliminary VarHandle support in Android start in P. The API is hidden, but it had to start ahead of the Java 9 libraries because it's a lot of work.
All code needs to be capable of being interpreted as that's the fallback when compilation invariants are violated (and also when stepping through code with the debugger).
A large number of operations combined with different vartypes and backing store types (fields, static fields, arrays, Buffers, etc) makes for a lot of work, even though this is just the slow path.
There is no compiler support yet for VarHandles, or MethodHandles, on Android, but there are bugs on these.
I thought that Native MIDI API would be something that places NDK as first class citizen, but as you mentioned it's a bit constrained. But it's more that Native MIDI is first class, than whole of NDK.
Nice to see that the original Pixel and PixelXL will be getting Q. It's always struck me as weird that Google sells that line of phones ostensibly for people who care about their OSes more than normal, and then only offers a couple of years of new OSes on them. Maybe we're seeing them turn the corner on that.
I was just watching a video a couple minutes ago about changes to system navigation in Android Q [0].
Oddly, I don't see any mention of it in this blog post.
Can someone explain how (1) switching buttons into gestures and (2) changing the recent apps screen from a list of all apps on 1 screen to a full screen for each app...how are these good ideas? What is the design philosophy for these changes?
They seem like gargantuan steps back in ease-of-use and intuitive design.
I'm looking forward to jumping to a Pine64 or Purism phone before I am compelled to use this mindless ripoff of stupid Apple interface design.
> changing the recent apps screen from a list of all apps on 1 screen to a full screen for each app...how are these good ideas? What is the design philosophy for these changes?
If you mean how the "cards" are now side-by-side instead of "stacked", I can assure you this is a HUGE improvement. I use this already on my Oneplus 6T.
The likelihood of requiring a recent app decreases enormously the further back in time you go. 95% of the time, you want the the previous app. 4% of the time, you want the next most recent app. 0.5% of the time, you want the third one... (all figures made up by me on the spot).
My point is, swiping left-to-right to expose cards in the past is FAR better than pulling down and shuffling through this crazy infinite deck of cards that flies by top-to-bottom.
Android P on Pixels actually has the option to double tap on the recents icon or flick right from the home button. Flick right should be just as easy as double tap in theory, but I haven't learned how to make it work 100% of the time yet.
Exactly. The new interface, even if it makes logical/quantitative sense, is functionally worse. I don't ever need to see the whole screen of an app to before deciding if I want to switch to it or not. Having all the titles and windows of open apps in 1 tidy list is way more functional, even if I only rarely access old apps.
> Oddly, I don't see any mention of it in this blog post.
From my experience, gestures and navigation changes quite wildly between beta builds, as they test different things to get feedback, so what you see here may be very different from what we get on release. I'm guessing the blog post covers the more stable features.
Just a nitpick, but the two changes referenced in the parent comment (whole screen 'cards' for multitasking view and using gestures for such) are straight from WebOS for both Apple and Android. Being a step back in UI is also a bit subjective, I personally find it a lot easier to navigate between the apps I regularly use now.
Edit: Just installed the android Q beta and the back button is still present, I was not aware of the potential loss of the back button. I can see why that would be considered such a step back in usability.
I think you're going to be in for a big ol' frothy glass of reality check juice if you're thinking Purism is going to have better usability than Android or iOS...
> The back button is vestigial tech debt. Gestures are the future.
I don't necessarily think that the back button will remain, but I think it SHOULD remain. Gestures are cool, but the back button is like the undo feature: it gives user a visible, clear button to correct a mistake or cancel an action.
Gestures are not immediately visible/discoverable, so while for a tech savvy it might not be a problem, for the average consumer (think of your dad, or aunt, or grandpa) it is a usability regression.
Devils advocate: the iPhone has never had a physical back button and it's a wildly successful device with people across all walks of life and levels of technical experience.
I think a lot of Android users feel this way but it is clear that Android is moving away from physical buttons. It's a crutch that Google is finally getting rid of.
On the other hand, most ordinary non-technical folk I know of don't know about about iOS swipe-to-go-back gestures, as iOS has largely moved from buttons to non-discovered swipes, special presses that most people won't know about unless they RTFM which they never do.
The swipe to go back gesture only applies to navigation controllers in which case there will always be a back button in the top left corner.
And yes they removed the home button and replaced it with a swipe up. But they have an annoying dark black line to indicate this. And you literally can’t use your phone without this one, simple gesture.
I think basic usability and user-friendliness on iOS has been going backwards since iOS7. I still think the platform overall's preferable to Android (hobbyist interests aside) mainly because Android started so far behind and, despite improvements, continues to bumble about, but I miss having an OS that I liked using but that I'd also unhesitatingly recommend as a primary device for my tech-confused relatives.
The problem is you have very loud early adopters who are abrasive and forcefully tell everyone that X is the new hotness and you're an old grandpa for wanting old-X and, ha, by they way, I'm pissing on your lawn. So, the rational majority get tired of trying to be heard and give up. Google and Apple, thus, never hear from them.
I think this basically kills a large chunk of the KDE Connect functionality I rely on. No more background clipboard access means no more clipboard sync, and closing off SD card access means it can no longer act as a wireless alternative to USB file transfer (which is terribly unreliable on Linux).
They can still access their own private area within external storage, which is fine for apps that just want to store large amounts of their own data, and they can use it for photos, video and music. There's just not any kind of general access to it anymore.
Yes, my interpretation is that that apps that simply used to use the READ/WRITE_EXTERNAL_STORAGE (runtime) permissions (which, if granted, implicitly give access to the whole storage, albeit possibly with some write access restrictions on removable SD cards) now instead need to explicitly ask the user to pick an allowed directory tree (or trees) using ACTION_OPEN_DOCUMENT_TREE.
So nothing that used to work should have become totally impossible now and instead of a simple yes/no choice users now could also answer "Yes, but only this directory", which should be nice, although it also means a slightly more complicated UX.
Of course Google also prefers you to use content://-URIs instead anyway. Those do indeed have the advantage that the receiving app doesn't require any special permissions because it simply uses the permissions granted by the app sending that intent, but at the same time they also have a number of issues that Google chooses to ignore. I've ranted about some of those here (https://hg.mozilla.org/mozilla-central/rev/9175cafb84bd), and the most important in my view is that content://-URIs as currently implemented totally break opening of locally stored HTML files (https://issuetracker.google.com/issues/77406791) and other similar content that implicitly depends on more than the one file that can be transmitted through the content://-URI intent.
Is it just me, this seems to be dripping with marketing schtick?
: rant on :
> Android is right at the center of this innovation cycle
> Android was designed with security and privacy at the center.
[ Ok. I get we're reading about Android¡ I disagree completely about this last point - it was always about advertising]
> One thing that's particularly sensitive is apps' access to location while the app is not in use (in the background).
[No mention that, by default, apps can phone home... which is a far greater privacy concern imho]
> If your app is in the background and needs to get the user's attention quickly -- such as for incoming calls or alarms -- you can use a high-priority notification and provide a full-screen intent.
So now my phone is no longer a phone, but a high priority notification device? They still don't give us inbuilt firewall/ adblocker, and they seem to continue the trend of making & receiving calls more obtuse by allowing every aspect of my 'phone' bleep, vibrate or blink at me.
What's the use case of allowing location access in the background for the user of the cellphone. I understand the use case for advertisers and other companies whose revenue model is based on spying and collecting data, but I can't imagine any application I'd be running on the background that would need location while it's in the background. Do people put map apps in the background? What other legitimate uses are there for location data?
> I can't imagine any application I'd be running on the background that would need location while it's in the background. Do people put map apps in the background?
Many Uber and Lyft drivers run Waze in the foreground and the Uber/Lyft driver app in the background.
I used that approach in a custom app for a family to track a person with MCI in case they got lost. (MCI=Mild Cognitive Impairment - memory problems basically)
Installed this, seems to mostly work okay. Looks like they broke Go on Android for now though [1] - unfortunately Syncthing is written in Go. Amusingly this bug was posted (by a Googler) about 7 weeks ago.
Has it? Does it afford me 'contextual' permissions, rather than an app just requesting contacts for no reason? Does it let me know _what_ data it's requesting (long/lat coordinates, state/county, country, continent?)? What about the data it's requesting about my contacts, does it tell me which contact's data was accessed, and what data that was (first/last name, DOB, email, phone number)? Does the app make a request to a server after getting that data, does it store it on a server? Are apps compliant with the GDPR, do they respond to privacy requests, such as what data they store, or whether they delete data when asked to do so?
Everything you see about privacy is an illusion, designed to do the bare minimum to make people think Google respects your privacy. But there's a reason Facebook likes Android simply due to how much information it gives developers with or without permission. You can hope the user allows that location permission (accidentally just once is all it takes).
Without actually detailing what information they want, why they want it, how they'll use it and how it'll be stored and processed and deleted (LOL) then no, privacy has not increased.
And this isn't exclusive to Android, but operating systems and 'apps' as a whole.
"privacy has not increased as much as you would prefer" and "privacy has not increased" are two distinct statements. You appear to be making the former, but asserting that it's the latter.
This beta has nothing exciting and just shows that both iOS & Android copy the best ideas.
e.g.:
Sharing shortcuts - it looks very similar to iOS sharing sheet with AirDrop users around you.
That's a mix of subjective stuff (you don't like UI changes, I do), and simply missing things like the big platform change in 8.0 which actually speeds up the adoption/updates (project treble). Please don't troll.
Project Treble relies on OEMs to actually bother to deliver updates, sofar they have cared so much that Google is finally adding some kind of update clause to Google Play Services access contract.
A part of that dragging feet was that they had to port all their (imo unnecessary) "value add" every time. This approach from Google actually works from both ends: incentive - you have a portable/stable base, and enforcement - now that you have it, stop doing stupid things.
The filesystem issue is going to be a problem for me. I have an app that writes about 1000 images a day from user photographs which should certainly not be mixed into the general images pool! And I want to be able to browse my filesystem. It sounds like that's basically out without rooting now.
Instead, I was waiting for an understanding that phones and tablets are becoming ever more general purpose devices, which means having a lot of niche applications which should have more control over their use of resources, including memory and cpu use. Notify, warn, make a lot of noise - but let the user decide if the app is making the right choices for their device, not the ideal device in the sky. It's not that hard to have minimum/low/standard/high/maximum use flags for cpu, ram, network, etc. And then make them actually mean something significant.
> The filesystem issue is going to be a problem for me. I have an app that writes about 1000 images a day from user photographs which should certainly not be mixed into the general images pool!
The app doesn't need to contribute the photos to the shared media store. It can if it wants to allow other apps to also have access, but it can also write them to its own private directory.
> And I want to be able to browse my filesystem. It sounds like that's basically out without rooting now.
The scoped storage changes are something that app developers must handle, but you, as a user, will still be able to browse the entire SD card. (I'm a member of developer relations on Android and wrote a proof of concept file browser that works just fine on Android Q. :)
Any chance this PoC file browser is open source and available? I've been looking at these changes and I'm not sure how I should handle discovery of new devices, e.g. insertion of a new SD card, or an OTG USB device.
Generally, an app can ask the user to grant it access to other directories on the device, including the actual SD card root. (The user can also decide to only give the app access to a subset.)
Specifically, the API one uses is ACTION_OPEN_DOCUMENT_TREE.
I feel the same. I've been using Termux a lot recently and I love that it has the ability to access local storage. I can just run a sshd from termux and rsync music and photo files to my phone. This is the mail reason I like android better than iOS. Easy access to shared file storage.
I'm also wondering what will happen to all of those File Manager apps on PlayStore.
The app can always open the system "Directory open" dialog though storage access framework and it'll get full access to that directory without being able to read all your other private data.
I always thought it was insane that any app could just listen to everything that went to the clipboard, even while in the background and without any permission. I'm sure many people copy passwords, credit card numbers, bitcoin private keys, etc.