Google’s Associate Android Developer exam was unusual among entry-level credentials: instead of asking only for definitions, it asked candidates to work in an Android project, change functioning code, and demonstrate the consequences of those changes. That made it a useful case study in practical software assessment. It is now a retired exam. Google’s certification page says it no longer accepts new registrations. Readers should not follow old instructions to install an examination plugin, reserve an eight-hour assessment, arrange an exit interview or purchase preparation materials for an upcoming sitting.
The original assessment still illustrates why Android employers examine completed work rather than trusting a checklist of API names. Its historical rules, the skills behind them, and the current ways to demonstrate those skills must be kept separate. Existing credential holders should use Google’s notice for credential validity; people learning Android now need an application, tests, a record of architecture decisions and evidence that they can maintain production code.
What made the old practical examination different
The retired assessment operated on a provided project. Candidates were expected to understand an unfamiliar codebase before adding functions or correcting problems. That requirement matters because most development work begins inside another person’s application. The difficult decision is not whether a feature can be written, but which existing component should own it, what contract must stay stable, and how a change could break a different screen.
Historical descriptions of the exam mentioned an Android Studio environment, restricted project changes, timing constraints and a review procedure after coding. Those are descriptions of a former examination, not an available booking route in 2026. Some old articles describe a Java-only rule and particular grading mechanics; those details should not be repurposed as present-day Android development requirements. Modern Android work routinely includes Kotlin, Jetpack Compose, existing Views and Java components, depending on the project’s age and architecture.
Read an inherited app before touching its interface
Imagine inheriting a field-service application that shows jobs, caches assigned work orders and lets technicians attach photographs while disconnected. Before changing a screen, inspect its build configuration, navigation, dependency injection, network client, local database, background-work components and test coverage. Sketch the direction of data: server response to repository, repository to local store, local store to UI state, and user action back through a validated command path.
Then choose one bounded improvement. For example, add a visible sync status and prevent duplicate uploads when the user taps twice on poor connectivity. This requires identifying the unique work-order key, the queue’s retry semantics and the UI’s lifecycle, not just drawing a new button. A reviewer can assess your design by reproducing a duplicate request, rotating the device and restoring connectivity after the process has been killed.
Lifecycle correctness is a behavior, not a library name
A ViewModel can retain screen-level state across configuration changes, but it is not a permanent background worker and does not guarantee survival after process death. The useful question is which state must survive rotation, navigation, termination, or an operating-system-initiated restart. Temporary selection state, durable user work, network request status and server-authoritative records have different owners.
For a long-running upload, durable work scheduling and idempotent operations matter more than keeping an Activity alive. For a form, deliberate state restoration prevents a user from losing edits. For sensitive information, avoid logging private field values and ensure cached data follows an explicit retention and sign-out policy. Test these behaviors with airplane mode, repeated taps, process recreation, expired credentials and denied permissions. A clean architectural diagram has little value if the user still loses a day’s work.
Room, repositories and offline decisions
A locally cached list can improve responsiveness, but being offline-first involves consistency decisions. Decide what the user may read without a network, which writes can queue, how conflicting edits are resolved, and when a stale record must be flagged. Room can provide a structured local persistence layer, while repository boundaries keep the UI independent of where information originates. These components do not automatically produce conflict handling or safe synchronization.
Build a narrow test matrix. Start online and cache data; restart offline; edit the same record on another device; reconnect; observe whether the original action is retried once or multiple times. Inspect how server timestamps, version identifiers and per-request idempotency keys are used. If a conflict needs human resolution, tell the user which version will win before applying the change. An interview discussion of these trade-offs demonstrates more development judgment than reciting a database annotation.
Choose Compose or Views according to the codebase
New Android UI work often favors Compose, but a professional working on a maintained Views app should not rewrite stable screens simply to display a new framework on a portfolio page. Evaluate the existing navigation and accessibility model, release schedule, testing infrastructure and ability to isolate a new component. A gradual migration may be appropriate; a sweeping rewrite introduces regressions that have no relationship to the requested feature.
Regardless of toolkit, validate screen-reader labels, focus order, touch target sizes, text scaling, color contrast and loading/error behavior. A connected emulator running one screen is not enough. Use at least a small and large device profile, rotate where relevant, switch languages and test with assistive technology. A concise defect report explaining what failed, how you reproduced it and how you retested it is stronger evidence than an image of a polished home screen.
Build a portfolio that a reviewer can run
Select a project with one concrete domain problem—equipment checkouts, appointment check-ins or a shared household inventory—rather than ten unrelated demonstration screens. Include a small setup guide, a realistic data model, an offline failure scenario, a test plan and a short architecture decision record. The repository should make it clear which behavior is guaranteed, which assumptions simplify the demonstration and what would have to change for production scale.
Add tests that reveal boundaries: a repository test for conflicting updates, a UI test for preserving an unfinished form, a validation test for malformed server data and an integration test for duplicate submission. Explain one trade-off you rejected. Perhaps you decided not to cache photographs indefinitely because of privacy, or not to adopt a new UI stack because it would delay a reliability fix. Good engineering is visible in what you refuse to change as much as in what you implement.
Review privacy and accessibility as production requirements
A strong example project should make its data-retention behavior explicit. Decide whether personally identifiable information is allowed in diagnostic logs, how cached records are cleared after a sign-out, and what a technician can see when the device is shared. Use a test profile containing fake sensitive data so that a reviewer can inspect logs and backup behavior without exposing any real person’s information. Permission denial must lead to a reasonable fallback, not a crash or an endless request to grant access.
Accessibility needs its own test cases. Add a screen-reader description for actions whose icons have no text, validate the reading order after an error appears, and test whether a magnified interface still allows form submission. Dynamic content may require a status announcement rather than only a color change. These issues are easy to miss when the developer tests with one device and full vision. They matter more to customers than whether the developer can list every API introduced in a particular Android release.
The review should conclude with artifacts: a short threat or privacy boundary note, an accessibility checklist with test observations, and a list of known limitations. Rather than claiming a portfolio app is ‘production ready,’ show how its behavior was checked and what remains unproven. That distinction is the clearest continuation of the practical spirit that made the former Google assessment useful.
Show the work without pretending the credential still exists
When applying for an Android role, describe the shipped feature and its observable behavior. A useful project summary might say: Implemented a retry-safe offline work-order queue with process-restart recovery and tests for duplicate submissions. It should say what was verified, not promise universal reliability. If you hold the historic Google credential, describe it accurately as a credential earned during the program’s lifetime; do not imply new candidates can enroll today.
A technical interview can recreate the most important part of the former practical examination without repeating its old mechanics: read a supplied codebase, locate a defect, make a limited change, test a failure mode and explain the result. The lesson worth retaining from the retired exam is that maintainable Android work is assessed by behavior under change. The exam itself is history; that engineering discipline is current.