Programming for Android is an interesting experience. One of the most annoying things I didn’t anticipate is how Android will just kill your app whenever it wants and often for no good reason (it’s a little like doing battle with a chaos monkey). This has to do with what is called the Android Activity Lifecycle.

When an app is not in the foreground (displayed on the screen) Android can, at any time, kill it. Android does this for at least two reasons, the first being that other apps might need the RAM and there isn’t enough to go around. The second has to do saving battery power. To make things even more complicated, this is one aspect of Android that is often modified by different OEMs, so that how often and for what reasons an app might be killed can vary by device.

When an app has been killed (the orange item on the left of the chart above), a small amount of data is preserved in what is known as the SavedInstanceState. When the user switches back to the app, the SavedInstanceState is passed to onCreate(), at which point it is up to the developer of an app to attempt to recreate the state of the app in such a way that the user doesn’t notice that it has been killed and restarted.

There is a surprising amount of code in Privacy Browser (and in any other good Android app) to try to successfully handle this background killing of apps. Most of the time, this works out fairly well and users aren’t aware of the magic that is going on behind the scenes to make everything run smoothly. However, in their infinite wisdom, not only did Google decide it would be a good idea to just randomly go around killing apps, but they also decided to set an amazingly small limit of 1MB for the entire SavedInstanceState. It turns out that if you have enough tabs open at once, you can exceed this 1MB limit. In which case, Android will just drop the SavedInstanceState and restart the app with no saved tab information.

Most browsers handle this by writing the information about the current tabs directly to a database on the flash storage. However, as I have written before, that is not a solution that is acceptable for Privacy Browser because I am opposed to anything that automatically stores a browsing history just by engaging in normal browsing behaviors. There is too high a probability that data written to the flash storage can be compromised for me to be comfortable with automatically populating it with a user’s browsing history.

I can understand why users can be unhappy if a bunch of their open tabs suddenly disappear. This isn’t a problem I run into in my typical workflow, because I tend to frequently run Clear and Exit. I rarely have more than ten tabs open at once, which isn’t typically enough to trigger this problem. Part of the reason why I do that is because any zero-day exploit in WebView is most likely to allow one tab to steal information from another tab, so keeping the number of running tabs small lowers my personal attack surface. I don’t have any problems with users who choose to run a lot of tabs at once, and I am happy to do everything reasonable to make it work well for them, but I won’t lower the security of Privacy Browser to do so. In that case of Google’s 1MB SavedInstanceState limit, that means that users who choose to have lots of tabs open at once will periodically discover than Android will close them for them.

It should be noted that Privacy Browser PC doesn’t suffer from this problem because desktop systems don’t tend to go around killing programs, so users can keep as many tabs open as they like. On Android, if there is a set of tabs you always like to have open there are a couple of ways to quickly open a lot of bookmarks.