Debugging Mixed-Mode Android Apps

Android app development is split into two, very distinct worlds.

On the one side, there's the Android SDK, which is what the bulk of Android apps is being developed in. The SDK is based on the Java Runtime and the standard Java APIs, and it provides a very high-level development experience. Traditionally, the Java language or Kotlin would be used to develop in this space.

And then there's the Android NDK, which sits at a much lower level and allows to write code directly for the native CPUs (e.g. ARM or x86). This code works against lower-level APIs provided by Android and the underlying Linux operating system that Android is based on, and traditionally one would use a low-level language such as C to write code at this level.

The Java Native Interface, or JNI, allows the two worlds to interact, making it possible for SDK-level JVM code to call NDK-level native functions, and vice versa.

For a while now, Elements has been breaking the language barrier between these two sides of the Android platform: As a seasoned Android developer with Java experience, you can use the Java language — including its Object Oriented paradigms and the native object model provided by our Island back-end —  to write rich native NDK code. And of course the same applies to the other four Elements languages, C#, Swift, Pascal and Go, which also can be used on the SDK and NDK side, if you prefer them over Java.

In last week's Elements release (.2441), we took another big step towards making the interaction between SDK and NDK code more seamless, and that is Mixed-Mode Debugging.

It's so cool, we decided to make a video about it:

Essentially, with mixed-mode debugging you can run your SDK-based Android app (all Android apps need to have an SDK-based portion/shell, while using NDK is optional) as you normally would, but in addition to debugging your JVM code, you can also debug your native code at the same time. You can set breakpoints in either part, or break on exceptions that happen on JVM or native level alike.

All of this is controlled by two settings, but Fire and Water, our IDEs, automate the process for you so you don't even have to worry about them yourself — everything Just Works™.

First, there's the "Support Native Debugging" option in your NDK project. It's enabled by default for the Debug configuration in new projects, and it instructs the build chain to deploy the LLDB debugger library as part of your native library (and have it, in turn, bundled into your APK). This is what allows the debugger to attach to the NDK portion of your app later.

Secondly, there's the "Debug Engine" option in your SDK project. It defaults to "Java", for JVM-only debugging, but as soon as you add a Project Reference to an NDK extension to your app, it will switch to "Both" (again, only for the Debug configuration), instructing the Elements Debugger to start both JVM and native debug sessions when you launch your app.

This, of course, works both in the Emulator and on the device.

Elements is a general purpose multi-language, multi-platform development suite for all your programming needs. Next to Android, it lets you also develop for .NET, Cocoa, Linux, Windows and the Web, with your choice of Oxygene (Next Generation Object Pascal), C#, Swift and — coming next month — Go as programming language. Read more and try Elements for free at elementscompiler.com.