1- 👤

Do you have a sharedUserId?

A sharedUserId is for sharing data, processes, and other things such as access to AccountManager between two or more applications. This might seem like something that’s kind of useless for most applications, but it’s actually very common and odds are if your app is moderately successful you’re likely to want to use it at some point. For example, some companies will end up building more than one app for their product(s), and need to share OAuth authentication and/or user information between them using AccountManager: there’s Facebook with Messenger, or Flow Tasks with Flow Chat, to name a couple.

If your app doesn’t have a sharedUserId you have a lot to lose. Not adding one to your app before launching to Google Play (or any other distribution channel) will make it impossible to add one at any point in the future through an update, since adding after an initial install will make your applications data (under /data/data/<package_name>/) inaccessible. The comments on this issue highlight just how frustrating this can be. You should also ideally have a sharedUserLabel as well which isn’t necessary, but I mention it because it nicely labels your processes.

Note: sharedUserId is defined in the Manifest of each app, and in order for it to work between both the id‘s must be the same.

So, why does trying to add this through an update break your app? In a nutshell, when you add a sharedUserId to your application it changes the UID associated with your package name on the device (same goes for removing one), which in turn causes application data to be inaccessible. This is why you can’t add it in an update, but can add it initially. Of course, you could update your app through Google Play, but all of your users would have to manually uninstall & re-install the app for data to be accessible again. Fun!

To prevent any issues in the future you should definitely add one to your app before launching—just in case. If not for you, then for any developers who might work on expanding the app down the road. There are some nuances to this though: just like an app’s package name it must be unique to your application, it should also ideally be formatted to match package name conventions so that you’ll be able to extend it to different variants (you can do this simply using strings, and Gradle flavors). Annnnd this brings us to the next topic…