Java in practice: Android, upgrades and certification interview questions
Interview questions on “Java in practice: Android, upgrades and certification”: warm-ups, then what each harder question tests and how a good answer starts.
3 questions: 1 warm-up and 2 with model answers · Levels: Fresher to senior
Warm-up questions
Short questions with short answers, each answered in full.
Fresher
What is desugaring in an Android build, and which tool does it?
What each question tests, the first step of a good answer and the follow-ups to expect.
Mid to senior
A Java library is shared by a Java 21 service and an Android app with minSdk 26. It compiles with --release 17 and its tests pass, yet the app fails on an Android 11 phone when it prints a receipt. What went wrong, and what do you add to the library's build so that it cannot happen again?
What it tests
Knowing that --release checks the Java level but not Android API levels, reading Android's API reference, and adding API-level checks and device tests to a shared library.
First step
Read the failing call in the stack trace and look the method up in Android's API reference, which gives the API level that added it. A Java 11 method such as String.repeat compiles for Java 17 and still needs API level 33, so a phone at API level 30 is not guaranteed to have it.
Follow-ups
Why did --release 17 not catch it?
How do you check every call of the library against minSdk in CI?
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
Model answer
Follow-up answers
Common mistakes
Rubric
Variants
about 3 minutes
Fresher to mid
An Android project builds in Android Studio, but on the CI server the same commit fails with "Android Gradle plugin requires Java 17 to run. You are currently using Java 11", although the module sets its Java toolchain to 17. Explain the JDKs involved and how you make every machine build the same app.
What it tests
Separating the JDK that runs Gradle, the toolchain JDK and the source and target compatibility, and pinning each so that builds are the same everywhere.
First step
The message is about the JDK that runs Gradle, not the one that compiles the code. Android Studio starts Gradle with its own Gradle JDK setting, while a terminal or a CI agent uses JAVA_HOME, or java on PATH, so the agent started Gradle on Java 11. The toolchain matters only once the plugin is running.
Follow-ups
Where does Android Studio take its Gradle JDK from?
What happens on CI when no JDK 17 is installed for the toolchain?
Why set sourceCompatibility and targetCompatibility explicitly?