[yourapostasy]

Indeed, Apple has the high-tech equivalent of "dragon sickness", in a nod to Tolkien.

Google has a long road ahead of it, but it looks like they have the right pieces in place where I see small, incremental improvements each year, so maybe they're the tortoise. Milestones on that long road are like migrate away from Dalvik, fix business model / monetization issues with the Android marketplace, switch to vector-based canvas blitting, rationalize API support for different manufacturer-added features, and so on. What would be interesting is if they steal Apple's developer thunder by capitalizing upon open source and their in-house build system, and out-flank Apple's developer mindshare, by creating a developer-oriented ecosystem.

Imagine if you could hook up your own Docker container that Google's build infrastructure then taps to build your Android app...but all the open source your app depends upon are in their build infrastructure, with near-instant feedback on build and CI problems of the open source bits operating at a massive scale. App development shifts to a posture where open source frameworks/modules/libraries that already power a lot of software are orders of magnitude more convenient to develop under this ecosystem, and the agility/efficiency of all those Android developers coalescing around common open source components online in a single build and CI ecosystem far outstrips Apple-based developers stuck with XCode and their own person-oriented toolchains. Apple has nothing in the pipeline remotely like that kind of ecosystem. Google would also get big data-based insight into phone app development trends in real-time that Apple could only dream about. Google's phone app development OODA loop would tighten considerably smaller than Apple's.

I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.

[pjmlp]

All of that has zero meaning given Google's reluctance to fix Android updates.

The majority of the Android users is yet to experience any of those improvements.

[bpodgursky]

Um, Google has actually worked very hard to de-couple parts of Android into separate apps, so that those apps can update without a carrier-managed total OS upgrade.

This has arguably negative impacts on Android's utility as a non-Google OS, but there's no question that this strategy was to help push updates to users faster.

[pjmlp]

Making it a legal requirement, as they already do with so many others for OEMs to access Google services and the Play Store, would be the solution.

No need for smoke and mirrors games regarding decoupling Android.

[AsyncAwait]

I imagine it's not that easy to add something like this now, without huge OEM backslash. If it was there from the start, maybe it would work.

[Nullabillity]

> Imagine if you could hook up your own Docker container that Google's build infrastructure then taps to build your Android app...but all the open source your app depends upon are in their build infrastructure, with near-instant feedback on build and CI problems of the open source bits operating at a massive scale.

But... why? Gradle already does a good job eliminating works-on-my-machine-isms, that sounds like cloud-for-the-sake-of-cloud.

> I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.

But... why?

[yourapostasy]

> Gradle already does a good job eliminating works-on-my-machine-isms, that sounds like cloud-for-the-sake-of-cloud.

Github for build and continuous delivery/deployment/integration; extremely distributed build. Today an app developer pulls down the latest version of an open source library and building against it, then files any integration issues against the library's ticketing system. Google's system allows the library developer to build a version, then find everyone whose apps that use their library break because of the new proposed version. It vastly speeds up the delivery cycle and increases robustness between builds of all your dependencies and your app.

A lot of people really like the re-factoring and IntelliSense features in Visual Studio, but hate working under Windows. The new Linux compatibility push under Windows when it matures may accomplish the same as making Linux a first-class citizen in Visual Studio.

Google trying to further develop Dalvik/Android Runtime for Android seems to me eerily like Sun developing further generations of SPARC. Google would have to put up a really big war chest to continually find and address all the edge cases to sustain a process virtual machine going forward into the future, and I'm not clear where the value proposition lies in doing so, rather than settling upon an existing process virtual machine with more developers working upon it. I suspect Google does this because adopting someone else's process virtual machine, even an open sourced one, risks that someone else somehow strategically chokepointing Android development in the future with incompatible changes.

[Nullabillity]

> Google's system allows the library developer to build a version, then find everyone whose apps that use their library break because of the new proposed version.

That assumes that library authors can see the code of dependent applications. Ehhh...

> It vastly speeds up the delivery cycle and increases robustness between builds of all your dependencies and your app.

Presumably by breaking repeatable builds? I certainly don't want it to replace libraries without my knowledge, and that's the only part where I can see it possible "speeding up the delivery cycle".

Oh, yeah, Gradle can do that anyway with -SNAPSHOT dependencies.

> A lot of people really like the re-factoring and IntelliSense features in Visual Studio, but hate working under Windows. The new Linux compatibility push under Windows when it matures may accomplish the same as making Linux a first-class citizen in Visual Studio.

Tried IntelliJ/Android Studio? Especially considering that ReSharper, which is more or less a port of IJ's refactoring, is usually considered a must-have add-on for VS.

> Google trying to further develop Dalvik/Android Runtime for Android seems to me eerily like Sun developing further generations of SPARC. Google would have to put up a really big war chest to continually find and address all the edge cases to sustain a process virtual machine going forward into the future, and I'm not clear where the value proposition lies in doing so, rather than settling upon an existing process virtual machine with more developers working upon it.

Sounds like migrating to OpenJDK would be a much more reasonable path in that case, since it wouldn't mean starting over in third-party application support.