Handling Nullability in Android 11 and Beyond

Last May at Google I/O, weannounced that Android was going Kotlin first, and now over 60% of the top 1000 Android apps use Kotlin. One feature we love about Kotlin is that nullability is baked into its type system — when declaring a reference, you say upfront whether it can hold null values . In this post, we’ll look at how the Android 11 SDK does more to expose nullability information in its APIs and show how you can prepare your Kotlin code for it.

How does nullability in Kotlin work?

When writing code in Kotlin, you can use the question mark operator to indicate nullability:

KOTLIN

var x: Int = 1
x = null // compilation error

var y: Int? = 1
y = null // okay

This aspect of Kotlin makes your code safer — if you later call a method or try to access a property on a non-null variable like x , you know you’re not risking a null pointer exception. We hear over and over again that this feature of Kotlin gives developers more peace of mind and leads to higher quality apps for end users.

How does nullability work with the Java programming language?

Not all of your (or Android’s) APIs are written in Kotlin. Fortunately, the Kotlin compiler recognizes annotations on Java programming languages methods that indicate whether they produce nullable or non-nullable values. For example:

JAVA

public @Nullable String getCurrentName() {
   return currentName;
}

The @Nullable annotation ensures that when using the result of getCurrentName in a Kotlin file, you can’t dereference it without a null check. If you try, Android Studio will notify you of an error, and the Kotlin compiler will throw an error in your build. The opposite is true of @NonNull — it tells the Kotlin compiler to treat the method result as a non-null type, forbidding you from assigning that result to null later in your program.

The Kotlin compiler also recognizes two similar annotations, @RecentlyNullable and @RecentlyNonNull , which are the exact same as @Nullable and @NonNull , only they generate warnings instead of errors ¹ .

Nullability in Android 11

Last month, we released the Android 11 Developer Preview , which allows you to test out the new Android 11 SDK. We upgraded a number of annotations in the SDK from @RecentlyNullable and @RecentlyNonNull to @Nullable and @NonNull (warnings to errors) and continued to annotate the SDK with more @RecentlyNullable and @RecentlyNonNull annotations on methods that didn’t have nullability information before.

What’s next

If you are writing in Kotlin, when upgrading from the Android 10 to the Android 11 SDK, you may notice that there are some new compiler warnings and that previous warnings may have been upgraded to errors. This is intended and a feature of the Kotlin compiler — these warnings tell you that you may be writing code that crashes your app at runtime (a risk you would miss entirely if you weren’t writing in Kotlin). As you encounter these warnings and errors, you can handle them by adding null checks to your code.

As we continue to make headway annotating the Android SDK, we’ll follow this same pattern — @RecentlyNullable and @RecentlyNonNull for one numbered release (e.g., Android 10), and then upgrade to @Nullable and @NonNull in the next release (e.g., Android 11). This practice will give you at least a full release cycle to update your Kotlin code and ensure you’re writing high-quality, robust code.

1. Due to rules regarding handling of annotations in Kotlin, there is currently a small set of cases where the compiler will throw an error for @Nullable references but not for @RecentlyNullable references.

Java is a trademark of Oracle and/or its affiliates.