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