
Developing for Android is like being a demonetized YouTuber - gbl08ma
https://gbl08ma.com/developing-for-android-is-like-being-a-demonetized-youtuber/
======
jbk
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.

~~~
pcwalton
> 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.

~~~
WorldMaker
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.

~~~
pcwalton
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.

~~~
WorldMaker
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?)

------
fattire
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...](https://developer.android.com/guide/topics/providers/document-
provider)

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.

Watch this little-seen video:

[https://www.youtube.com/watch?v=C28pvd2plBA](https://www.youtube.com/watch?v=C28pvd2plBA)

~~~
jbk
> 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.

~~~
iggldiggl
> 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](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.

------
Mindless2112
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.

~~~
on_and_off
>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 target a recent
API level.

~~~
paulryanrogers
> 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.

~~~
on_and_off
>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.

------
fencepost
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.

Edit: removed disparagement of Windows Phone apps

~~~
ocdtrekkie
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.

~~~
arebours
Totally agree. It works pretty well on iOS with APFS so multiple file copies
occupy the same storage space. Not sure about Android though.

------
xrd
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 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.

~~~
gbl08ma
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.

~~~
xrd
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.

------
vgoh1
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.

------
eh78ssxv2f
> "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.

~~~
redleggedfrog
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.

It's the price of maturity.

~~~
kitsunesoba
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.

~~~
UncleMeat
No. Mobile operating systems are considerably safer than desktop operating
systems.

------
briga
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

------
IloveHN84
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

~~~
cm2187
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.

~~~
indigo945
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.

~~~
oarsinsync
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.

------
holoduke
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

------
agluszak
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...

~~~
HillaryBriss
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.

------
shams93
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.

------
iliketosleep
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.

~~~
TeMPOraL
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".

~~~
stallmanite
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?

~~~
otalp
I think the intention is that someone with malicious code placed in the users
device still won't be able to access bank details

------
sadris
I had 90% piracy rate on Android when I did it years ago. Gave up and didn't
look back.

~~~
wetpaws
Anecdotally, 75% of my sales are on Android and only 25% on iOS.

~~~
andysinclair
Interesting...is the app exactly the same on both platforms and the same price
(assuming it is paid)?

I am interested to see if it's worth porting some of my iOS apps to Android.

~~~
wetpaws
App functionality and price are identical. It's a very niche app with
dedicated community though, so piracy is not such a big factor.

------
HillaryBriss
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._

[https://support.google.com/googleplay/android-
developer/answ...](https://support.google.com/googleplay/android-
developer/answer/6334282?hl=en)

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?

------
qwerty456127
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.

------
lagadu
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.

------
yogthos
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.

------
alanh
I wrote this 10 years ago, and it’s as true as ever: Google signals every day
that they don’t care about people, just money.

[https://alanhogan.com/arrogance-of-google](https://alanhogan.com/arrogance-
of-google)

------
Causality1
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.

------
bibyte
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.

~~~
justryry
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.

------
dhbradshaw
We need a viable 3rd alternative.

