Lessons Learned from Maintaining Real Android Apps

An app that isn't maintained decays: it gets removed from discovery for targeting old APIs, breaks on new Android versions, and accumulates security issues in old dependencies. Maintenance isn't glamorous, but it decides whether an app lasts five months or five years.

Lesson 1: Budget for the yearly Android cycle

Each new Android version brings behaviour changes (permissions, background limits, edge-to-edge, foreground service types). Read the "behaviour changes" pages for each release and test early.

Lesson 2: Small, frequent dependency updates beat big jumps

• Update a few dependencies at a time, with tests and release notes reviewed.
• Use a version catalog, and automate update PRs (for example with a dependency bot).
• Remove unused libraries. Every dependency is maintenance, size and a potential security issue.

Lesson 3: User data outlives your code

• Every Room schema change needs a migration, tested from every old version still in use, not just the previous one.
• Never use destructive migrations for user-created data.
• DataStore and preference keys are contracts. Rename carefully, with migration code.
• Server APIs must remain compatible with old app versions for a long time, since users update slowly.

@get:Rule val helper = MigrationTestHelper(
    InstrumentationRegistry.getInstrumentation(), AppDatabase::class.java,
)

@Test fun migrateAllVersions() {
    helper.createDatabase("test.db", 1).close()
    // Run all migrations to the latest version and validate the schema
    Room.databaseBuilder(ApplicationProvider.getApplicationContext(), AppDatabase::class.java, "test.db")
        .addMigrations(*ALL_MIGRATIONS).build().apply { openHelper.writableDatabase.close() }
}

Lesson 4: Devices are more diverse than your test lab

Manufacturer customisations affect background work, notifications, camera behaviour and permissions. Use Android vitals breakdowns by device to spot patterns, and keep a small set of popular devices from your user base for testing.

Lesson 5: You can't fix what you can't see

• Crash reporting with readable stack traces (mapping files uploaded) from day one.
• Non-fatal logging for important failures, plus breadcrumbs.
• Staged rollouts with clear halt criteria.
• Remote config or feature flags to disable broken features without a release.

Lesson 6: Write things down

When the original developer leaves, undocumented decisions become mysteries. Keep a README for setup, architecture notes, a release checklist, and short decision records. See Scaling Across Teams.

Lesson 7: Support is part of the product

• Make it easy to contact you from inside the app, with diagnostic info attached (with consent).
• Reply to reviews, since many issues surface there first.
• Keep a known-issues list and update release notes honestly.

Maintenance calendar

Frequently asked questions

Conclusion

Maintainable Android apps plan for the yearly platform cycle, update dependencies in small steps, treat user data and API compatibility as long-term contracts, invest in observability and documentation, and treat support as part of the product.

Next step: plan your next project realistically with How to Plan and Estimate Android App Development.