Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developing for Android is like being a demonetized YouTuber

gbl08ma.com

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Developing for Android is like being a demonetized YouTuber

#111

Post by xrd »

gbl08ma wrote: post #5
xrd wrote: post #3

Two thoughts: I got a little caught up in the argument about clipboard apps suddenly being broken as if there was no thought put into the impact it would have. Clipboard apps on Android are currently very dangerous since an app can access the clipboard without asking for permission so the user can unknowingly share anything in the clipboard with malicious apps. That's insane and Google is right to fix this even if it…

I agree with you on the clipboard thing, but as with every other API that gives access to sensitive information, they could have put it behind a permission prompt. It wouldn't make the situation worse than it is now, and wouldn't annoy users and developers nearly as much.

What you are suggesting seems so obvious that I'm assuming they couldn't do this. Android Permissions on older targets essentially "grandfathers" in apps since older versions didn't need to write code to ask for each permissions at runtime (they asked for the entire set of permissions at install time). I imagine there was no way Google could effectively permit apps targeting older versions to run safely inside the new OS. So, they just took the hard path for developers and are forcing those that really need the permission to update their apps. I'd be unhappy too, but I wouldn't be entirely surprised, and I'd only be furious if I was doing something bad and couldn't anymore. There is going to be the new permission READ_CLIPBOARD_IN_BACKGROUND which will give me whatever I need, and let users know I'm using it, so if I'm willing to write the code, I have everything I need.

Re: Developing for Android is like being a demonetized YouTuber

#112

Post by qwerty456127 »

jbk wrote: post #110
qwerty456127 wrote: post #108

Earlier quoted context omitted.

You're the guy behind VLC for Android? Amazing job, it really is an essential app I couldn't live without! The only problem is years pass and I still can't find how to turn a directory into a playlist without hand-checking every single file in it (for me this usually means hundreds).

On the folder, in the directory view, click on the play button and then save the playlist

Cool! Thanks a lot! This is it! However there still is a problem. In the past I used to just play entire directories (switched to using playlists then) but after an update (about half a year ago or earlier) and ever since it stopped playing some big directories (with many hundreds of files in them). Before that it was just enqueuing the files, then sort of hanging for some dozens seconds and working. Now the name of the directory just appears in the playing queue and nothing happens, it doesn't get expanded into the files list. But who knows, perhaps I just have to wait longer...

Re: Developing for Android is like being a demonetized YouTuber

#113

Post by Mindless2112 »

UncleMeat wrote: post #93
Mindless2112 wrote: post #2

I don't really mind that some behaviors are being restricted. (Although I think removing the ability for apps to toggle WiFi is nonsense.) The problem is that Google wants to break API compatibility without actually calling it what it is. Your app, which worked for years, is now broken and as far as the user is concerned it's your fault. I've been tempted to set the "max API level" property on my apps so that I don't…

You've got between the beta release and when Play will mandate that you target the new sdk. That's like three years.

Many new restrictions apply to apps regardless of the target API level, so all you actually get is from beta 1 to final release, and that's assuming all the restrictions are already enforced in beta 1.

Re: Developing for Android is like being a demonetized YouTuber

#114

Post by curlypaul924 »

indigo945 wrote: post #35
cm2187 wrote: post #22

Earlier quoted context omitted.

I compare that to Windows which has been around two decades longer than iOS and Android and which APIs have remained remarkably stable and backward compatible. It is possible to do it. It is just more work.

Well, to be fair, this comes at the cost of Windows (like other major desktop operating systems) being considerably less secure than Android or iOS. This tradeoff is not easy to avoid except by designing the permission model to be sane from the start, and we all know that good upfront design doesn't exist.

That's not really being fair; Windows was created decades before Android (one decade if you only count NT). The security model is different, because it was created in a different computing era.

I think the difference in API stability is a result of the different financial motivations between Microsoft and Google. For Microsoft, the OS itself was the product; to not make the APIs backward-compatible would have meant significantly less revenue and market share.

For Google, the OS is not the product. Google doesn't make any less money when someone continues to run an old version of Android. There is no monetary incentive to make new versions of the OS API-compatible with older versions, nor is there any monetary incentive to make new versions of the OS run on old devices.

Consider also that the cost of upgrading to a new (non-flagship) device in 2019 is much cheaper than in 1995. A typical PC circa 1995 could cost $2000 or more (price adjusted for inflation). Today, you can get an entry-level mobile phone for 1/10 that price. Back then, a family might hold on to a computer for five or ten years, because it was so expensive to upgrade. That makes paying $100 or so for an OS upgrade every few years worthwhile, because it's much cheaper than buying a new PC.

Re: Developing for Android is like being a demonetized YouTuber

#115

Post by iggldiggl »

jbk wrote: post #21
fattire wrote: post #16

Android's Storage Access Framework is really underrated. Just ask the user to choose a document (file or image or whatever) by firing an intent-- then Android's built-in file picker starts up and you don't have to deal with implementing any of that UI experience. After the user picks the file, a content:// URI is returned back. https://developer.android.com/guide/topics/providers/documen... Best part-- along with the…

> But in most situations involving External Storage, the SAF is really what you want to use anyway. Or not. A File Picker does not work for playlists, linked MKV/MOV files, subtitles autodetection (subfolders and such), and so many other multimedia cases. Also, it is a pain to use from the NDK... And incorrectly documented. And then, the UI to allow people to give you access to the folders is extremely confusing, har…

> Or not. A File Picker does not work for playlists, linked MKV/MOV files, subtitles autodetection (subfolders and such), and so many other multimedia cases.

Exactly. HTML files are another victim of this, as with content://-URIs there's no official way to properly resolve relative URIs for any subresources (images, style sheets, scripts and whatnot) or local links, and even if you could, you wouldn't have the permission to access those files anyway. Even Android's included mini HTML-viewer app (or Chrome for that matter) are broken if you try viewing a HTML file using a content://-URI, e.g. from the file explorer that's built-in since Marshmallow.

I opened https://issuetracker.google.com/issues/77406791 for that, but you can guess at the reply I received so far (none - I guess I should be glad they didn't close it outright...)

And another problem is that even if your app has the appropriate storage permissions itself (whether through READ_EXTERNAL_STORAGE or the new-fangled way, even if that means dealing with the SAF) and could therefore open both that file and its companion resources without relying on the permissions attached to the content://-URI intent, in practice that's rather difficult because even for local files there's no official link between the content://-URI and the file system location. In practice at least some ContentProviders will leak the path through the URI, allowing you to reconstruct the original file path with a little luck, but that's of course not really a reliable method.

Re: Developing for Android is like being a demonetized YouTuber

#116

Post by iggldiggl »

swiftcoder wrote: post #79
gmueckl wrote: post #74

Earlier quoted context omitted.

Apps need my permission to access external storage even today. I don't see how a convoluted UI helps here. Although it may not be international (I think intentions are good), this change will devalue internal device storage to such an extent that people will see themselves forced to store even more data in cloud services of dubious reputation. Technically, they don't have to, but it will likely be easier for the mass…

> Apps need my permission to access external storage even today. I don't see how a convoluted UI helps here. Consumers tend to just click past permission prompts, hence granting malware permission to everything. Power users can take care of themselves, of course, but most consumers don't have the technical knowledge to safely deal with this kind of permission prompt.

The major problem isn't replacing the blanket READ_EXTERNAL_STORAGE permission with something a little more fine-grained, but the fact that after requesting access to some user-picked directory tree, apps still have to go through the Storage Access Framework with all its warts and deficiencies instead of being able to use normal file system access if the picked directory is part of the local storage.

If it had been implemented that way, there still would have been some usability problems (some users will likely always manage to pick the wrong directory and then wonder why the app doesn't work), but other than that it would have caused much less trouble.

Re: Developing for Android is like being a demonetized YouTuber

#117

Post by iggldiggl »

Arnt wrote: post #82
fencepost wrote: post #63

Didn't they do some of this kind of storage crap back on 4.x? And for that matter, isn't this pretty much exactly what Microsoft was doing with Windows Phone? My annoying use case for those was ebook readers - I have a pretty massive library of epubs (Thanks Baen Webscriptions!) and have tended to just dump a ton of them into a folder in storage on a device. I can then pull those up in CoolReader, Moon+ Reader (posit…

That you can still do. The future notion is that that storage directory is yours, and apps don't have total access ("write anywhere, read anything, delete whatever"). FBReader cannot dump some more ebooks in that directory. FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases. It doesn't sound…

> The future notion is that that storage directory is yours

One problem is that unless I want to plug my phone into my computer each time I need to manage the storage or use the rather limited built-in file explorer, I'm going to have to use some third-party apps myself (that I have decided to be trustworthy enough) in order to manage "my" storage. From Google's point of view those apps remain third-party-apps though, and as such remain subject to some set of restrictions.

> FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.

I don't want my ebooks to "belong" to FBReader, though. Now yes, you can still do that as long as you only open the books from inside the respective reader apps (copy your ebooks into a general ebooks directory on the storage and then give each of your reader apps permission to access that directory), but

> can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.

Google wants the above to be the only way to pass file references around between apps, which is stupid when a) that file doesn't actually conceptually belong to the sending app, and b) the receiving app would have had permission to access that file itself anyway.

As Google has currently implemented content://-URIs for example, even if FBReader has been explicitly granted access to my ebooks directory, if I happen to open a book from my file explorer instead, then because in that case the access is "mediated by" the file explorer, FBReader cannot reliably tell that the incoming file is actually one that is already part of its library, so I potentially end up with a duplicated LRU/history entry, my reading position might not properly remembered because FBReader doesn't know whether those two files are in fact one-and-the-same or not, and, and, and... And if I happen to switch my file explorer app and uninstall the old one, all references to files opened through the file explorer become invalid, even if FBReader had permission to directly access the file by itself, too.

Re: Developing for Android is like being a demonetized YouTuber

#118

Post by on_and_off »

paulryanrogers wrote: post #65
on_and_off wrote: post #11

Earlier quoted context omitted.

>reasonable deprecation timeline Each new Android version starts with a beta which previews and advertises the behavior changes, how is that not a reasonable deprecation timeline ? (real question, not trying to be cute) > don't let users install apps that target old API levels Google has been less active on that front that I would like but the play store is starting to at least enforce that new apps and update must t…

> Each new Android version starts with a beta which previews and advertises the behavior changes, how is that not a reasonable deprecation timeline ? (real question, not trying to be cute) Testing against betas can cause regressions for non-API reasons. That's why I'm reluctant to test against them, preferring to wait for final releases. For apps that need maximum stability with minimal effort deprecation policies ha…

>Testing against betas can cause regressions for non-API reasons .

if the regression is not listed on the behavior change list, create a ticket on the beta bug tracker to determine if it is intended or a beta bug.

What in this is not ok ? That's what I have been doing in the past cycles and have had no issues. I can't speak for all the usecases, but that's a reasonable process.

Post reply on HN