Common Kotlin Pitfalls in Android Development and How to Solve Them

Author Liu Peng, an Android development engineer at Hujiang, reflects on the challenges his team faced after adopting Kotlin for more than two years, presenting a collection of real‑world pitfalls and their resolutions.

1. IDE Convert Laziness Leads to Disaster

Android Studio’s one‑click Java‑to‑Kotlin conversion is convenient but can introduce unsafe forced‑unwraps (e.g., a!!.value ) that cause crashes when null values appear at runtime. Certain plugin versions also crash the IDE when converting classes containing Runnable .

2. DexGuard Obfuscation Crash (NoSuchMethodError)

The project uses DexGuard for code hardening, which caused crashes after obfuscation when handling server‑returned data. The original code:

val drawable = imageView?.drawable ?: ColorDrawable(Color.LTGRAY) transitionDrawable = TransitionDrawable(arrayOf(drawable, ColorDrawable()))

crashed after obfuscation. Adding a null‑check solved the issue:

if(imageView == null) return val drawable = imageView.drawable ?: ColorDrawable(Color.LTGRAY)

3. Debugging Pitfalls

When debugging the main app, setting breakpoints often results in the IDE reporting an exception, preventing inspection of asynchronous callback data. Debugging Kotlin libraries is even harder: the generated bytecode makes setting breakpoints impossible, forcing developers to rely on source‑dependency debugging.

4. No Ternary Operator

Java’s ternary expression:

String content = contentStringBuilder.toString().length() >=140 ? contentStringBuilder.toString().substring(0,139) : contentStringBuilder.toString();

has no direct equivalent in Kotlin, requiring an if‑else expression such as val a = if(some) valueA else valueB . To mimic ternary syntax, the team created a helper function:

val a = select(some, valueA, valueB)

However, this initially caused an IndexOutOfBoundsException because the arguments were evaluated before the function call; a revised implementation fixed the bug.

5. Other Pitfalls

Reified functions are powerful, but Java cannot call Kotlin reified functions, so using Kotlin throughout is recommended.

Kotlin’s nullable type syntax (the ? operator) can be confusing; third‑party libraries are often used to handle optional values more gracefully.

Extensions provide DSL‑style syntax and replace findViewById , but they differ from Swift extensions; a deeper comparison can be explored separately.

Vararg parameters require the spread operator ( *vars ) when passing arrays.

Conclusion

Kotlin has become stable in the author’s project, thanks to Google’s official support and community resources. By sharing these pitfalls, the article aims to help other developers avoid similar issues and embrace Kotlin confidently.