There was recent news about 47% decline in the number of apps on Google Play Store.

As a hobby Android developer, who has been developing MusicSync , a Google Play Music + Podcast replacement for the last five years, I thought I would share my experience of maintaining an Android app. And why this reduction in the number of apps is not surprising to me.

I have several side-projects that run on a backend server with a limited web UI, and it is much less effort to maintain them.

However, maintaining an Android app as a side-project is a more involved affair. And here are some of the problems I have faced.

Java vs Kotlin

Kotlin is clearly the preferred language of development if you are starting a new Android project in 2025. But what if you are maintaining a hobby project written in Java? You will start seeing incompatibility when your dependencies are re-written in Kotlin.

• If you depend on a library that uses Kotlin’s coroutines or relies on Kotlin’s suspend functions , then you will have to work around it, or rewrite your app in Kotlin as well!
• Jetpack Compose, an official Google UI library for Android is entirely unusable from Java.
• I would imagine that if you started with Kotlin first then a big chunk of StackOverflow questions written for Java audiences require you translate them to corresponding Kotlin code as well

To their credit, Android documentation still gives code samples in both Java and Kotlin.

Google makes breaking changes to its libraries

Google has a habit of making breaking changes to its Android libraries. Here’s a list of some of the libraries that I have used in my app and the issues I have faced.

Media 3

Android ships with MediaPlayer .
Google recommends its open-source library ExoPlayer .
ExoPlayer V1 was last released in 2017.
It was replaced with backward-incompatible ExoPlayer V2 which was last released in July 2024.
And now, it has now been replaced with backward-incompatible media3 .
The Google provided migration script is far from being complete.

Further, media3 does not follow semantic versioning, minor version upgrades has resulted in breaking API changes.

Google Auth library

Google’s own Auth library had a bug and sign-in was broken for API 26 and lower for months .

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

java.lang.NoSuchMethodError: No virtual method getAndSetObject(Ljava/lang/Object;JLjava/lang/Object;)Ljava/lang/Object;
in class Lsun/misc/Unsafe; or its super classes
(declaration of 'sun.misc.Unsafe' appears in /system/framework/core-libart.jar)
  E  at com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper.gasWaiters(AbstractFuture.java:1394)
  E  at com.google.common.util.concurrent.AbstractFuture.releaseWaiters(AbstractFuture.java:1110)
  E  at com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:1000)
  E  at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:783)
  E  at com.google.auth.oauth2.OAuth2Credentials$RefreshTask.access$400(OAuth2Credentials.java:600)
  E  at com.google.auth.oauth2.OAuth2Credentials$RefreshTask$1.onSuccess(OAuth2Credentials.java:617)
...

Dropping support for older Android versions

Google Ads library v24 dropped support for Android API 21.
According to official Google statistics, API 21 is used by 0.1% (~4 million) users.
The rationale behind this has been left unexplained.

Upgrades for the sake of it

Material 2 was deprecated for Material 3. No clear migration guide was provided. I tried to upgrade and some components like Sliders won’t look good. Why? I don’t know, and I was never able to figure out the mystic. It does not help that most documentation now refers to Jetpack Compose which I cannot use!

So, for the near term, Java-based codebase are likely stuck with Material 2.

The UI design guidelines for Android evolve unpredictably

• Bottom bar, a featured popular on iOS was discouraged and then became a standard feature in Material design.
• Back and up buttons used to behave differently and now they are supposed to behave the same . I only learnt about it last year when I posted about it on Reddit.
• You might think that you can just use Material Design components and be done with it. But migrating from one version of Material Design to another is not trivial either. And before you migrate from Material 1 to Material 2, Google deprecates it for Material 3.

Google makes breaking changes to Android platform

Every major release of Android makes breaking changes that requires developer effort

• Toasts use to work for quick notifications, now, after API 31, it only works if the app is foreground. How to know if you app in foreground? You have to use ActivityLifecycleCallbacks for that and write ton of code and even then there are confusions about onStart vs onResume .
• Displaying notifications didn’t require permissions, now after API 33, it requires POST_NOTIFICATIONS .
• Storage permissions were either all or none, now API 33 onwards , they can be fine-grained at the level of audio, video, and images.
• Background code execution restrictions keeps changing subtly in every release.
• Media notifications were changed in a backward-incompatible in API 33 onwards. This long thread explains the pain of a lot of developers.

Crucial third-party libraries have been deprecated

Several popular third-party have been deprecated or are no longer maintained.

Picasso

Picasso was great for image loading and has been deprecated . It has been replaced with coil but the upgrade is not trivial.

Glide

Glide an alternative to Picasso was last released in Sep 2023.

OkHttp

OkHttp which even Android uses internally for implementing HttpURLConnection has not seen a stable release since Oct 2023, the last stable release was 4.12.0 and even the last alpha release was in April 2024.

OkHttp 4.12.0 does not support Happy Eyeballs which is a major issue with IPv6 networks.

EventBus

EventBus was the de-facto event passing library for Android. And it is unmaintained now.

RateThisApp

RateThisApp was good to get app ratings, and then it was abandoned.

I don’t blame the maintainers here. If you use an open-source library, you have to be prepared for the fact that it may not be maintained. I am just pointing out, how some of the obvious boilerplate tasks that one requires for building an Android app are suddenly in a limbo.

Two different versioning schemes for everything

Android has two versioning schemes , Android API version is for developers and Android version for marketing.

For example, Android 11 is API 30, Android 12 is API 31 as well as 32(!), Android 13 is API 33, Android 14 is API 34. The developer documents would reference one scheme or the other or sometimes both! And you are supposed to memorize the mappings while trying to debug issues using GitHub issues or StackOverflow. It just adds unnecessary friction and confusion.

Forced upgrades

There are multiple versions in an Android app, all tightly coupled with each other.

• minSdkVersion and targetSdkVersion of the app
• Java sourceCompatibility and targetCompatibility
• version of dependencies
• version of Android build tool chain
• version of Gradle
• version of Android Studio

You might think that all updates are optional, but they aren’t

• Gradle and Android Studio must be upgraded together for version-compatibility
• Upgrading Java sourceCompatibility and targetCompatibility requires upgrading Gradle (and hence, Android Studio)
• Upgrading Android build tool chain requires upgrading minSdkVersion and targetSdkVersion
• Upgrade Android build tool chain requires upgrading Gradle version
• Also, if you want to stay on an old library like Exoplayer V2, sooner or later, it will become incompatible with other dependencies, and you will be forced to upgrade to media3!

You see how you are forced to upgrade almost everything or nothing?

And what if you decide to not upgrade any of these? Well, your app will get delisted if the minSdkVersion is too old.

Conclusion

Compared to server-side development, Android development requires a bit more efforts to maintain. So, if you are planning to build an Android app as a hobby, keep the ongoing maintenance cost in mind.