

Ask HN: Locking Android Tablets - How fool proof is it? - nppc

I am the IT manager for a large retailer. We are thinking of purchasing hundreds of Android tablets for our workforce instead of low end laptops, what we used to buy traditionally. The primary use for these devices would be to capture data related to budgeting and Purchase orders and using our ERP tools.<p>As we do not want the staff to use the provided tablets for playing games and facebook and watching videos etc, we want to install AppLock (https:&#x2F;&#x2F;play.google.com&#x2F;store&#x2F;apps&#x2F;details?id=com.domobile.applock) or something similar.<p>My Question is .. Is it possible to overcome the AppLock&#x27;s Lock by fiddling with the filesystem of the device by connecting it to a PC&#x2F;Mac - other than by factory resetting the device (which will erase our in-hour ERP apps anyway).
======
Zigurd
Take a look at the device management capabilities in Android. Pick a good MDM
system that uses the standard Android APIs if you can make that work for you.
If that's not sufficient, look at what Samsung has done in extending Andrdoid
MDM, but beware of lock-in, and I'm not a fan of Samsung bloatware.

I would avoid hackish MDM. While an app can do things like block the use of
blacklisted apps, I would prefer to rely on auditing of devices to detect
undesirable apps and then to lock the device. That you can do with normal use
of standard APIs. Hackish MDM can claim all kinds of capabilities, but if the
standard device management APIs don't directly support those features, the
risk of undesirable side effects, features that invite complacency but are
easy to circumvent, and other problems become much more likely. I have not
evaluated AppLock personally, do I can't say if it's sound or not.

I have pushed the boundaries on these kinds of features myself. For example,
developing a device-based packet filter that, while it doesn't require rooting
the device, and does not rely on undefined behavior, it makes creative use of
an API that is designed for a different purpose. So if a vendor makes claims
of having capabilities that go way beyond what the Device Administration
documentation says is possible, get a good explanation of how they do it.

An example of a bad hack is that I have seen a "lockdown" app that "blocks"
the app switcher button by creating several instances of an app with a blank
name and blank screen image. That's just challenging users to break your
system (by scrolling the list of recent apps) and sneer at it. A gateway drug
to more malevolent cracking.

But if you really really need behavior that meets a hard set of specs and
Android just can't do it using standard MDM APIs, consider rolling your own
variant of Cyanogen Mod or other aftermarket Android distribution. That way
you know exactly what you are getting, and you can implement your desired
features in ways that actually work.

