
Android Pie SDK is now more Kotlin-friendly - ingve
https://android-developers.googleblog.com/2018/08/android-pie-sdk-is-now-more-kotlin.html
======
ilove_banh_mi
I'm giving up on upgrading my apps for Android. The releases are dividing the
market every single year and consequently steadily eroding sales.

On the one hand Google's Nexus was released 3 years ago and is now obsolete;
on the other hand Apple's iPhone 5s was released 5 years ago and gets to run
iOS 12. On top of this, the vast majority of my paying customers use iOS, not
Android (a variety of lifestyle and reference apps).

This is disappointing; I can't financially justify further development for
Android.

Oreo, released in 2017, is at a pitiful 12% installation share. [1]

[1]
[https://developer.android.com/about/dashboards/](https://developer.android.com/about/dashboards/)

~~~
izacus
The only way you get only 12% installation share on Oreo is if you're
targeting Indian continent with Hindi localisation.

For a western world targeted app, the stats are around 35-40% for Oreo right
now. So you seem to be deliberately ignoring your own installation stats just
to complain - the dashboard you're posted is pretty much not relevant for
anyone but multi-million installation apps like Facebook. In other words, if
you ignore Oreo users, you're ignoring more (wealthy) people than there are
owners of iPhone X.

Also I simply fail to see how releases are dividing the market, considering
the fact that for most apps new releases don't really require nearly as much
maintenance as they do for new iOS releses. Granted, Oreo and P require a bit
of work for apps that run in the background, but vast majority of the apps
will just work if they implemented proper privacy respecting permissions since
the release of 6.0 in 2015.

Just to be clear - I don't mind if you give up Android development (good
riddance actually, way too much toxic people in the community), but PLEASE do
not spread misinformation.

~~~
knuththetruth
Conflating a very real and common concern (fragmentation in the android
market) with “toxicity” seems a bit excessive.

~~~
izacus
The OP wrote a post which has nothing to do with article at hand and is
deliberately misleading. I think the term is fitting - it's complaining for
complaining's sake. And that's toxic in a community. Compare it with the
frontend developers - dealing with Android fragmentation is signficantly
easier than dealing with browser and device fragmentation as a web
developer... and those topics aren't full of people complaining.

~~~
pawadu
These negative posts always show up on top when something even remotely
positive about android is posted.

------
izacus
It's rather sad to see how none of the comments here are actually commenting
on Android P/Kotlin friendliness.

(Which is available to all Android developers, not only those targeting P -
the nullability headers will give you all the benefits even if your app
supports older Androids.)

~~~
akerro
I actually wish there was an Android release targeted for Dart support with
more Dart promotion. Since this year Java got a lot more powers, they're
moving the language and ecosystem much faster, functional targets for Java 12
(will be released in 2019) contain almost everything Kotlin has now.

~~~
jillesvangurp
Given the legal wrangling with Oracle, I don't think they will be eager to
support Java. However, Kotlin has a native compiler (llvm based) as well. You
can target Android/IOS with it as well as Wasm or simple desktop/server
executables. So, the smart move would be to deemphasize Dart, move flutter on
top of Kotlin native/llvm (and why not expose it to other languages as well;
e.g. swift). Then they cab move the entire Android ecosystem on top of llvm
and provide some level of continuity for people with Kotlin/Android codebases.

The main challenge here is the API gap between the old java 6 APIs that
underly the current Android API that won't be there on native Kotlin. Flutter
solves that problem.

~~~
akerro
Do you have anything specific in mind about Oracle-Java? They opensource a lot
in the last two years, OracleJava is basically 99.9% openJDK now, the main JDK
is OpenJDK, Flight Recorder is open-source, graalVM is GPL2...

~~~
jillesvangurp
The problems between oracle and google are related to copyright and APIs.
Androids OSS java bits are licensed differently(Apache license if I recall
correctly) and technically a partially API compatible implementation of Java
about 10 years ago with lots of Google specific additions and some code
inherited from IBMs harmony project.

In any case, compiler technology has moved forward a lot and as Apple has been
showing with IOS and Swift, you can do some pretty decent app ecosystem around
native code without having to expose your developers to doing C/C++.

------
drb91
I really wish they used version numbers rather than names so i can tell
there’s a new version of android. I thought this was a just a distro for
raspberry pis.

It’s pretty clear in the article though, no sweat :)

~~~
simcop2387
They sort of do, the first letter of the new name is always the next one in
the english alphabet. That said, they do have version numbers but almost no
marketing uses them with or instead of the codenames.

Kitkat Lolipop Marshmallow

[https://en.wikipedia.org/wiki/Android_version_history](https://en.wikipedia.org/wiki/Android_version_history)

~~~
the_trapper
The stupid thing is that these code names sometimes span multiple versions of
Android and even API levels making it all even more of a clusterfuck of a
platform. My suspicion is that they do this to hide all of the fragmentation
and pretend that more handsets are up to date than they actually are.

~~~
altair8800
What's the difference between named releases and Apple's semantic versioning?
Both create groupings that hide fragmentation.

~~~
sjwright
What fragmentation is being hidden behind Apple's iOS version numbers?

~~~
altair8800
I should have said _can_ hide fragmentation.

------
sidlls
I get why developers would be interested in this, but it doesn't feel like
something that moves the needle. It's a decent first step if the end goal is
to promote Kotlin to the place Java occupies in Android development and (at
the same time) fix some of the issues with the inconsistent and over-
engineered APIs.

