3 ms·

Probably a silly question, but since Android is OSS, what specifically prevents parties other than Google from adding "first class" language support? Does Goog

Probably a silly question, but since Android is OSS, what specifically prevents parties other than Google from adding "first class" language support? Does Google not accept (major) external contributions to the build toolchains? Is it the official documentation that's getting rewritten for Kotlin? Or is Google releasing Kotlin-ified wrappers for the Android APIs? Maybe I don't fully understand what new privileges Kotlin is getting.

zanny 9y ago
The Android APIs are all pretty much Java, so you need a JVM langauge to use them. The NDK requires a Java shim layer, and then you end up writing Java anyway to use most platform features. Google obviously won't support competing first class toolkits on Android. You can already use most JVM languages on Android as is, especially since the switch to OpenJDK. Giving Kotlin first class support is just adding it to their own in house tools. You can already use Scala, for example, if you want. Qt is a great example of how hard it is to bring a 3rd party language to Android. Qt app on Android cannot use native theme, cannot interact with most other apps, don't behave like other apps perfectly, and can be a mess to deploy because of how many Qt libraries you need to bundle in. Google doesn't actively stop you from shipping a Qt app on Android, but it took the Qt company a lot of work to get support where it is now, and its still far from seamless (if you want an example of a great Qt on Android app, try Subsurface Mobile that uses the Kirigami widget set).
izacus 9y ago
Kotlin was supported way before this announcement. Scala, Clojure, etc. worked to some extent as well. This is more of a political thing.
pas 9y ago
Kotlin is getting Google's blessing. Mentioned in Google's Android development docs and tutorials. That's the magic sauce. Since Kotlin is veeery close to Java, it was already working well on Android. It targets the JVM of Java6, so if you compile your Kotlin android app, it looks like a regular thing compiled from Android Studio. Regular bytecode, that then gets recompiled by dx (dalvik compiler into .dex bytecode - see also https://softwareengineering.stackexchange.com/questions/285235/is-art-an-installation-process-or-an-os-or-a-virtual-machine https://softwareengineering.stackexchange.com/questions/2852... ) And yes, adding new things to Android is ... problematic, because Google doesn't accept pull requests. (It accepts bug reports, and sometimes patches of bugs.) And of course you can propose a big patch adding [see https://source.android.com/source/life-of-a-patch https://source.android.com/source/life-of-a-patch ] .. let's say Swift to the Android Platform, but the project owners are Google employees, and the community cannot really influence what gets accepted. [ https://source.android.com/source/roles https://source.android.com/source/roles ]
- bogidon 9y ago
  Got it. It's a shame that Google has been moving Android in a more proprietary direction. Are there any notable Android forks that are more progressive about supporting new languages? If so, is their market share consequential?
  - pas 9y ago
    https://en.wikipedia.org/wiki/List_of_custom_Android_firmware https://en.wikipedia.org/wiki/List_of_custom_Android_firmwar... Replicant is the most "open". Also, it's not hard to package all the stuff a language needs and put it into an APK. It's just messy and there are a lot of "edge cases" and things to work out (like the problem of interacting with the Platform, you'd need to call into a "Java" interface from your language, you'd need to run your app inside ART/Dalvik, maybe fork - https://stackoverflow.com/questions/39006044/repeatedly-fork-android-app-process-where-child-can-access-system-services-via https://stackoverflow.com/questions/39006044/repeatedly-fork... ). And so if you spend half a year just getting something to run, and on the next Android version Google makes a change, and bamm, you might get left in the cold, because security or whatever.
lnanek2 9y ago
Ever since amazon managed to making a competing Android release with everything Google stripped out, the SDK licenses have intentionally been made very onerous, it's become nearly impossible to get your own SDK extensions put into the SDK manager, and Google has been moving as much as possible into private extensions like Google Play Services. They even strong armed cell companies into breaking contracts with GPS provider replacements, like SkyHook. I worked for an OEM at the time Google kicked us out of the SDK manager update list, so am familiar with the about face. If you do try to make your own toolkit, you'll have to fight very hard to do so. JetBrains writes IDEs and licensed Android Studio to Google, so there's no harm in Google helping them, but anyone else would be in for a lot of pain.

zanny 9y ago

The Android APIs are all pretty much Java, so you need a JVM langauge to use them. The NDK requires a Java shim layer, and then you end up writing Java anyway to use most platform features. Google obviously won't support competing first class toolkits on Android. You can already use most JVM languages on Android as is, especially since the switch to OpenJDK. Giving Kotlin first class support is just adding it to their own in house tools. You can already use Scala, for example, if you want. Qt is a great example of how hard it is to bring a 3rd party language to Android. Qt app on Android cannot use native theme, cannot interact with most other apps, don't behave like other apps perfectly, and can be a mess to deploy because of how many Qt libraries you need to bundle in. Google doesn't actively stop you from shipping a Qt app on Android, but it took the Qt company a lot of work to get support where it is now, and its still far from seamless (if you want an example of a great Qt on Android app, try Subsurface Mobile that uses the Kirigami widget set).

izacus 9y ago

Kotlin was supported way before this announcement. Scala, Clojure, etc. worked to some extent as well. This is more of a political thing.

pas 9y ago

Kotlin is getting Google's blessing. Mentioned in Google's Android development docs and tutorials. That's the magic sauce. Since Kotlin is veeery close to Java, it was already working well on Android. It targets the JVM of Java6, so if you compile your Kotlin android app, it looks like a regular thing compiled from Android Studio. Regular bytecode, that then gets recompiled by dx (dalvik compiler into .dex bytecode - see also https://softwareengineering.stackexchange.com/questions/285235/is-art-an-installation-process-or-an-os-or-a-virtual-machine https://softwareengineering.stackexchange.com/questions/2852... ) And yes, adding new things to Android is ... problematic, because Google doesn't accept pull requests. (It accepts bug reports, and sometimes patches of bugs.) And of course you can propose a big patch adding [see https://source.android.com/source/life-of-a-patch https://source.android.com/source/life-of-a-patch ] .. let's say Swift to the Android Platform, but the project owners are Google employees, and the community cannot really influence what gets accepted. [ https://source.android.com/source/roles https://source.android.com/source/roles ]

bogidon 9y ago
Got it. It's a shame that Google has been moving Android in a more proprietary direction. Are there any notable Android forks that are more progressive about supporting new languages? If so, is their market share consequential?
- pas 9y ago
  https://en.wikipedia.org/wiki/List_of_custom_Android_firmware https://en.wikipedia.org/wiki/List_of_custom_Android_firmwar... Replicant is the most "open". Also, it's not hard to package all the stuff a language needs and put it into an APK. It's just messy and there are a lot of "edge cases" and things to work out (like the problem of interacting with the Platform, you'd need to call into a "Java" interface from your language, you'd need to run your app inside ART/Dalvik, maybe fork - https://stackoverflow.com/questions/39006044/repeatedly-fork-android-app-process-where-child-can-access-system-services-via https://stackoverflow.com/questions/39006044/repeatedly-fork... ). And so if you spend half a year just getting something to run, and on the next Android version Google makes a change, and bamm, you might get left in the cold, because security or whatever.

lnanek2 9y ago

Ever since amazon managed to making a competing Android release with everything Google stripped out, the SDK licenses have intentionally been made very onerous, it's become nearly impossible to get your own SDK extensions put into the SDK manager, and Google has been moving as much as possible into private extensions like Google Play Services. They even strong armed cell companies into breaking contracts with GPS provider replacements, like SkyHook. I worked for an OEM at the time Google kicked us out of the SDK manager update list, so am familiar with the about face. If you do try to make your own toolkit, you'll have to fight very hard to do so. JetBrains writes IDEs and licensed Android Studio to Google, so there's no harm in Google helping them, but anyone else would be in for a lot of pain.