How to update an old Android app so Google Play accepts it again

Android25 October 20269 min read

A practical order of work for bringing an older Android app up to the current target API level without breaking it for existing users.

Upgrading an old Android app goes smoothly when it is done in a sensible order and badly when someone changes the target SDK first and then fights the errors. This is the order we use.

1. Make sure you can build the app at all

Before anything changes, get the current code to build and run on a fresh machine. Projects that are two or three years old often depend on a specific Android Studio, a local file, a keystore on someone’s laptop or a library that has been deleted from the internet. Finding this out first saves a week.

Locate the source repository and the signing key, or confirm Play App Signing is enabled so a new upload key can be issued.
Record the versions of Gradle, the Android Gradle Plugin, Kotlin or Java, and your minimum, target and compile SDK.
Run the existing app on one old and one new phone and note what already misbehaves.

2. Take stock of dependencies

List every library the app uses. For each one, check whether it is maintained, which version is current and whether it supports the new target. The usual trouble spots are advertising, analytics, payment, push notification, maps and social sign-in libraries. A library that has not been updated for two years is either replaced or removed.

3. Upgrade the build tools

Move Gradle, the Android Gradle Plugin, Kotlin and AndroidX to current versions in small steps, building after each. Older apps may also need migrating from the support libraries to AndroidX, and from deprecated build syntax to current Gradle conventions. Do this before touching the target SDK so that errors have one cause at a time.

4. Raise compileSdk and targetSdk to 36

Now change the numbers. The build will complain about removed or changed APIs, and these are fixed one by one. This is also when Android’s behaviour changes start to apply to your app.

5. Fix the behaviour changes

Edge-to-edge: content now draws behind status and navigation bars, so toolbars, buttons and bottom sheets need window insets handled.
Back navigation: custom back button handling moves to the current back dispatcher and predictive back support.
Permissions: notifications, photo and media access, location and exact alarms each have newer rules, and the permission prompts and declarations must match.
Background work: services, alarms and background location are limited. Move work to WorkManager or a properly declared foreground service.
Large screens: layouts should adapt on tablets and foldables instead of assuming a portrait phone.

6. Handle native libraries and 16 KB pages

If the app includes .so files, check that they are aligned for 16 KB memory pages. Update the SDKs that ship them, rebuild your own native code with the current NDK, and test on a 16 KB emulator image.

7. Test properly

Test every main flow on at least one Android 8 to 10 device, one Android 12 to 13 device and one Android 15 or 16 device. Pay special attention to login, payment, notifications, camera and file uploads, which are where upgrades most often break things. An existing user updating from the old version must keep their data and stay logged in, so test that upgrade path as well as a fresh install.

8. Update Play Console declarations

Review the data safety form, the permissions declarations, the privacy policy link and the content rating. Declarations that no longer match what the app does are a common reason for rejection.

9. Release gradually

Upload to an internal or closed testing track first. Then release to production with a staged rollout, starting at a small percentage while you watch crash and ANR rates in Play Console and Firebase Crashlytics. Increase the percentage only when the numbers stay clean.

A staged rollout turns a risky release into a boring one, which is exactly what you want.

Questions people ask

How long does it take to update an old Android app?

A small app with maintained libraries can take around a week. An app with many screens, old SDKs or native code usually takes two to four weeks, including testing.

Will my users lose their data when the app updates?

They should not. The update keeps the same package name and signing key, so local data carries over. This is tested explicitly before release.

What if I do not have the source code?

It depends on what you have. With only the published app, the code can sometimes be partly recovered, but a rebuild is often more reliable. An audit will tell you which route is sensible.

Should I rebuild instead of upgrading?

Upgrade when the app is structurally sound and the code is readable. Rebuild when the code is missing, the framework is abandoned or the cost of repair is close to the cost of a clean build.