After porting VLC on so many platforms, to be honest, working on Android applications is not too bad. Notably compared to other mobile platforms.
The tools and IDE are quite good (they need a lot of RAM though), the deployment is easy, the development workflow simple enough and the devices are easy (and cheap) to come by. Even the Play Store console is not catastrophic.
A contrario from Youtube, you can get questions answered by Google, and the dev communities are quite large.
The API changes are known 6 months in advance, which is good enough, for most cases. And you get them usually only when targeting the new SDK version (except for Android Q... why?!?)
What I don't like though, is their abysmal NDK support (notably compared to iOS), the removal of use-cases (just use SAF, right? wifi?), but mostly the APIs that are never finished and always buggy (Audio API for example), and the impossibility to send patches to fix those bugs.
Finally, the Play Store Console is so-so, but the user-facing part is quite nice.
> What I don't like though, is their abysmal NDK support (notably compared to iOS)
Yeah, this is my biggest gripe. The vast majority of popular apps in the Play Store are games, which all use the NDK. Yet Google refuses to give the NDK more resources.
Isn't that Google's intent that the NDK be hard to use? They still act like they may pull the rug at any time and switch kernels or hardware architectures on a whim, so it always seems like Google acts as though any NDK usage is a "bug" to them.
There's aspiration, and there's reality. The reality is that virtually all games, which are most of the Play Store, depend on native code. Without those games, Android would be much less attractive of a platform. Even if Google wanted to break them, they realistically can't.
I don't think I've ever seen anyone accuse Google of being realistic. They certainly don't have a problem breaking NDK compatibility at whim, hence some the conversation above and in other threads. It doesn't feel from the outside that Google cares that much about how attractive Android is as a platform to games (or much else, for that matter), where it gets in the way of whatever the aspirations du jour are. (Is this one of the months of the arcane cycle as foretold by the elders that Chrome OS is still dominant over the other signs or is it that the Fuchsia kernel that waxes in the west again?)
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).
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...
I quite like VLC on my cheap Android, and I'm glad the development experience has been reasonable! It's just the thing for my SD card full of ogg vorbis files.
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.
Best part-- along with the URI, you get the permission to access the document/file/image/audio/whatever "for free" without ever having to request it! Because you kind of just did-- the act of the user picking the file auto-gives you the read permission, which can be kept ("persisted") across system/app restarts.
This file may not even be on the actual device. It could be on some cloud service or a file server or something else you've never even heard of. Android handles it all for you. An example of this is Google Drive. If they've installed the Google Drive app and it's linked to their account, the Storage Access Framework will let the user pick stuff from there just as easily as their own external storage.
You can also use the picker to create/save a new file or even choose a whole (directory/folder) tree.
Reading from the content:// URI is a little different than from a file:// , and I know there are some situations where this won't cut it. But starting in Q you'll be kind of limited in where those files can be accessed.
But in most situations involving External Storage, the SAF is really what you want to use anyway.
> 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, hard to explain to users, not customizable, and changes from version of Android to another, so very hard to document.
> 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.
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.
Agreed that the UI could be WAY more intuitive. There are issues with it default-opening for saving to an unwritable directory (confusing people), not being clear about why you're there (no way to instruct the user what purpose they're selecting a file for except the "open"/"save" button), the side drawer is not intuitive for new Android users who might not know there are more services beyond the Download folder, etc. There are too-limited sorting options, the MIME filtering could be extended, etc. Older versions of the framework didn't even let you suggest what saved files should be called...
In the case of a sophisticated media player like VLC I totally get your point. The solution before Q was just to ask for the READ/WRITE storage permissions and have full access. I guess they figure that's too broad access for one app to have.
Upsides-- it works great on Chromebooks, integrating with ChromeOS well, and the convenience of seamlessly integrating a single UI with numerous cloud services with no extra SDKs to include or APIs to learn is also a big plus.
So how would a file manager work then? I have used several file managers over the years that allowed me to conveniently manage files locally and remotely. E.g. extract the downloaded zip file locally, edit ome of them, copy these 20 selected extracted files via SCP and delete these three folders.
Granted, I only do that on a phome in a pinch but having these features saved me more than once. I dom't want Android to become as restrictive and underpowered as iOS feels to me.
The file manager would ask you to pick (using the Android UI, via SAF) the directory where you had downloaded the zip, then everything would work the same.
Alternatively, the app can register itself as opener of zip files, then it could extract them freely to its own private directory (without asking for permissions) and let you list and upload them.
This is all a load of crappy workarounds leading to a convoluted and cumbersome user experience. From a usability perspective, I would not consider such a behavior a solution.
The alternative is malware having free reign over the entire filesystem. This is a real problem which is happening today. With your all-or-nothing solution the user has no ability to limit what files an app can access, which is totally unacceptable.
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 masses.
> 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.
The SAF APIs are cumbersome garbage up there with Account Manager and ContentProviders. Its missing important providers like DropBox, and even Google Drive doesn't implement it completely.
> Reading from the content:// URI is a little different than from a file://
I haven't found the reading part to be different, but getting the uri has changed from Uri.fromFile() to their FileProvider package. Which, requires quite a bit of setup in comparison.
To be fair, it's documented well on the Android developer site.
But there are some APIs that don't work, e.g. ExifInterface (that you need to properly process image orientation) can only read from InputStream starting with r24, and you need access to the raw File before that [0].
Suppose you're a VR app and you invoke a picker to open a... I don't know... you want to open a sound file. How should the picker's UI be to fit into your general VR interface?
If a sound file is particularly badly suited, then some other kind of file (but in that case I'm interested in why that's easier/better than sound).
Not sure I understand the question exactly. Generally, a file picker UI could look exactly the same in VR as it does out of VR, just projected on a flat surface.
The crucial point is to remain inside the stereoscopic VR view since exiting VR is very disruptive.
Boxes and drawers. A sound file could be in a collection of records or CDs or tapes. Making it just like real life is like having your users start off with the manual already read.
I’m afraid a general Android VR item picker will be a lot more boring though.
Rather older versions of Macs! With binders where you put files into, and dragging items around, and most of the applications being items on an office desk.
Nowadays I guess the surface studio is a good example. Being laid out like a drawing table and interacting with it like a drawing table.
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 have to deal with this anymore. (Oh, wait, Google changed Android to no longer enforce that property.)
If Google wants to make breaking changes to the API then give developers a reasonable deprecation timeline and don't let users install apps that target old API levels.
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 target a recent API level.
> 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 have to preserve BC at least for one release cycle.
>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.
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.
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 (position sync!) or FBReader as I desire. On Windows Phone every reader app (not that there were many) had to have its own independent download because god forbid you have shared freaking storage.
Somehow I feel that this is also going to end up hitting things like third-party gallery apps such as ones that allow tagging, along with the multimedia stuff that other folks are concerned with. Oh, and music. The death of MP3s saved locally to a device and used by multiple apps?
So much of what Google has been doing with Android (turning it into a minimal platform for running the massive Google Play where all functionality lives) seems like they're heading down the walled-garden that Apple has always been, but with creepy monitoring and ad-driven revenues layered on top.
I always dismissed iOS as an option because I didn't like how locked-down it was and I really liked swipe-based input, but now that iOS allows keyboards and the locked-down aspect is happening everywhere perhaps it's time to reconsider.
I do think sandboxing the file system makes sense. I recall on early Androids just seeing an arbitrary dumpster of files on the SD card for different apps and uses, and tons of apps had access to all of them. That's concerning.
But ideally, the user should be able to create an arbitrary storage location (say, a folder), and then permit specific apps to access it, without granting the app "file system access" as a whole.
Capability-based systems with a powerbox/picker UI are designed this way, so my guess is Fuchsia will work a bit more like this.
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 bad to my ears, except that the APIs involved need love and attention, and their documentation even more so.
(Edit: Not picking on FBReader, just using it as an example.)
> 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.
I think the point you make about walled gardens needs to be addressed more than it is. It seems to have become normalized across all platforms and that is disturbing.
I fundamentally disagree with the premise of a walled garden when there are no other options to install on a device.
The web is the only freedom devs have left and even that is starting to erode - article 13, neutrality etc.
To be honest, the last freedom of small portable devices are the Pi and the NVidia cards and a build your own solution. While I understand this isn't a true replacement for a mobile, as it doesn't have access to the web everywhere, I can't seem to think of an independent alternative that hasn't been hobbled quite a bit.... plus they're pretty fun to build. You can build pretty neat ones the size of a DS that do what you want, but again, it's not a true replacement for what you're looking for. It is a hacked solution in the truest sense. =[
> On Windows Phone every reader app (not that there were many) had to have its own independent download because god forbid you have shared freaking storage.
That's not entirely accurate, even for Windows Phone at its most restrictive (7.x). The reader app would ask for storage apps and the storage apps would provide the files. It was quite common that the storage apps seemed like they would download multiple copies each file separately for each reader app, but that wasn't always the case. Unsurprisingly, some storage apps were just dumber than others.
Windows Phone 8.x and 10 opened up more direct file system access without going through an intermediary storage app, though of course possibly too late for the impression of stupid storage apps to linger.
ETA: Not that any of this currently matters given the current state of Windows on mobile devices. :(
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 breaks things for well behaved apps. There is a lot of solid information in this article but starting with that argument set a poor tone.
Second, makes you wonder if Google as an organization wants to push you towards web apps / PWAs. Google has always seemed to think that getting people to abandon the app model benefits them and hurts Apple and maybe these changes are in search of that end result.
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.
The constant API changes has been a huge PITA for me both as a developer and as a user.
As a developer, I am forced to take time out of developing my new app to update my older apps. This year, I spent 3 months updating my 2 older apps to the newest API. My app/game that will be released soon is targeting an API that will be banned from further updates later this year. The problem is that the game framework that I use does not support the newer API yet, and development has slowed considerably on it, so I may be stuck with the (possibly monumental) task of updating the game framework myself.
My two older apps should be left alone. My users tend to stick with them because they want to use a familiar interface, and most other competitors change interfaces on a regular basis. But I have had to occasionally remove features because of API changes.
And that brings me to my gripes as an Android user - most of my favorite old apps from just a few years back with either no longer work, or have completely changed so that they aren't really the same app that I used to love.
I am really rooting for a Linux-based phone to eek out some type of commercial viability. I am willing to pay much more for a device with much lower specs and polish, so that I can have a device that respects me as a user.
> "Note that all of these things that they are removing for “security”, could simply be gated around a permission prompt you’d have to accept, as with the contact list, or location."
I think letting the user decide on permissions works in practice only if (i) There is a good chance that an average user would understand the tradeoffs of giving different permissions to different apps (ii) A large majority of users are expected to give that permission to the app under reasonable circumstances.
If an average user does not understand the tradeoffs of giving permissions to an app, then the operating system may as well do it on behalf of the user. I think this is a common problem since an average user probably clicks arbitrarily on the permissions dialog.
Similarly, if a permission is perceived to be not useful enough by most of the users, then there is no point in even having that in the ecosystem.
This is the crux of the problem that gbl08ma isn't realizing.
"User choice is what all of this boils down to, really. Android used to give me the choice of being slightly insecure in exchange for having more powerful and innovative features in the apps I install..."
You're dead on about the average user. Watch someone install and app, and less than a second is spent looking at the permissions.
Google's solution makes sense for their platform, not for power users. Leaving security up to users will result in insecure devices, increasing support costs as well as denigrating the brand.
If people are going to do things like financial transactions shudder on their phone, then the platform has to be rock-solid secure. That leaves those who might know and do better with their devices with less options.
Is it really that bad to do financial things on one’s phone? I would be pretty annoyed if I had to fire up a browser tab on my desktop/laptop any time I wanted to look over the transactions on my CCs and bank account.
Lile the article says, the Google Play Store makes it difficult for newer developers to get established. To get your app featured, you need to meet a whole host of design/accessibility/localization/etc requirements that pretty much make it impossible for small companies to get on the list--they simply don't have enough developer time to make sure that every button in their app has flashy touch feedback or to make sure their app is supported in Zimbabwe.
That said, I don't really feel that oppressed as an app developer. I think Google has done more good than bad here
Here people is complaining about Google bad policies..but have you ever seen/read/experienced changes in iOS ecosystem? All the new SDK versions must support newer devices while deprecating old versions of iOS.
At least, you pay a fee of 25$ and it's on you (or Google). Paying 99$/year and still experiencing some strong frustration at each newer release and change is much more for fetishism
Seeing that the newest phone that doesn’t support the latest version of iOS was released in 2012, I don’t see a problem with Apple deprecating older versions of iOS.
80% of all iOS devices are on iOS 12. An additional 12% are on iOS 11. Any device that can run iOS 11 can also run iOS 12.
By not supporting older devices, you are missing out on at most 8% of the iOS population. But even some percentage of those are able to update to iOS 12.
To target anything older than the 5s means you also have to target 32 bit processors. How much time are you going to spend targeting such a small user base?
Besides, if you have an older version already in the App Store, they can download “the last compatible version”.
You'd better believe there are older devices out there, and people would use the app store with them, iff the app store would only show you apps (or versions of apps) that still run on your device.
It is frustrating trying to get games on an old iPad for the kids.
Sure they can. If there was a version of the app that was submitted that’s compatible with their device, when they try to download it, it will ask them do they want to download “the last compatible version”.
I’ve done that with my first gen iPad as late as last year to download a few streaming apps like Netflix, Hulu, and Plex.
I have the iPhone 3G somewhere in the basement. For years, it has been a paperweight, it couldn't download anything from the App Store, including apps that originally were compatible. It even lost some capabilities it originally had out of the box, for example it could not sync contacts with Google anymore.
The last compatible download feature doesn’t work on my 1st gen iPod touch running iOS 3, but it does work on my iPad running iOS 5. I’m not sure about iOS 4.
So does that mean you also support 3.5” screens? If you want to support older devices that can’t run iOS 12 but have the same screen size as a supported device then you limit support to the 5 and the poorly selling 5c.
How far down the rabbit hole do you want to go? The 4s? The 4? The 3GS? The 3G? The original iphone?
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.
Legacy baggage also comes at the cost of performance, which in the case of mobile devices, means reduced battery life.
As an app developer, it's immensely frustrating to have to keep updating apps to stay on top of the latest SDK.
As a mobile user, I delete apps that get flagged up as battery hogs.
So that leaves me with a fairly simple choice, and I keep stuff updated if I expect anyone to keep using it, and if I abandon it, I shouldn't be surprised when my users do the same.
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.
Arguably the pros of just making security the users problem outweigh the cons of trying to protect the foolish from themselves. The desktop ecosystem for all its security problems is rather vivid
We are currently struggling with firebase messaging in a multi million user android app. Receiving lots of quota errors which are preventing push notifications to work properly. There is contact support with the firebase team, but there is no solution. I learned that the firebase infrastructure is shared with other developers. If one developer is maximizing load on the system it affects others.
The fact that you basically have no alternative to firebase fcm is really a pita. Each new version of Android makes it more restrictive. I wouldn't be surprised if in 2 years from now every app needs to have buttons with a predefined colour and fontsize
Security on Android is a joke. Google may shut down completely legitimate developers' accounts and remove useful permissions, yet they will still allow malicious apps like Cheetah Mobile's Ram Booster to be in top 10 most downloaded apps of the Play Store...
case in point: the MalwareBytes app is no longer allowed to access SMS message info, so it cannot examine links in SMS messages.
so there's a legit security app which can no longer function as effectively as it did before the Google Play Store eliminated its access to the SMS permission.
They can also blow you off overnight by mistake but whoops it's too late. At one time I had around 25,000 users on my app then a hiccup landed me back at 2 users. As a developer you have no rights. But at least they don't charge $100 a year like apple who can also randomly kill your app by mistake easily as well.
In fairness, access to features such as call logs and clipboard are too easily abused. I think that most users downloading apps from the Play Store have the expectation that Google is taking care of their privacy. As the author mentioned, advanced users can still sideload any non-approved apps they want, and as advanced users they should understand any security implications.
The point I do agree on is that the platform itself is becoming far too locked down, and the example of "Imagine if the online banking of my bank refused to open on my desktop because it knows I know the password for the administrator account" is a valid one and shows just how crazy it's getting.
Speaking of ridiculous, Android and banking, just yesterday I was browsing my transactions and wanted to send a screenshot of one to my wife. As it turns out, you cannot make screenshots of banking apps. Because "security".
Good thing criminals don’t have access to a camera or other device to take pictures of the screen. How does this stuff not get laughed out of the meeting when suggested?
Screenshots are saved to the sd card, where every app has complete access. Apps can specify certain UI safety features, like preventing clicks through overlaid UI elements or preventing screenshots. Blame the app if you want. There isn't some blanket policy in the OS that identifies banking apps and prevents screenshots.
If you make something like this possible, apps will use it. My problem is both with the app using this malfeature, and with the system providing it with no way for me (phone's owner and user) to override it.
Publishers often refer to copying they don't approve of as “piracy.” In this way, they imply that it is ethically equivalent to attacking ships on the high seas, kidnapping and murdering the people on them. Based on such propaganda, they have procured laws in most of the world to forbid copying in most (or sometimes all) circumstances. (They are still pressuring to make these prohibitions more complete.)
If you don't believe that copying not approved by the publisher is just like kidnapping and murder, you might prefer not to use the word “piracy” to describe it. Neutral terms such as “unauthorized copying” (or “prohibited copying” for the situation where it is illegal) are available for use instead. Some of us might even prefer to use a positive term such as “sharing information with your neighbor.”
A US judge, presiding over a trial for copyright infringement, recognized that “piracy” and “theft” are smear words.
In my experience very few people can say that. With all of the apps (games, line of business apps, audio visual apps) I've been involved with 90% of the sales/installs were iOS and 10% Android. IMO Android is rarely worth supporting for most apps. Not to mention huge piracy rates.
This is the underrated "why iPhone" answer most people overlook.
An iPhone may be more "locked down" than an Android equivalent in terms of what you can install, but when the App store is so robust, you really don't feel any pain from the walled garden.
An iPhone user doesn't need to side load a bunch of software to get the job done -- the App store has high quality tools for 99% of use cases and most are available for a couple bucks.
a GPS nit: the Google Play Store's "timed publishing" feature lets you accumulate changes to your app's store page hours or days in advance of an update and then click a "Go Live" when you actually want to publish that update and make those changes publicly visible.
but apparently it's not quite atomic. the Timed Publishing documentation notes say: If you ... add release notes to your app’s “What’s new in this release?” section while you're in timed publishing mode, they'll be published immediately.
that's so confusing! if I want to update release notes about a new release I'm going to make live soon, why would I want them to be published immediately? huh?
There are just so many apps demanding access to your clipboard, WiFi configuration and other stuff for no valid reason I'm actually glad to see Google is doing something. The only part that seems annoying is messing with what and how can apps access on the external storage. The μSD card and the OTG-attached thumb drive are exactly the places where I store content like audio, video, ebook, documents and other files, I use them the same way I use my laptop hard drive, having to grant root rights to an app every time I want to perform an operation on these files feels annoying and weird.
While I understand the complaint about google eliminating entire classes of apps, I have to say that I'm finding it extremely difficult to have any sympathy whatsoever for the OP: he's effectively complaining that software requires maintenance, which is something that has always been true and every single one of us learned about project lifecycle management in our engineering management or equivalent classes; as time goes on the effort towards maintaining any piece of software tends to overcome the effort of having it created in the first place.
Personally, I really hope that Librem 5 won't flop. While I don't see it going mainstream, at least it could provide a mobile platform for technically minded users.
I also think efforts like Fairphone are also promising. Android does provide a nice solid base to build on top of. What's missing is a community effort we see around Linux to build a completely open platform on top of what's already available.
Android becomes more hostile to power users with every update. That's why I will never buy a phone I can't root. The very fact users have to pick a particular phone and then jump through hoops for the privilege is ridiculous.
As an Android user it feels like Android is getting more and more IOS like with every new release. Seriously I wouldn't be surprised if they locked down the filesystem (like IOS) in the name of security.
Maybe they'll start mandating a half-decent device security update policy in the name of security. I've had a few too many two year old devices stop getting updates.
not disagreeing, but i'm skeptical android will ever attain iOS's level of fan-appreciation or polish. if becoming like iOS is their goal, Google is probably playing a losing game.
The tools and IDE are quite good (they need a lot of RAM though), the deployment is easy, the development workflow simple enough and the devices are easy (and cheap) to come by. Even the Play Store console is not catastrophic.
A contrario from Youtube, you can get questions answered by Google, and the dev communities are quite large.
The API changes are known 6 months in advance, which is good enough, for most cases. And you get them usually only when targeting the new SDK version (except for Android Q... why?!?)
What I don't like though, is their abysmal NDK support (notably compared to iOS), the removal of use-cases (just use SAF, right? wifi?), but mostly the APIs that are never finished and always buggy (Audio API for example), and the impossibility to send patches to fix those bugs.
Finally, the Play Store Console is so-so, but the user-facing part is quite nice.