Will Google Betray and Kill Android

Android is the most popular platform in the world that powers more than two billion devices. It’s a massive and indisputable success.

Despite all that, I suspect that the future of Android might be not as bright as its past.

My first troubling thoughts originated about a year ago. Back then Google announced that Kotlin programming language will be officially supported for Android development. This announcement gave rise to a wave of enthusiasm among Android developers, but I couldn’t join this wave.

I tried to understand how Kotlin will benefit entities with a stake in Android, but all I could see is further fragmentation of an already fragmented and (let’s be honest here) messy development ecosystem.

I had hoped that Google will share with us additional information, but they didn’t. They just said that Kotlin is officially supported because it is “better”, concentrated their PR efforts to promote it and added Kotlin samples to official documentation.

The most straightforward and obvious question — what’s the roadmap for Java on Android? — remained unanswered.

How I came to write this post:

At some point I decided to share my troubling thoughts with the readers of this blog. So, I wrote an article that showed how quantitative estimation indicates that adoption of Kotlin can be counter productive. Surprisingly, that post attracted quite a bit of attention and received lots of feedback.

I analyzed the community feedback and noted that there seems to be a widespread misconception as to why JetBrains invented and promotes Kotlin. Many developers concentrated on technical aspects, forgetting the fact that JetBrains wouldn’t invest such a huge amount of resources into Kotlin without clear business model. No problem, I wrote about that too.

The next step would be to share what I believed to be the reasons Google adopted Kotlin, but I got stuck for several months.

See, my initial hypothesis was that Google adopted Kotlin due to ongoing legal dispute with Oracle concerning use of Java in Android. I thought that Kotlin can help Google in getting Oracle off their back. However, this hypothesis fell apart following the basic review of technical and legal aspects of this lawsuit.

It was only after I studied the Oracle vs. Google lawsuit in details that I circled back to the same idea.

Well, not exactly the same idea. A much more frightening version of it. The “small” hypothesis that I previously had — Google adopted Kotlin and hurts us to get a better hand in the lawsuit against Oracle — grew to an apocalyptic scale.

In this post I will share this updated hypothesis with you.

Keep in mind though that this post is a third one in a series. It builds upon the content of my first article that explained why Google adopted Kotlin and the second article that summarized the Oracle vs. Google lawsuit. I’m going to assume that you already read the first two articles in this series.


The disclaimers from both preceding posts apply here as well. In addition, you might want to put your tinfoil hat on.

Google negotiated Java license with Oracle:

One astonishingly interesting piece of evidence in Oracle vs. Google lawsuit is this email from software engineer Tim Lindholm to Andy “Father of Android” Rubin:

Allow me to assist you in interpretation of what’s actually going on here.

That said, Alan Eustace said that the threat of moving off Java hit Safra Katz hard. We think there is a value in the negotiation to put forward our most credible alternative, the goal being to get better terms and price for Java.

It looks to us that Obj-C provides the most credible alternative in this context, which should not be confused with us thinking we should make the change. What we’re looking for from you is the reasons why you hate this idea, whether you think there’s anything we’ve missed in our understanding of the option.

Meet the participants: Alan Eustace, senior executive at Google; Safra Katz, senior executive at Oracle. The email is dated about six months after Oracle acquired Sun and about two months PRIOR to Oracle suing Google.

In my review of Oracle vs. Google lawsuit I mentioned that Google always knew that Java APIs were copyrighted and negotiated a license with Sun. Turns out that they also negotiated a license with Oracle after Sun’s acquisition.

Note how Google threatens Oracle to move off Java. They don’t really intend to do that, but they believe that such a threat can get them better terms and price for Java license. Keep this tactic in mind for now.

The part that draws the most attention in this email is this:

What we’ve actually been asked to do by (Larry and Sergey) is to investigate what technical alternatives exist to Java for Android and Chrome. We’ve been over a bunch of these, and think they all suck.

Software developer inside me immediately concentrates on the assertion that “Java alternatives for Android and Chrome suck”, but it’s actually the least interesting piece of information in this entire email.

When I explained why Google adopted Kotlin, I described an imaginary conversation between a mid-level manager and an executive at Google concerning Kotlin’s adoption. I used it to show you that the claims that Google adopted Kotlin because it’s “better” or “community asked for it” are ridiculous. I also stated that Kotlin adoption probably required approval from Google’s top level executives, or even the board of directors.

Now you see that Larry Page and Sergey Brin, Google founders, were directly involved with the issue of Java in Android even before Oracle sued Google. Today, when Google is on the loosing end of a multi-billion lawsuit, I find it extremely improbable that anyone at Google would bring this topic up to discuss a “more concise programming language”.

We conclude that we need to negotiate a license for Java under the terms we need.

But, but, but… Google said for years that Java APIs weren’t copyrightable. They said that greedy Oracle sued them for no reason! Why would they conclude that they need to negotiate a license for Java then?

Well, either Google was eager to donate hundreds of millions of dollars to Oracle, or they lied to us and to the court. I think that one of these options is much more probable than the other.

This statement (alongside additional evidence for willful infringement) also flies in the face of “experts” who said that copyrightability of APIs will “end the software industry as we know it today”. Turns out that APIs had been copyrightable long before Oracle sued Google and software industry as we know it today is fine with that.

But there is still one additional very surprising aspect to this email. Well, more precisely, what’s surprising is that one aspect is completely missing from this email.


At the time Tim Lindholm wrote the aforementioned email OpenJDK was already three years old.

Google could just take this open source implementation of Java APIs and integrate it into Android. Instead, top Google executives searched for alternatives to Java and tried to manipulate Oracle executives into giving them a discount. OpenJDK wasn’t even mentioned as an option in this email.

Why Google negotiated a license with Oracle instead of simply using Oracle’s own open source OpenJDK for free?

Well, OpenJDK is licensed under GPL + Classpath Exception while Android is mostly licensed under Apache. Contrary to a common belief, integration of OpenJDK into Android wouldn’t help Google. Google executives knew this perfectly well, therefore this wasn’t even brought up as an option in this discussion.

However, OpenJDK was introduced into Android about six years later with the release of Android Nougat. What caused Google to change their mind?

Well, neither OpenJDK’s nor Android’s licenses changed, so it’s not that OpenJDK became a safer option for Google. It’s just that by then Google already failed to convince US Court of Appeals for the Federal Circuit to make an exception and deem Java APIs non-copyrightable and Supreme Court declined Google’s petition to hear the case. In comparison to this trouble the risks associated with OpenJDK weren’t that big anymore and Google decided to integrate it.

But make no mistake – there are still huge risks to Google associated with OpenJDK in Android.

First of all, Oracle can win the lawsuit and get an injunction that will apply to post-Nougat Android versions despite the fact that they use OpenJDK. Even if Google will be able to convince the court that a separate trial is required to determine post-Nougat damages, Oracle will most probably not back off.

While Google does have a chance to get away with OpenJDK in Android, it wouldn’t bet billions of dollars and control over the future of Android on this hope alone.

Enter Kotlin.

How Kotlin helps Google:

Let’s start with the less probable explanation.

Remember the tactics that Google used during Java license negotiations with Oracle in 2010? They tried to demonstrate their willingness to migrate to a different technology in a hope that Oracle will give them a discount. Today we know that it didn’t work as expected back then.

However, it is not improbable that Google might try the same approach again.

If Google already decided to settle with Oracle, they might have initiated this Kotlin hype to demonstrate that they are serious this time. That could be a good leverage in settlement talks. Maybe even the only leverage because Google seems to be in a bad shape as far as this lawsuit is concerned.

I personally think that the probability of this explanation to be correct is extremely low. Oracle clearly stated that they want a fair share of Android, but everything Google has ever done with Android indicates that they won’t let anyone in. It looks like the positions of Oracle and Google are too much apart for a settlement to be a viable option.

Even if Kotlin is just a settlement talks leverage, Google will still need to demonstrate that Kotlin can assist in migration off Java.

Unfortunately for Google, as of today, Kotlin on Android is just a thin wrapper around Java. It’s still compiled into Java bytecode and its APIs use the disputed Java APIs under the hood. Looks like Kotlin can’t really help Google get rid of OpenJDK in Android.


Theoretically, Kotlin APIs can be re-implemented to remove dependency on Java APIs in Android. If Java APIs won’t be used anymore, Google will be able to remove OpenJDK from Android.

Will Android drop support for Java applications after OpenJDK removal? I don’t think so.

Take Facebook for example. They probably crossed the line of one million lines of Java code in their codebase long time ago. Migration of such a mammoth to Kotlin will be extremely hard and long project that will cost millions. I don’t think Facebook will be up to that in the foreseeable future. Since it would be absolutely stupid to remove or even just break Facebook and other major apps, Google has no option but keep Java support.

After removal of OpenJDK, Andorid can work around missing implementations of Java APIs by transpiling Java to Kotlin before compilation or directly compiling to code that will use Kotlin APIs. Such a delegation should be not much more difficult than today’s Kotlin delegation to Java APIs.

So, here you have it – Google adopted Kotlin in order to remove the disputed Java APIs form Android platform.

Good for you Google! Too bad that there seems to be nothing but churn for Android ecosystem in all this.

Google’s doomsday scenario:

As far as I understand, if Oracle wins the lawsuit then, theoretically, they can get a share in Android regardless of whether it will continue to use Java APIs or not.

Oracle states that Google infringed their copyright and created a competing product that basically threw Java out of mobile market. Even if Google will remove the infringing part at this point, the court can still hold it responsible for the long term damage to Oracle’s core business. In such a case, Oracle might get a share of Android even if infringement will stop.

That would be a doomsday scenario for Google because Oracle will get a share in Android and Google wouldn’t be able to do anything about it.

Unless… there will be no more Android.


One of the most speculated topic in respect to Android is whether Google’s new and “secret” operating system named Fuchsia is actually intended to replace Android.

The implications of such an intent would be tremendous for Android ecosystem players, but Google doesn’t share any information with us. I myself and many other Android developers asked official Google representatives about Android and Fuchsia roadmaps, but, as far as I know, nobody ever got an answer to this question. So much for Google openness.

So, let me answer the biggest Android related question today: what the heck is Fuchsia?

Fuchsia is Google’s insurance strategy for doomsday outcome of Oracle vs. Google lawsuit. If all other Google’s responsibility avoidance tactics will fail and Oracle will get a share in Android ecosystem or profits, Google will kill Android and migrate to Fuchsia.

However, for Fuchsia to be able to replace Android, at least three preconditions must be met:

  1. Fuchsia must have a mature developers ecosystem with enough skilled developers.
  2. There must be devices that can actually run Fuchsia.
  3. Fuchsia must support Android applications.

I’m sure that replacing the most popular operating system in the world will take much more than just that. The reason I chose to concentrate on these three preconditions is that each one of them is mandatory and can take long time to achieve.

So, even if Google will decide to kill Android in favor of Fuchsia, we will still have several years because none of the above can be achieved in shorter time. Great.

Unless… Google is already working to satisfy these conditions today.


Flutter is Google’s new mobile development SDK that supports both Android and iOS. It’s written in a language called Dart which doesn’t use Java APIs under the hood.

Google recently started active Flutter promotion and it confused and even irritated many Android developers.

See, Google threw Kotlin at us less than a year ago and now they seem to promote this weird framework written in a weird language that no one uses. Needless to say that Google didn’t share any information about Flutter’s roadmap with the developers community.

Steve Yegge said this in his viral post Who will steal Android form Google:

And Google, not to be outdone by their competitors, responded by saying, “Oh yeah? Well you can’t compete with us, because we’re going to compete with us!” and they launched Flutter, which is — I am not making this up — a 100% serious Android development stack that competes with native Android, and whose existence the actual Android team simply refuses to acknowledge.

This piece precisely conveys the absurdity of the situation around Flutter. That said, I don’t think that Google indeed competes with itself.

So, let me answer another huge WTF question related to Android: why the heck Google created and promotes Flutter?

It’s not a secret that Flutter is also the official SDK for writing Fuchsia applications. Given the fact that Google will need an established ecosystem of skilled developers if they decide to kill Android in favor of Fuchsia one day, it makes sense to let Android developers get hands on experience ahead of time.

That’s what Flutter is all about – building developers ecosystem to support the potential migration to Fuchsia. You can check off that first precondition for killing Android.

Project Treble:

The official documentation for Google’s project Treble opens with this:

The Android 8.0 release includes Project Treble, a major re-architect of the Android OS framework designed to make it easier, faster, and less costly for manufacturers to update devices to a new version of Android. Treble is for all new devices launching with Android 8.0 and beyond (the new architecture is already running on the Developer Preview for Pixel phones).

So, Google invested a considerable effort to make it less costly for OEMs to update devices to new versions of Android. Wow, Google is so nice to these OEMs.

You already know what’s coming, right?

Indeed, I could explain you how Google screws OEMs on every opportunity. I could show you that the reason OEMs stop releasing updates for older devices has nothing to do with Treble. I could even show you that Treble is not really relevant to all this.

However, at this point I hope that you already learned the value of Google’s statements and will believe me when I say that Treble is not about helping OEMs.

Back to Fuchsia.

Android ecosystem suffers from the fragmentation problem. It’s not the fragmentation of internal development practices that we discussed in context of Flutter though. The fragmentation that I’m talking about here affects Android by itself and the hardware that runs it.

Each OEM takes the stock Android and changes it according to its needs. For example, OEM can decide to add its proprietary code that makes camera images super sharp. If the underlying hardware exposes special capabilities, OEMs can account for these as well in their special flavor of Android.

The problem with all this is that different Android versions become incompatible due to these changes. Samsung phones will not be able to run Pixel’s Android and vice-verso. This makes it impossible to switch to a different flavor of Android on a given device, let alone completely different operating system.

If Google would release Fuchsia with all this mess going on, there would be no devices to run it. It could take months or even years before Fuchsia would be properly supported by hardware manufacturers.

So, replacing one operating system with another operating system is extremely difficult task. Especially if the former operating system is the mess known as Android.

Luckily for Google, the fundamental theorem of software engineering states:

We can solve any problem by introducing an extra level of indirection.

It’s not immediately clear how “indirection” is related to project Treble, but recall that “indirection” is a synonym of “abstraction” in software engineering. Abstraction like in Hardware Abstraction Layer (HAL), which is what project Treble is.

So, project Treble is not about helping OEMs or caring about Android users. It’s all about making sure that hardware manufacturers standardize their platforms to make them ready for Fuchsia. I don’t know whether Google plans to actually push Fuchsia to devices that run Android. However, it is evident that they want mobile devices to support Fuchsia out of the box if and when it will launch.

I think it is safe to say that absolute majority of devices manufactured today already support Fuchsia.

At this point you might be inclined to point out to technical differences between Android and Fuchsia. These operating systems are indeed based on different technology stacks. However, I can assure you that Google has billions of reasons to make Fuchsia compatible with Android devices.

So you can check off that second precondition for killing Android from the list as well.

Android applications on Fuchsia:

To kill Android, Google will need to ensure that Fuchsia supports Android applications. I think it’s kind of self-evident and doesn’t need explanation.

I planned this section to be relatively long because I would need to explain how Fuchsia can actually support Android apps. I wanted to show that it’s not infeasible and that Google is probably already moving in this direction.

Luckily for me, there is no need in all this anymore. I can simply show you this tweet from about nine days ago:

Fuchsia Android ART

To be honest, I haven’t investigated this commit yet and I’m not completely sure that it is absolutely related to the question at hand. However, I estimate the probability of this being an unrelated coincidence to be very low.

Well, now you can check off the third and the last item from the above list of preconditions for killing Android.

When will Google kill Android:

There are lots of voices in Android community that downplay the situation around Kotlin, Flutter and Fuchsia. I personally think that the situation is absolutely critical and imposes huge personal and business risks to all participants of Android ecosystem.

In this post I shared with you my journey from the question — why Google adopted Kotlin for Android? — to — what’s the roadmap of Java in Android? — and then to — WTF is going on in Android?

Now the most important question in my opinion is — when will Google kill Android?

From technical and technological perspective, I estimate that Google will be able to replace Android with Fuchsia in one-two years.

However, remember that absolutely nothing here is about technology. It’s also not about the users, the developers or the OEMs. The only factor at play is Google’s desire to avoid the responsibility for copyright violation if Oracle wins the lawsuit.

Therefore, court proceedings will determine Android’s fate and the schedule of that fate.

If the Supreme Court will agree to hear the case and revert one of Federal Circuit’s decisions, then it’s even probable that Google will simply shut down Fuchsia and Flutter projects and Android will live.

Is Oracle that evil:

At this point you might be inclined to blame Oracle for all this mess. Well, at least that was my initial reaction because I saw Oracle as the Satan of software industry.

However, then I asked myself: was there any professional harm Oracle did to me in the past?

There had been none that I was aware of. I haven’t even participated in Oracle’s ecosystem as an Android developer.

But then why do I have such a bad attitude towards Oracle?

I retrospected a bit and came to the non-flattering conclusion that I fell victim to Google’s PR efforts. For years I’ve been hearing how Oracle is bad and evil, but I never actually stopped to think about this assertion. I just took these claims and the standard FUD about APIs copyrightability at a face value.

After learning the details of Oracle vs. Google lawsuit I became convinced that Oracle is in its right. It’s up to the courts to determine whether Google is actually guilty, but there is undoubtedly enough evidence to justify Oracle’s actions.

Then I thought about how Android ecosystem would look like if Google would take a proper license from Sun in 2005-2006, or Oracle in 2010. What harm would it do to us developers, OEMs and, most importantly, Android users? I couldn’t think of a single potential negative aspect.

However, I do see many potential benefits that Google’s decision deprived all of us of. Imagine for a moment that Sun or Oracle is part of Android ecosystem.

We surely wouldn’t wait several years for Java 8 to be supported on Android. We would be part of the bigger Java ecosystem and would extract all the associated benefits. In fact, we would be the biggest group of Java developers and could actually influence the evolution of the entire Java ecosystem.

Google representatives claim that Java is “old” (I personally find this premise laughable). Well, if your company would take a proper license we could actually do something about it!

If Sun or Oracle would be part of Android ecosystem we would never need hacks like Jack toolchain or Retrolambda!

And, surely, Google wouldn’t be preparing to kill Android.

I used to think that Oracle is evil. Today I think that Android developers, OEMs and users missed a great deal by not having Oracle as a partner.

And all this was caused by Google’s enormous greed and apparent willingness to attack third-party copyrighted IP instead of taking a proper license. A license that was very much justified because if you read the evidence in Oracle vs. Google lawsuit, it will immediately become clear that Sun’s Java ecosystem was a major factor in Android’s success.


In the last three articles I shared with you one very troubling theory about the current state and the future of Android.

It’s important that you keep all the disclaimers that I stated in mind and remember that this is just a theory at this point. It can be wrong in part or in whole.

This theory of mine explains everything that happened in Android in the last couple of years and answers today’s most difficult questions. That said, a good theory doesn’t just explain the past, but also predicts the future.

One prediction has already came true because it indeed looks like Google is working to make Fuchsia support Android apps.

Here is a list of additional predictions based on this theory:

  1. Kotlin will not use Java APIs
  2. OpenJDK will be removed from Android
  3. Compiled Java code will either use Kotlin’s APIs or be directly compiled into native code
  4. Google will continue to promote Flutter
  5. Google might attempt to capitalize on their marketing efforts for Kotlin by making Flutter use Kotlin
  6. Android devices supporting Treble will be able to run Fuchsia
  7. Android project, as we know it today, will be killed

I don’t believe that absolutely all above predictions will come true. Such an accuracy would be surprising given the very limited amount of information available today. However, if you see any of the predictions 1-6 come true, be aware that it increases the probability of prediction 7 to come true.

There might also be other developments in Android ecosystem that will be in line with this theory. I will try to keep an eye on them and let you know if it happens.

At this point you might wonder what to do about all this. I don’t know.

As I said, according to this theory every participant of Android ecosystem is at personal and/or business risk. However, these risks are quite unique and depend on specifics of your involvement.

The risks of CEO of a company that makes a profit by modifying Android for OEMs are very different from the risks of an experienced Android developer who specializes in building beautiful UIs.

While I can’t give specific recommendations, I think that these two general advises might be useful:

  1. Think about your personal risk factors
  2. Take all Google official announcements with a grain of salt. Be skeptical and think critically.

Believe me, I wish for this entire theory of mine to turn out to be complete nonsense.

As usual, you’re welcome to leave your comments and questions below.

Check out my premium

Android Development Courses

34 comments on "Will Google Betray and Kill Android"

  1. No matter how depressing your conclusions are, I think you got most of it, if not all, right. It does look that Android community ended up hostage of corporate greed, although many, it appears, don’t see it that way. For one, I think that Flutter looks promising (despite using a weird language), but – alas – it is being introduced for the wrong reasons. I do hope that Android will survive somehow, if not in form then at least in spirit.

    Again, thank you for all the research and effort you took to put this series together. Even though not very encouraging, it is very informative, educating, and eye-opening in general. Looking forward to your other posts!

    • Hey Vladimir,
      I’m glad you found these posts interesting. Believe me, I’m sorry that they are not very optimistic too.
      However, I think it’s better to be aware of the situation and make educated decisions rather than believing that Google “loves” us and being screwed at some stage. That’s why I wrote these posts – to let people know about the potential risks.
      I suspect that many careers are at risk right now, and even betting on new tech like Flutter is not bullet-proof.
      I hope that these posts will be useful to someone because I knew ahead of time that it’s not the kind of content that will help me make friends or sell courses.
      Thank you for taking time to provide feedback.

  2. Nice research. Despite I see some panic notes, it’s the most comprehensive overview of the situation. Thanks.

  3. Solid, informative, well written article, even for the ones not too familiar with the subject. Well done, as usual

  4. I’ve always wondered why Google is trying so hard to promote Flutter … constantly.

    If Flutter’s constant promotion by Google had any connections to the Google – Oracle lawsuit, then it does appear to contradict with Google making Kotlin an official language for Android today…..

    That is, unless Kotlin is refactored under the hood to remove dependencies on OpenJDK, right?

    • Hello,
      I think that these are two independent strategies. IMHO, Google would want to keep Android because migration to another OS is extremely difficult and expensive process. However, if Kotlin and removal of OpenJDK won’t be enough to avoid potential legal responsibility – they will kill Android.

    • Quite weird comment.
      Google spent years developing Flutter and then they should not promote it?
      One can always find a hair in the soup when searching hard enough.

      • Hi Gunter,

        Any business that spent years developing a product should of course try to promote that product.
        I am wondering about Google’s motives and reasons behind developing Flutter in the first place.
        Yes, on the surface, Flutter is supposed to be Google’s answer to cross platform development for iOS and Android.
        But it’s hard to ignore the fact that Flutter is the primary development language for Fuchsia, and Fuchsia does appear to be a replacement for Android.

        There is more than one reason and motive behind the development of Flutter.

        • Hi Phileo,

          even companies like Google can’t always anticipate the Future.
          If you remember Windows 7 (just one prominent one out of countless), even the largest software companies can’t be sure a software project turns out as planned.
          Google itself has a long list of software projects they started and then dropped. Actually they are infamous just for that.

          Android has serious limitations and Apple has strong advantages because they fully control their whole ecosystem.

          Google is trying something new where they strive to avoid the issues hard to fix in existing systems.
          If it works out it might be able to replace Android. If developers, users, OEMs, … don’t like it, Google will have a hard time pushing it onto us.
          This also will take years and the whole IT landscape might have changed before Fuchsia is even ready to be used.

          So instead of being too suspicious you might consider they don’t provide more concrete information because they just don’t have it themselves.

          > But it’s hard to ignore the fact that Flutter is the primary development language for Fuchsia,

          Why shouldn’t they use something they own and that turned out quite well? Perhaps even better than they expected themselves?
          What would be the (better) alternatives?
          Did you have a closer look at Flutter yet?

  5. Hi Vasiliy ,

    In order for Google to migrate Kotlin away from using Java API’s, they would need consent from JetBrains.
    So then JetBrains must also agree to the overall plan of killing off Android.

    That is where things are muddy and I would have some doubts.

    • Hi,
      Theoretically, Google can modify Kotlin toolchain and ART by themselves. As far as I understand, the fact that Kotlin is Apache means that Google can re-implement Kotlin APIs and stay withing license bounds.
      That said, I think that JetBrains already helps Google with this plan.
      What many developers seem to overlook in this situation is that JetBrains has a business motivation and that Android developers aren’t their clients. Google is.

      • Exactly! They have been pushing into it a lot. Then they will have a strong language (without any java bits) that can be run on all sorts of HW devices and they are safe from the Oracle lawsuit. On the other side, Kotlin will find community of cloud / backend developers, who can still use Kotlin with huge number of java APIs that have been written in the last 20 years. Do not expect it will change soon to rewrite it all. A lot of industrial software, banks, telecom companies depends on Java in critical use cases. Thats also reason Java is number 1 in TIOBE index from 2001. It may gradually move to Kotlin in the following years, but not the APIs behind it. My prediction for the following yeras is Kotlin in JVM for cloud and backends and Kotlin Native + Flutter for future version of Android incarnations (or Fuchsia). I do not expect that Dart will gain momentum as programming language.

  6. We should want Google to keep innovating and moving forward. So a new OS built from the ground up for security and reliability is ideal. How in the world can that be a negative?

    • Hello Jack,
      Several negative aspects off the top of my head:
      1) New operating system means huge losses for businesses and individuals on re-learning and re-tooling
      2) New operating system is absolutely not guaranteed to be any better than the old. In fact, it will probably be much worse. Complete rewrite is rarely ever a good approach to software evolution.
      3) New operating system will coexist with the old one for a long time. Therefore, even further fragmentation and further losses for application owners.

      That’s from professional point of view. From ethical point of view I think that Google treats its community of developers disrespectfully by not sharing any plans. They basically throw a bunch of stuff at us, without clearly saying what’s the scope and the future of this stuff, and let us manage the risks with zero information. Given that Googlers often call us “partners” on-stage, I would expect a bit more collaboration and openess.

      In general, I don’t agree with your premise that Google “innovates and moves forward”. As I wrote in this article, I think that all Google tries to achieve is to avoid responsibility for their illegal actions.

  7. No offense, i have the opinion about flutter only.
    weird framework with weird language? really?
    I have done only some basic with android java and over that, I liked this weird framework far better to develop apps
    I do not think that Google will use kotlin over the weird language of a weird framework.

  8. While I think many of the arguments are true or close to the truth, I think it’s quite simplified and on-sided, at times even close to conspiracy theory.
    As if business decisions were always that simple.

    Google has issues with security in Linux and they had hard clashes with Linus about that AFAIK.
    There are many other reasons why Google might want to get rid of dependencies like unfriendly suppliers or components they don’t have full control over.

    Dart was started as replacement for JavaScript for big browser apps and its strategy changed several times since.
    Flutter was an approach to allow to build cross-platform apps and get rid of many things of the Android platform that didn’t turn out too well or are outdated and difficult to get rid of.
    These two projects somehow found that they are a perfect fit for each other
    and Flutter turned out to be a great platform for building cross-plaform applications.

    If Flutter flies and solves a host of problems for Google and mobile developers, why should they not think about discontinuing Android? But first Flutter needs to fly, and Android set the bar quite high for what “flying” means.
    Nobody knows how this will turn out and competitors aren’t sleeping.

    Google experiments with different approaches, all in the open for everybody to see.
    I think it’s quite weird to interpret this all as conspiracy against OEMs, Android developers and users.

    • Hello Günter,
      Thanks for sharing your opinion. I respectfully disagree on many points, but the only thing I would like to challenge is your last statement.
      I’m not sure what you mean by “all in the open for everybody to see”, but AFAIK, Google never shared a roadmap for either Kotlin, Java, Flutter or Fuchsia. That would be the absolute minimum to even mention “openess” IMHO.

      • What if they don’t have a roadmap?
        They were experimenting with a lot of approaches and dropped many.
        If they’d provided a roadmap people like you would have been extremely busy creating blog posts pointing out how badly Google failed because they couldn’t stick with the roadmap, again, and why they miraculously changed feature X to Y even though the roadmap told otherwise.
        There are tons of things worth criticising Google for, but out of all you chose projects where Google takes lots of risks for trying something new that could solve serious problems with existing tech and they even providing it as open source.
        For me this is what I actually love Google for. They have the resources to try things out, and they do it and share it with us.

        What I hate Google for is rather that they build products like G+ or all kinds of cloud services and then provide user or admin interfaces that make them appear like next-door hacker web sites where you have to be lucky to get past the login screen and support websites that don’t provide any useful information except links that always only go in cycles.

        Have you even tried Flutter?
        Many developers coming from iOS, Android, Xamarin, … are excited how much fun it is to build mobile apps with Flutter even though it’s just beta and still lots of polishing needs to be done.

        • Gunter,
          It seems to me that this discussion is derailing and neither of us will change his mind anyway. I don’t agree with almost all your statements, but it’s totally fine to agree to disagree respectfully.

  9. Really interesting and insightful story and I really like your saying, “Then I thought about how the Android ecosystem would look like if Google would take a proper license from Sun in 2005-2006,”. However, I was wondering, if Oracle wins, “Can Oracle continue with Android? based on the Android (AOSP) license terms?”

    • Hey Syed,
      I don’t think Oracle is interested in forking Android. In my estimation, they’ll happily allow Google to proceed and will even help if they’ll have a piece of that pie.

  10. Very interesting article and well written. Solid research. Thanks for sharing with us.
    By the way, what would your advice to Android freelancers be?

    • Hey Roberto,

      I’m Android freelancer and consultant myself and I decided to wait a bit to see what will happen. In my estimation, it’s not likely that there will be drastic changes in 2019. You can also mitigate the risks by mastering another tech (e.g. iOS, Flutter, web, etc.). This might come in handy if the situation will become really bad.

      However, all in all, I would say that if this theory is any accurate and Google decides to kill Android, it’ll probably create much additional opportunities for all of us.

      • Thanks for your reply. In one of your posts you’ve said “In some sense, to accept the truth about Oracle vs. Google lawsuit, I had to admit that I’ve been naive when I decided to become an Android developer. ”

        So I assume you have regrets about this decision? Would you have preferred to become an iOS developer instead?

        • I wanted to join an open, responsibly led community and I though that Google is the “don’t be evil” ideal. I was naive and I had to admit that. However, this doesn’t mean that I regret becoming Android developer.

          I used to work in semiconductors industry where everything is slow, so it was really tempting to work in a fast paced environment where you don’t need millions to bootstrap. I found that in Android. Maybe I could find that in iOS too, don’t know. In addition, I produce commercial courses for Android now and it goes relatively alright.

          Therefore, all in all, I’d say that I’m fine with being Android developer, despite the fact that I’m deeply disappointed by Google.

  11. Hi Vasiliy, I guess I’m late to the party.

    I wonder what if:
    – Google kill Android, launch Fuchsia.
    – Some people/developers/OEMs dissatisfied with Fuchsia, create alternative, Android-compatible open-source OS.
    – Oracle support it, become umbrella project.
    – Java-compatible Oracle Android is born.

    • Hi Safi,
      Several companies tried to do that, but, to this day, all of them failed. Google holds a very tight grip on Android ecosystem (using Google Play, Google Play Services, etc) and it will be very difficult to compete with them.

  12. I wrote this in 2010 when developers were wondering whether Google would actually release android: Google was not interested in helping developers make money from their apps. They simply wanted a platform to control. So they made development on it as cool and collaborative as possible. The community of developers contributed a lot. On the other hand, Apple was serious about selling apps and making money from them. So they invested in the app distribution chain.

  13. Two points admittedly delayed.
    The court case clearly is an inflection point for Google because the court decision is due soon (relative to this post) and there have been no major announcements from Google, but usually there are so this silence is unusual, so its all moot until the court decision (and I would agree that Google have no defence).

    One point that people overlook about steering younger developers in Kotlin is that there they will stay. So as an older (cough) developer I’ve been able to switch around every 4 or 5 years database->swing->j2ee->mobile. The old boys on the middle tier simply won’t adopt Kotlin, not because of the existing code base, but simply there is no advantage to doing so. So when you go for a job interview trying outside of Android and say oh I have 4 years Kotlin you will only hear ” and?” and then “next!”.

    Personally I don’t like Google deciding my tech path, there is no choice. Developer adoption didn’t push Intellij to the top, by use developers preferred Eclipse, it was mandated by Google. Same with the build system, you -have- to use Gradle. If I am picking a new language it would be C#, also similar to Java, not Kotlin. Finally there is a financial imperative for me, I earn more sticking with my Java experience rather than jumping to Kotlin.
    Hopefully Google will lose the court case and if not, then I’m going to move back to server side.


Leave a Comment