SureshJoshi.com ▼

Updating Your Android Kiosk App


2015-12-29

In a previous post, I discussed the concept of making a kiosk app in Android using Lollipop or greater and the new screen pinning APIs. The next logical step is: How do I update my kiosk app?

I’ve tried and tested a few solutions, and I’ll be presenting them below

  • truthfully, there are no ‘good’ solutions, but rather ‘good enough’ solutions. If you want a true kiosk app, you’re going to end up doing more work to provision your devices - so I’m assuming all of this knowledge is more for enterprise-oriented kiosks, rather that something you want to be put in the app store and downloaded by the masses (where you cannot setup a device admin).

I’m also assuming your kiosk app isn’t something that you’re making in the millions, but rather in the thousands, where spending a few minutes provisioning each device isn’t a huge problem. Besides, if you’re in the millions, you shouldn’t be buying an off-the-shelf Android tablet to build a kiosk app on top of - do it right…

Here are the three methods I’ve tried, a step-by-step explanation, and some commentary.

Google Play Store Updates

In this method, you host your app/apk on the Google Play Store (either publicly available, or in perpetual Alpha/Beta) - and let the Play Store work its magic with automatic updates. This takes the most amount of provisioning, and might require user interaction - but it’s probably the ‘most official’ way to go.

Unfortunately, it’s a little bit messy because you need to setup a device admin for the kiosk app, which means you can’t have a Google Account setup beforehand. This means you can’t download from the Play Store directly (which would have been ideal). The workflow I’ve had that works is:

  1. Install the app on a fresh tablet using adb
  2. Setup a device admin as per my previous instructions
  3. Increment the build version and upload your APK to the Play Store
  4. Either publish it publicly, or leave it in the Alpha/Beta channel
  5. (If leaving in Alpha/Beta) Setup an open or closed Testers setting
  6. Setup a Google Account on the tablet
  7. Go to the app or the testing link and download the app from the Play Store (essentially, this is how Google Play will now know to auto-update your app on this tablet)
  8. (For verification) Increment your build version and re-upload a new APK
  9. (For verification) Wait a few hours to propagate, and check if your app has been updated

This method can be viewed as the ‘traditional’ method - but it involves a boatload of steps. And not sure if anyone caught the little hiccup in there, but you now have to provision a Google Account on every tablet you send out… But what if the IT team of the enterprise you’re delivering the tablet to wants to have their own account on each tablet? Well, you give it to them to perform steps 6-7, which can cause friction and support calls. And what if they forget? And then they start complaining about their app being out of date… Any way you slice it, it’s not ideal.

A very mild complaint I have about this method is that Google Play, even on Alpha and Beta channels takes up to 24 hours to update apps. While this is AMAZING compared to Apple and TestFlight’s crappy 2 weeks if you want to change the anything, it’s still hard to test iterations. You need to make an update, and the next day verify it gets installed… Also, customers have a really hard time understanding why updates aren’t instantaneous.

Fabric’s Beta Distribution

I cannot sing enough praise for the Fabric platform. I have used Crashlytics for a long, long time - as well as the associated Answers and such since it came out, but I only just recently started using Beta - almost as a fluke.

On one of my projects, we had a lot of people working on several feature streams on Android, and figuring out how to distribute (e.g. using Google Play) was a pain. TestFairy and HockeyApp were brought up as options… Then, just to see what it was like (and since we were all already using Crashlytics), I gave Beta a try - and holy crap was it amazingly simple.

Fabric’s IDE plugins made my life drag-and-drop, so all I needed to do was to generate a release APK, drag it into the Fabric IDE plugin, put in release notes, and add the emails for new testers (if any).

What this meant for us is that we could run multiple streams of development by changing the application ID (and app name) in Gradle, and we didn’t need to ‘create’ a new Google Play app. We just changed application IDs and uploaded to Fabric - and Fabric handled the rest for us! With the multiple app ids, we can also run multiple streams of dev or testing on any device, rather than uninstalling, or having multiple testing devices per feature stream. I now also use this for my iOS development, as I think TestFlight has become horrendous ever since Apple bought it.

The biggest plus about Beta for me is that it’s almost instantaneous! When I upload a release, usually within minutes (or faster) - everyone has access to the app.

While not perfect for the kiosk app issue, since you still need an email associated with the device (thus, probably a Google Account) - it’s easier and faster to setup, and doesn’t require the user to do much other than open an email.

  1. Install the app on a fresh tablet using adb
  2. Setup a device admin as per my previous instructions
  3. Increment the build version and upload your APK to Fabric
  4. Setup a Google Account on the tablet (or some email client)
  5. Open the Fabric email, click the link, and you have the app update
  6. (For extra verification) Increment your build version and re-upload a new APK
  7. (For extra verification) Wait a few seconds/minutes to propagate, and check if the Fabric app notifies you of an app update

Downside here? Non-automatic updates - meaning someone has to exit the kiosk mode to open the link and install the new app… Which is kinda lame… Not because someone has to click a link, but rather that they need to leave the app explicitly.

In-App Updates

This is my preferred solution, as it gives me 90% of control and the user the remaining 10% of control. It’s not reliant on Google’s propagation time or process, and doesn’t require the user to leave the app, check emails, or even have a Google Account setup!

Note: There is an option I’ve ignored, which is a private APK repo - but that just sounds like too much work for me, so I’ll avoid it :)

The In-App Updates route is pretty streamlined, and could become even more streamlined - but I explicitly like user interaction when it comes to closing, updating, and re-installing an app. The reason is that I don’t want that to happen while the kiosk is in use by a customer - so that control needs to be given to the enterprise.

The short explanation of this process is:

  1. Install the app on a fresh tablet using adb
  2. Setup a device admin as per my previous instructions
  3. Increment the build version and upload the APK to your server
  4. The kiosk app will notify the user that there is an update available, and ask if they want to install it
  5. APK is downloaded, installed, and the app is updated automatically

No emails, no Google Accounts, and the propagation time is whatever you want it to be (e.g. do you want a push notification to the kiosk? Or only when a certain login is used? Etc…)

In a later post, I’ll delve into the specific code required to implement In-App Updates for your Kiosk App!

Feature Photo credit: Christiann Macauley / Sticky Comics