Updating an old Android app is often less about writing new features and more about carefully moving an old build system into a modern, testable state. The safest process starts by preserving what already exists.
1. Preserve the original before changing anything
Keep a read-only copy or version-control snapshot of the source project, the last known working APK/AAB and any non-secret release documentation. Do not overwrite the only copy while experimenting with Gradle or SDK upgrades.
2. Record the app identity and release history
Before rebuilding, record the package/application ID, versionName, versionCode, minSdk and targetSdk from the current artifact. If the app already exists on Google Play, the next build must remain the same app identity and use an acceptable new versionCode.
3. Find out whether the project still builds
Open the source in an appropriate Android Studio/toolchain and try a clean build before making broad migrations. A failure here is useful information. It tells you whether the first repair is the build environment itself rather than Android 16.
4. Inventory the build system
Check the Gradle wrapper, Android Gradle Plugin, Java/JDK level, Kotlin plugin, repositories and major third-party dependencies. An old project may need these moved in compatible steps instead of jumping every component at once.
5. Install and compile against Android 16
Android’s current SDK setup guidance uses compileSdk = 36 for Android 16. Once the project can compile against the new platform, the app can be migrated to targetSdk = 36 and tested against Android 16 behaviour changes.
6. Review target-API behaviour changes
Changing target SDK opts the app into newer platform behaviour. Android 16 includes changes that can affect areas such as edge-to-edge UI, predictive back navigation and large-screen behaviour. Not every app is affected, but every app should be tested for the behaviours it uses.
7. Check native libraries and 16 KB support
If the app or any SDK includes native .so libraries, add a separate 16 KB compatibility review. A successful API 36 compile is not proof that native binaries are correctly built and aligned.
8. Test important user flows
At minimum, install and launch the build, confirm identity and resources, test navigation and core features, verify data/save behaviour if used, check permissions, ads/billing if relevant, and specifically retest every area changed during migration.
9. Build a fresh release artifact
After the source migration passes runtime checks, create a clean release artifact using the project’s real package and signing process. Do not patch a legacy compiled APK to imitate a source migration.
10. Re-check the final APK/AAB
Verify that the final artifact contains the expected package, version, target SDK and resources before uploading it.
Check the current or rebuilt APK/AAB →
When is an old project a simple update?
A project is more likely to be straightforward when the source is complete, it clean-builds with modest tooling updates, it uses maintained dependencies and it has no problematic native components. A project becomes more complex when the build is broken, source is incomplete, libraries are abandoned, native code is old or Android behaviour changes require code-level work.
This is why the source assessment determines whether the work fits Creator Quest Studio’s fixed Standard or Advanced repair tier. If the job cannot be completed safely within a supported tier, it is declined rather than given an improvised price.
Last verified: 17 August 2026
Official references
Need the facts from your APK or AAB?
Use the free Studio checker to read the important release facts directly from the compiled artifact. You do not need Android Studio or Android development knowledge.
Analyze APK / AAB →