Ruben Pieters

In the world of Android development, the journey of Kotlin or Java source code to Dalvik bytecode is anything but straightforward. However, as with any complex system, this translation process can introduce quirks or unexpected behaviors leading to challenging debugging sessions. In this session, we’ll take a deep dive into how Java and Kotlin code ultimately becomes Dalvik bytecode. This transformation process can have some quirks introduced by the various tools involved in this process. Improving your understanding of these transformations can help tracking down complex problems related to them. Through the lens of our own experience developing a recompiler for Dalvik bytecode, we’ll share real-world examples of unexpected behaviors we encountered. The goal of this session is to arm you with a deeper understanding of the tools related to these translations in the Android ecosystem and practical ways to handle debugging issues related to them. As a sneak peek, here's an example of quirks we'll cover in this session: - When building an Android application, you compile against classes that might not be present on the device it's running on due to the difference in Android version. This can cause an invocation of a method call to fail after it is called through reflection, even though the regular invocation would succeed on that device. - The Android Runtime uses just-in-time compilation that compiles the Dalvik bytecode to machine code. We'll cover a bug we encountered in this compilation process, and share useful tools for diagnosing whether just-in-time compilation is the culprit of an issue you are debugging.