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. ...
In MusicSync, one of the views became complex and too slow to be inflated on the UI thread. So, I decided to do some Pooling around it to inflate it on the background thread and use it on the UI thread. This made the UI snappier, reducing multiple-second load times when opening some folders. However, soon I ended up with an edge case where re-opening the activity (and not the app) led to a semi-functional app. This edge case is hard as it gets triggered only in particular scenarios where the user destroys the activity via swipe up. At the same time, the app keeps running due to the attached foreground service that鈥檚 playing the media. And on activity re-creation, I got stale views! ...
This is a story of a messaging app used by billions of users. The app followed an extremely strong model of privacy. The app never persisted the user鈥檚 data on the servers. All the communication is end-to-end encrypted. A lot of users of this app, especially, on Android would regularly uninstall and reinstall the app. Now, to prevent these users from losing messages, the messages were backed up to the user鈥檚 SD card. In the Android security model, an SD card is a public storage space, accessible to all apps. So, to keep messages private, the backups were encrypted. ...
I use Makefile for Android just like I use Makefile for my non-Android side-projects.
Android has two distinct navigation guidelines as opposed to iOS. Getting them right is nuanced.
I used to call Toast#show() on the UI thread. Then one day, I received notifications related to an ANR (Application Not Responding) error in one of my Android apps. Java 1 2 3 4 5 6 7 8 9 10 11 at android.os.BinderProxy.transactNative(BinderProxy.java) at android.os.BinderProxy.transact(BinderProxy.java:605) at android.view.accessibility.IAccessibilityManager$Stub$Proxy.addClient(IAccessibilityManager.java:1207) at android.view.accessibility.AccessibilityManager.tryConnectToServiceLocked(AccessibilityManager.java:1804) at android.view.accessibility.AccessibilityManager.(AccessibilityManager.java:606) at android.widget.ToastPresenter.(ToastPresenter.java:138) at android.widget.Toast$TN.(Toast.java:1151) at android.widget.Toast.(Toast.java:259) at android.widget.Toast.makeText(Toast.java:891) at android.widget.Toast.makeText(Toast.java:879) at net.ashishb.androidmusicplayer.util.UiHelper.showToast(UiHelper.java:111) Programmers on StackOverflow are confused about whether it is OK to call Toasts on the background threads. Just like me, they think that Toast must be displayed from the UI thread. Even though there is no reason. ...
Google released a new version of the Google Auth library. It had a bug that broke Google Login on Android for API 26 and earlier. This impacted my small but popular Music Player app in Google Play. It reveals the kind of problem, I have alluded to in end-to-end testing. The only way to avoid such problems is by end-to-end testing. However, I find all Android testing frameworks to be terrible. ...
While trying to install a custom exception handler to catch uncaught exceptions (crashes), I ended up writing
Google Play Music was great. Apart from one missing feature about the inability to upload music from the phone to the Google Play Music library, I had no other complaints. Then it was forcefully shut down.
On Android catching Java exceptions is easy via UncaughtExceptionHandler. Catching NDK crashes is a bit more convoluted. Since the native stack is probably corrupted, you want the crash handler to run on a separate process. Also, since the system might be in an unstable shape, don鈥檛 send the crash report to your web server or do anything fancy. Just write the crash report to a file, and on the next restart of the app, send to your web server and delete it from the disk. I ended up using jndcrash package for this.