12 ms·

A Closer Look at Android RunTime in Android L

119 points by rohan404 12y ago

pjmlp 12y ago
It was about time Android catched up with how iOS and Windows Phone work (e.g. everything is AOT compiled to native code). Now it just needs to provide a similar developer experience to the other mobile platforms for the C and C++ developers.
- djur 12y ago
  As I understand it, the major speed improvements with ART come less from the native compilation than from the improved GC and the ability to do whole-program optimizations during the AOT compilation step. EDIT: Also, ART takes a different approach to AOT compilation than either iOS and Windows Phone. iOS apps are shipped as compiled binaries from the start, and apparently Windows Phone apps are compiled in the cloud by MS. ART does the native translation step on the device itself, which has only really recently become feasible with the speed and storage capacity of recent Android devices.
  - higherpurpose 12y ago
    I think his main point was that it has caught up with the performance of AOT, not the nitty gritty details behind the process, which is kind of irrelevant to the user.
    - danieldk 12y ago
      It is relevant to the user for two reasons: portability and speed. In contrast to iOS, Android in the wild runs on everything from ARM to x86, in many different generations. Doing the compilation on the device allows the AOT compiler to optimize for the specific CPU that the device uses. Also, it increases compatibility, because what is shipped is platform-independent bytecode, not a binary that may only target one specific architecture.
      - pjmlp 12y ago
        This is a solved problem since the early 80's, known as fat binaries or delivering multiple binaries in a package. I code mainly in C++ (NDK) and don't have any issues delivering code.
        vetinari 12y ago
        > known as fat binaries or delivering multiple binaries in a package. That's not a solution, that's band aid. Fat binaries or multiple binaries cannot support future architectures or architectures that the original developer doesn't support. Platform independent bytecode can.
        pjmlp 12y ago
        That is the theory, which I preached for a long time as well. The real life looks a bit different. An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. So gcc and clang can easily outperform Dalvik in < 4.4 generations, given that it was hardly changed since 2.3.
        danieldk 12y ago
        An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. For one application. And again, your binaries will be very fat if you want to optimize for every possible CPU generation. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. Which is a problem with how Android updates are distributed, not the principle of doing AOT compilation on byte code. I think pretty much everyone agrees that the push of updates to Android devices sucks, compared to iOS or, to some extend, Windows Phone. Also, for optimization for a particular CPU it should not matter if ART is not upgraded, as long ART was optimized for the CPU at the time the phone was released. (Of course, you would miss out on newer optimizations in ART.)
  - pjmlp 12y ago
    Sure, Dalvik apparently was left to gather dust for a few Android releases. Yes, having the AOT compilation done on the device is an handicap, given how OEMs barely update Android versions. So while Apple and Microsoft approaches mean you can target older devices while enjoying improvements in code generation, with Google's approach you're stuck with whatever the device supports, unless you use the NDK instead.
- lern_too_spel 12y ago
  In terms of scaling to more architectures, this solution looks superior to iOS's and on-par with Windows Phone's CIL-MDIL system. Since the original Android phones, they've added ARM processors with VFP, Thumb, Thumb-2, NEON, and now ARMv8-A; MIPS processors; and various Intel instruction sets. Developers targeting Dalvik bytecode can ignore all that complexity going on underneath. The same APK they built years ago will work everywhere. I agree that they should have made the transition to AOT a long time ago. Their technical excuse is that devices didn't have enough space. That's only because they allowed devices to not have enough space. Even the original iPhone had 4 GB flash minimum.
  - higherpurpose 12y ago
    Android's model for 64-bit support also seems superior to all other operating systems, in terms of not adding the "64-bit memory bloat" (which is roughly 30 percent more memory required for 64-bit apps), so in terms of RAM needed 64-bit Android apps should actually require less than 64-bit iOS apps. However, I'm not completely sure whether Google just restricts the addresses length to 32-bit, or they are keeping the apps 32-bit even on the 64-bit architecture. It sounds like the former, but I really hope it's not the latter. So far I've not seen ARMv8 supported in the SDK and Nvidia's 64-bit Denver CPU still comes out as 32-bit in benchmark tests, even on Android Lollipop. I don't know whether that's related in any way, or it's some other Google screw-up (not being ready on time with Aarach64 support), or it's just the benchmarks who don't support ARMv8 yet. Oh and I agree with your comment on storage. Google should impose more "reasonable" requirements. In 2010, even high-end HTC flagships came with like less than 200 MB free storage. Absolutely unacceptable, even at the time. I've hated my HTC phone for so long because it, and it kind of made me not want to get HTC ever again now, since the brand is tainted in my mind. Today, even $50 Android phones shouldn't have less than 4GB internal storage (which is like 1GB free storage), but those over $100-$150 should all have at least 8GB. Most people should get at least 16GB. When I'll buy a flagship phone a year or so from now I intend to get one with 64GB internal and a UHS-I 128GB microSD to shoot 4k video and RAW pictures.
    - AndrewDucker 12y ago
      How does Android's support for 64-bit avoid the memory bloat?
jkn 12y ago
The URL points to the second page of the article, can someone fix it?
- fpgeek 12y ago
  That's because the original submitter wanted to highlight the garbage-collection discussion, not the whole article. Of course, now that the title has been changed...
- dang 12y ago
  Thanks! Fixed.
frozenport 12y ago
This article is a great reminder that garbage collection should not be the default strategy as it is hard to get right, Dalvik is almost a decade old, and that it introduces performance issues which are not transparent to the programmer. Indeed these second long delays have rendered Android hardware second rate.
- rohan404 12y ago
  It was pretty ridiculous, even on some of the most powerful hardware out there I still found animations to lag from time to time due to the GC_FOR_ALLOC calls! Ended up with a bunch of hacks to try to work around the issue, but none fully resolved it.
  - on_and_off 12y ago
    If animations lag because of allocations, then you are allocating too many objects.. The most common cause is object allocation in a critical part like a draw call (or view binding).
    - rohan404 12y ago
      This is true, but for operations like loading images from disk for example, this is unavoidable. The best you can do is reuse memory instead of allocating whenever possible
      - kuschku 12y ago
        On Android you should definitely load the images Async and not load them within the draw call.
        rohan404 12y ago
        Even loaded asynchronously, the calls for allocation still cause lag. Unless I am doing something incorrectly?
neals 12y ago
Not an Android Developer here. Is there no "pauseForGC" function in Java/Android? I know AS3 has it, and you can use it to suggest GC at a point where there aren't any animation going on.
- tpaksoy 12y ago
  You can use the System class to do this. "System.gc()" will request a GC run. Of course, its only a request. There's no guarantee when, and if the GC will fulfill that request.
- rohan404 12y ago
  There is a System.gc() call which is essentially what you described, but it doesn't help with allocations freezing the UI for memory intensive applications
andyjohnson0 12y ago
"...an application’s first start-up will be much increased compared to an equivalent Dalvik system." Any thoughts on why they they are compiling to native on first run, rather than at install-time? Often a user will want to run immediately after install, but my feeling is that people are less likely to be frustrated by a longer install time than having to wait for an app to start-up. Edit: Izacus and InclinedPlane say that AOT compilation is at install-time and the article is wrong.
- cpeterso 12y ago
  It seems like the AOT compilation could be scheduled asynchronously after install. You don't need to prolong install wait for the user. If they don't open the app right away, then the first run will be fast because AOT should have completed by then. If the user tries to open the app before AOT has completed, then the first run will have to block for AOT to complete.
- keletappi 12y ago
  Maybe auto-updating apps? It could be that the compilation is resource-intensive enough that it would slow down whatever user is currently doing when an app is updated in the background.
- InclinedPlane 12y ago
  They are compiling to native at install-time (or on first boot if you're upgrading to ART on an existing device). I'm not sure exactly what overhead is happening on first run that would cause a slow down compared to Dalvik.
- ohazi 12y ago
  > Any thoughts on why they they are compiling to native on first run, rather than at install-time? Or why they don't do it on the server so that you get the specialized binary directly from Google Play? Why should my phone be compiling anything?
  - pjmlp 12y ago
    This is Microsoft's approach.
ShabbyDoo 12y ago
For Google, ART seems bigger than just Android. Consider the degree to which their infrastructure depends on the Oracle JVM and the associated strategic risk. As one datapoint, recall the Oracle vs. Google Java lawsuit. How much additional ART development effort is required for correct execution of non-AWT (Abstract Windowing Toolkit) Java applications (essentially, headless server processes)? I know the Java/JVM ecosystem well, but I have not done any Android development. Surely, Google wants control over the destiny of its core software stack. The article doesn't mention one seemingly huge benefit of JIT compilation: profile-guided optimization: http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmjitcompilationoverview-24613146 http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmj... Perhaps the baby has been thrown out with the bathwater? Little is mentioned about how ART compares to the JVM. For example, does ART perform escape analysis? Not all object allocations are equally bad. The Sun JVM can figure out which objects may be allocated on TLABs (Thread Local Allocation Buffers) - an optimization which reduces the burden placed on the garbage collector because TLAB-resident objects may be deallocated as the stack is popped. [Please fact-check me as I'm merely a long-time Java developer vs. an expert on JVM internals]
- pjmlp 12y ago
  Well, OpenJDK is getting AOT compilation as well (planned for 9). In addition to JIT. The SubstrateVM is the AOT compiler for Graal. And many commercial JVMs do offer AOT compilation. Also, .NET has had AOT/JIT since the very beginning. And now static compilation is coming as well.
  - logicchains 12y ago
    > Well, OpenJDK is getting AOT compilation as well (planned for 9). In addition to JIT. On ARM? Last time I checked, OpenJDK doesn't even have JIT compilation on ARM, it just interprets the bytecode.
    - pjmlp 12y ago
      > On ARM? Well, at least the closed source JDK has it. As many other commercial JVMs. As for AOT, it was referenced at Java ONE, Java Language Summit and Øredev 2014.
flohofwoe 12y ago
It's interesting that an asm.js Javascript application running in a web browser yields better performance on Android then a Java application running on Dalvik: https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/ https://blog.mozilla.org/javascript/2013/08/01/staring-at-th... So ART and AOT compilation is a step in the right direction, but I'm secretly hoping that Google will enable Portable Native Client 'natively' on Android outside the browser for proper C/C++ development. Distribution format is a frozen LLVM IR subset, final compilation to the CPU architecture happens on the client side, and performance is close enough to pre-compiled that the difference doesn't matter much.
- pjmlp 12y ago
  I would just be happy if little things like SKIA and SQLLite were exposed in the NDK, instead of forcing us to bundle our own versions. And having a gdb setup that works properly.
sandGorgon 12y ago
Here's a question - has Google made the move to ART for performance reasons or is it because it makes it possible to move to ... say.. Golang for Android ? Let me explain - One of the big reasons that Google cannot switch over to Golang (or Dart, or any other) is that the core of Android SDK is written in Java and therefore every app needs to work with Java to be able to tap into it. However, ART can make it possible for SDK components to compiled down to object code, thus making it possible for Golang/Dart/etc. to link against it, while MAINTAINING backward compatibility with old java apps. Will it allow new apps to be written in pure native code, without relying on the JNI bridge ?
- pjmlp 12y ago
  You still need an common ABI and Java has a few features Go cannot understand and vice-versa. Android team stated multiple times that Java is the language of the platform.
- vetinari 12y ago
  No, ART still works with dex bytecode, and native code still requires JNI bridge.
- izacus 12y ago
  ART is still Java runtime which conforms to Java memory model, GC requirements and everything that comes with it. So no, you cannot just link random other languages without going through JNI. That is a common misconception. Also most of Android itself is managed Java code, so making other languages first-party citizens would require pretty much full OS rewrite. I very much doubt rewriting whole Android just to support non-JVM languages is worth it. Making ART VM fast, efficient and adding Java 8 bytecode compatiblity is I feel a much better use of development time. Wasting precious development time to placate devs that don't want to switch languagaes is - I feel - a hugely wasted effort.
  - higherpurpose 12y ago
    I almost wish Google loses against Oracle at the Supreme Court, and is forced to pay Oracle billions every year as long as it continues to use Java, just so it's forced to switch away from Java. Almost, because I know Google losing that lawsuit could mean dire consequences across the industry. But it's still annoying that Android has to use Java and can't change away from it.

119 points by rohan404 12y ago

pjmlp 12y ago

It was about time Android catched up with how iOS and Windows Phone work (e.g. everything is AOT compiled to native code). Now it just needs to provide a similar developer experience to the other mobile platforms for the C and C++ developers.

djur 12y ago
As I understand it, the major speed improvements with ART come less from the native compilation than from the improved GC and the ability to do whole-program optimizations during the AOT compilation step. EDIT: Also, ART takes a different approach to AOT compilation than either iOS and Windows Phone. iOS apps are shipped as compiled binaries from the start, and apparently Windows Phone apps are compiled in the cloud by MS. ART does the native translation step on the device itself, which has only really recently become feasible with the speed and storage capacity of recent Android devices.
- higherpurpose 12y ago
  I think his main point was that it has caught up with the performance of AOT, not the nitty gritty details behind the process, which is kind of irrelevant to the user.
  - danieldk 12y ago
    It is relevant to the user for two reasons: portability and speed. In contrast to iOS, Android in the wild runs on everything from ARM to x86, in many different generations. Doing the compilation on the device allows the AOT compiler to optimize for the specific CPU that the device uses. Also, it increases compatibility, because what is shipped is platform-independent bytecode, not a binary that may only target one specific architecture.
    - pjmlp 12y ago
      This is a solved problem since the early 80's, known as fat binaries or delivering multiple binaries in a package. I code mainly in C++ (NDK) and don't have any issues delivering code.
      - vetinari 12y ago
        > known as fat binaries or delivering multiple binaries in a package. That's not a solution, that's band aid. Fat binaries or multiple binaries cannot support future architectures or architectures that the original developer doesn't support. Platform independent bytecode can.
        pjmlp 12y ago
        That is the theory, which I preached for a long time as well. The real life looks a bit different. An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. So gcc and clang can easily outperform Dalvik in < 4.4 generations, given that it was hardly changed since 2.3.
        danieldk 12y ago
        An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. For one application. And again, your binaries will be very fat if you want to optimize for every possible CPU generation. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. Which is a problem with how Android updates are distributed, not the principle of doing AOT compilation on byte code. I think pretty much everyone agrees that the push of updates to Android devices sucks, compared to iOS or, to some extend, Windows Phone. Also, for optimization for a particular CPU it should not matter if ART is not upgraded, as long ART was optimized for the CPU at the time the phone was released. (Of course, you would miss out on newer optimizations in ART.)
- pjmlp 12y ago
  Sure, Dalvik apparently was left to gather dust for a few Android releases. Yes, having the AOT compilation done on the device is an handicap, given how OEMs barely update Android versions. So while Apple and Microsoft approaches mean you can target older devices while enjoying improvements in code generation, with Google's approach you're stuck with whatever the device supports, unless you use the NDK instead.
lern_too_spel 12y ago
In terms of scaling to more architectures, this solution looks superior to iOS's and on-par with Windows Phone's CIL-MDIL system. Since the original Android phones, they've added ARM processors with VFP, Thumb, Thumb-2, NEON, and now ARMv8-A; MIPS processors; and various Intel instruction sets. Developers targeting Dalvik bytecode can ignore all that complexity going on underneath. The same APK they built years ago will work everywhere. I agree that they should have made the transition to AOT a long time ago. Their technical excuse is that devices didn't have enough space. That's only because they allowed devices to not have enough space. Even the original iPhone had 4 GB flash minimum.
- higherpurpose 12y ago
  Android's model for 64-bit support also seems superior to all other operating systems, in terms of not adding the "64-bit memory bloat" (which is roughly 30 percent more memory required for 64-bit apps), so in terms of RAM needed 64-bit Android apps should actually require less than 64-bit iOS apps. However, I'm not completely sure whether Google just restricts the addresses length to 32-bit, or they are keeping the apps 32-bit even on the 64-bit architecture. It sounds like the former, but I really hope it's not the latter. So far I've not seen ARMv8 supported in the SDK and Nvidia's 64-bit Denver CPU still comes out as 32-bit in benchmark tests, even on Android Lollipop. I don't know whether that's related in any way, or it's some other Google screw-up (not being ready on time with Aarach64 support), or it's just the benchmarks who don't support ARMv8 yet. Oh and I agree with your comment on storage. Google should impose more "reasonable" requirements. In 2010, even high-end HTC flagships came with like less than 200 MB free storage. Absolutely unacceptable, even at the time. I've hated my HTC phone for so long because it, and it kind of made me not want to get HTC ever again now, since the brand is tainted in my mind. Today, even $50 Android phones shouldn't have less than 4GB internal storage (which is like 1GB free storage), but those over $100-$150 should all have at least 8GB. Most people should get at least 16GB. When I'll buy a flagship phone a year or so from now I intend to get one with 64GB internal and a UHS-I 128GB microSD to shoot 4k video and RAW pictures.
  - AndrewDucker 12y ago
    How does Android's support for 64-bit avoid the memory bloat?

jkn 12y ago

The URL points to the second page of the article, can someone fix it?

fpgeek 12y ago
That's because the original submitter wanted to highlight the garbage-collection discussion, not the whole article. Of course, now that the title has been changed...
dang 12y ago
Thanks! Fixed.

frozenport 12y ago

This article is a great reminder that garbage collection should not be the default strategy as it is hard to get right, Dalvik is almost a decade old, and that it introduces performance issues which are not transparent to the programmer. Indeed these second long delays have rendered Android hardware second rate.

rohan404 12y ago
It was pretty ridiculous, even on some of the most powerful hardware out there I still found animations to lag from time to time due to the GC_FOR_ALLOC calls! Ended up with a bunch of hacks to try to work around the issue, but none fully resolved it.
- on_and_off 12y ago
  If animations lag because of allocations, then you are allocating too many objects.. The most common cause is object allocation in a critical part like a draw call (or view binding).
  - rohan404 12y ago
    This is true, but for operations like loading images from disk for example, this is unavoidable. The best you can do is reuse memory instead of allocating whenever possible
    - kuschku 12y ago
      On Android you should definitely load the images Async and not load them within the draw call.
      - rohan404 12y ago
        Even loaded asynchronously, the calls for allocation still cause lag. Unless I am doing something incorrectly?

neals 12y ago

Not an Android Developer here. Is there no "pauseForGC" function in Java/Android? I know AS3 has it, and you can use it to suggest GC at a point where there aren't any animation going on.

tpaksoy 12y ago
You can use the System class to do this. "System.gc()" will request a GC run. Of course, its only a request. There's no guarantee when, and if the GC will fulfill that request.
rohan404 12y ago
There is a System.gc() call which is essentially what you described, but it doesn't help with allocations freezing the UI for memory intensive applications

andyjohnson0 12y ago

"...an application’s first start-up will be much increased compared to an equivalent Dalvik system." Any thoughts on why they they are compiling to native on first run, rather than at install-time? Often a user will want to run immediately after install, but my feeling is that people are less likely to be frustrated by a longer install time than having to wait for an app to start-up. Edit: Izacus and InclinedPlane say that AOT compilation is at install-time and the article is wrong.

cpeterso 12y ago
It seems like the AOT compilation could be scheduled asynchronously after install. You don't need to prolong install wait for the user. If they don't open the app right away, then the first run will be fast because AOT should have completed by then. If the user tries to open the app before AOT has completed, then the first run will have to block for AOT to complete.
keletappi 12y ago
Maybe auto-updating apps? It could be that the compilation is resource-intensive enough that it would slow down whatever user is currently doing when an app is updated in the background.
InclinedPlane 12y ago
They are compiling to native at install-time (or on first boot if you're upgrading to ART on an existing device). I'm not sure exactly what overhead is happening on first run that would cause a slow down compared to Dalvik.
ohazi 12y ago
> Any thoughts on why they they are compiling to native on first run, rather than at install-time? Or why they don't do it on the server so that you get the specialized binary directly from Google Play? Why should my phone be compiling anything?
- pjmlp 12y ago
  This is Microsoft's approach.

ShabbyDoo 12y ago

For Google, ART seems bigger than just Android. Consider the degree to which their infrastructure depends on the Oracle JVM and the associated strategic risk. As one datapoint, recall the Oracle vs. Google Java lawsuit. How much additional ART development effort is required for correct execution of non-AWT (Abstract Windowing Toolkit) Java applications (essentially, headless server processes)? I know the Java/JVM ecosystem well, but I have not done any Android development. Surely, Google wants control over the destiny of its core software stack. The article doesn't mention one seemingly huge benefit of JIT compilation: profile-guided optimization: http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmjitcompilationoverview-24613146 http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmj... Perhaps the baby has been thrown out with the bathwater? Little is mentioned about how ART compares to the JVM. For example, does ART perform escape analysis? Not all object allocations are equally bad. The Sun JVM can figure out which objects may be allocated on TLABs (Thread Local Allocation Buffers) - an optimization which reduces the burden placed on the garbage collector because TLAB-resident objects may be deallocated as the stack is popped. [Please fact-check me as I'm merely a long-time Java developer vs. an expert on JVM internals]

pjmlp 12y ago
Well, OpenJDK is getting AOT compilation as well (planned for 9). In addition to JIT. The SubstrateVM is the AOT compiler for Graal. And many commercial JVMs do offer AOT compilation. Also, .NET has had AOT/JIT since the very beginning. And now static compilation is coming as well.
- logicchains 12y ago
  > Well, OpenJDK is getting AOT compilation as well (planned for 9). In addition to JIT. On ARM? Last time I checked, OpenJDK doesn't even have JIT compilation on ARM, it just interprets the bytecode.
  - pjmlp 12y ago
    > On ARM? Well, at least the closed source JDK has it. As many other commercial JVMs. As for AOT, it was referenced at Java ONE, Java Language Summit and Øredev 2014.

flohofwoe 12y ago

It's interesting that an asm.js Javascript application running in a web browser yields better performance on Android then a Java application running on Dalvik: https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/ https://blog.mozilla.org/javascript/2013/08/01/staring-at-th... So ART and AOT compilation is a step in the right direction, but I'm secretly hoping that Google will enable Portable Native Client 'natively' on Android outside the browser for proper C/C++ development. Distribution format is a frozen LLVM IR subset, final compilation to the CPU architecture happens on the client side, and performance is close enough to pre-compiled that the difference doesn't matter much.

pjmlp 12y ago
I would just be happy if little things like SKIA and SQLLite were exposed in the NDK, instead of forcing us to bundle our own versions. And having a gdb setup that works properly.

sandGorgon 12y ago

Here's a question - has Google made the move to ART for performance reasons or is it because it makes it possible to move to ... say.. Golang for Android ? Let me explain - One of the big reasons that Google cannot switch over to Golang (or Dart, or any other) is that the core of Android SDK is written in Java and therefore every app needs to work with Java to be able to tap into it. However, ART can make it possible for SDK components to compiled down to object code, thus making it possible for Golang/Dart/etc. to link against it, while MAINTAINING backward compatibility with old java apps. Will it allow new apps to be written in pure native code, without relying on the JNI bridge ?

pjmlp 12y ago
You still need an common ABI and Java has a few features Go cannot understand and vice-versa. Android team stated multiple times that Java is the language of the platform.
vetinari 12y ago
No, ART still works with dex bytecode, and native code still requires JNI bridge.
izacus 12y ago
ART is still Java runtime which conforms to Java memory model, GC requirements and everything that comes with it. So no, you cannot just link random other languages without going through JNI. That is a common misconception. Also most of Android itself is managed Java code, so making other languages first-party citizens would require pretty much full OS rewrite. I very much doubt rewriting whole Android just to support non-JVM languages is worth it. Making ART VM fast, efficient and adding Java 8 bytecode compatiblity is I feel a much better use of development time. Wasting precious development time to placate devs that don't want to switch languagaes is - I feel - a hugely wasted effort.
- higherpurpose 12y ago
  I almost wish Google loses against Oracle at the Supreme Court, and is forced to pay Oracle billions every year as long as it continues to use Java, just so it's forced to switch away from Java. Almost, because I know Google losing that lawsuit could mean dire consequences across the industry. But it's still annoying that Android has to use Java and can't change away from it.