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.

Disclaimer:

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.

OpenJDK:

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.

Unless…

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.

Fuchsia:

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:

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:

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.

Conclusion:

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.