In Java 8, Oracle added support for Lambda expressions to the Java programming language and the Java Virtual Machine (JVM). Though Android apps are also written in Java, this however doesn’t automatically make them available to app developers. In fact, it takes some time until Android catches up with newer Java developments.
The build chain for Android is (at least at the moment) built on top of the Java build chain: The normal Java compiler takes Java source files and creates Java class files. These files then serve as inputs to Android’s “dx” tool which finally emits the Dalvik bytecode that can be run on an Android device or emulator. In version 19 of the Android build tools, support for Java 1.7 class files was added – with the usual delay (Java 1.7 came out in July 2011, Android build tools v19 came out in April 2012). Up to now, that was the end of the line. But now, Java 1.8 support might be around the corner.
Those who have followed the development of the smali/baksmali tools closely mnight have noticed a recent commit with a very interesting description:
Add lambda experimental dalvik opcodes
The story goes on in the same commit description:
Add new -X/–experimental flag to [dis]assemble opcodes not in art yet
Add new opcodes liberate-variable, box-lambda, unbox-lambda, capture-variable, create-lambda, invoke-lambda
So the tool now supports opcodes that (judging by their names) will add Lambda support to Android. They are not yet available in ART, but given that the developer who goes by JesusFreke and is the person behind smali/baksmali is with Google’s Android team, chances are that we got an unintended sneak preview into the inner workings of the next Android release.
Let’s look around in the commit a bit further. There is a very interesting test case with the following line of code:
options.apiLevel = 23; // since we need at least level 23 for lambda opcodes
The most recent Android API level is currently 22 which is Android 5.1 Lollipop, released March 2015. So we are actually looking at stuff for something still in the works. Whether these opcodes will actually be part of Android 23 is not clear, though – they might as well be released later.
Speaking of opcodes, let’s have a look at the numbers. In the “old world”, 0xf3 – 0xf9 were ODEX opcodes. With ART becoming the new execution model, they have been deprecated together with much of ODEX (yeah, it’s still lurking in some corners, ok). Their place are now taking the Lambda opcodes, e.g., “invoke-lambda” at 0xf3. There’s a certain chance that these Opcodes will still be relocated before a final release and move away from the “internal” region.
In summary, there seems to be hope for all those who were missing Lambda expressions and Java 1.8 support on Android. Let’s see what happens next.
Cross-posted from SEEBlog
