The world of mobile app development is vast and ever-evolving, with new frameworks and technologies popping up almost on a daily basis. When you think about a mobile device, you probably think of your phone or maybe your tablet, even though they are nowhere nearly as popular as smartphones.

Apple’s iOS and Google’s Android dominate the mobile market, each having had its ups and downs over the past decade. Today, I am going to talk more about Android and its use on devices that aren’t necessarily mobile.

Being open-source had a really interesting side effect on Google’s mobile operating system. Sure, we may think of all of the different Android forks from various smartphone companies, but what about all the devices running Android that aren’t mobile? Everything ranging from fridges, smart ovens, door locks, or even Point of Sale (POS) devices can run Android nowadays. The latter are the reason I ended up writing this article.

Android POS Systems

About a year ago, I got to play with an Android device that was anything but ordinary, and it’s not something most people are likely to use. The device in question is an Android-based POS system from a Chinese vendor that also has an integrated thermal printer (like the ones used to print out receipts at stores or on ATMs).

The biggest surprise, though, was its software: It was running a bone stock version of Android. If I recall correctly, at the time, it was running Android 8, or Android Oreo if you prefer Google codenames. The device itself looks like an old school portable POS device, but instead of the physical keyboard where you would enter your PIN, it sports a capacitive touchscreen like the ones used in the Android phones of yesteryear.

My requirement was easy: I had to see if there was a way we could use this device’s features such as the thermal printer while also running the app we were developing. As soon as I realized that the requirement itself was possible, another problem came to my attention: security.

The thing is, if you have a device that handles card payments and other kinds of transactions, you might not want that same device to be able to run TikTok, Gmail, or Snapchat. This device was behaving exactly like a tablet, and it even came with Google’s Play Store pre-installed. Imagine going to a small convenience store and seeing your cashier taking selfies, opening emails from a Nigerian prince, and browsing weird, malware-ridden websites.

And afterward, the cashier hands you the same device to enter your PIN. Personally, I would not feel safe about providing my credit card information over such a device.

Locking Users Out of Android Menus

Security aside, I had to take on an even more important challenge: I had to lock the person using the Android POS device inside my app. Messing with the operating system was not an option since these devices were delivered to non-technical people.

Sure, cashiers are more than able to install an application, but most of them could not flash custom ROMs or handle other lower-level operations. The app itself was written in React Native, although that is irrelevant in this context. All the modifications I made are in native Java code, so no matter what you are using to develop your main application, these tweaks should work.

As a little disclaimer, this procedure only works for Android apps. Apple does not give us the control we need to easily accomplish something like this on an iPhone or iPad, which is understandable given the closed nature of iOS.

There are four ways a user could possibly exit an application:

• Use the Home button.
• Use the Back button.
• Use the Recents button.
• Leave your app through the notification bar.

Either clicking on a recent notification or going to settings from that bar would cause a user to exit our application. You also have gestures, but at the end of the day, these gestures trigger the exact same actions as regular button presses would.

Also, having a PIN system to unlock the application can be really useful for someone to manage the device. This way, only someone holding a PIN would be able to install a different version of the application, without offering deeper access to the end user.

#android