Develop Reference

Is it possible to write an unremovable device policy manager for Android?

My goal is to write an application for Android (>= 9.0) which basically offers a device-owner-style control like Google's "Android Device Policy".
The following criteria have to be met:
Zero dependency on Google servers or any other 3rd party infrastructure like existing EMM solutions (MobileIron et cetera)
The user should not be able to remove or disable the app
Provisioning methods: QR-Code, NFC, URL, ADB, actually any "local" way ...
Has to work with stock androids on regular consumer devices
In short: I'd like to write an unremovable device manager (including a web-based management UI), put it on a device I own, give that device to someone else, and being able to fully control the device remotely.
Is such a project even possible with the current situation of Android?

No.
Has to work with stock androids on regular consumer devices
Mostly, this is your biggest hurdle to overcome.
What you are asking for is the description of a very powerful MalWare. An app that ca run on any version of Android, that can't be uninstalled, but can do what it wants to "fully control the device".
If you move away from the idea of "stock android on regular consumer device", towards a suite of devices you have some say in distributing:
Here is a list of Google Partners who offer an EMM solution: https://androidenterprisepartners.withgoogle.com/emm/
Here is Samsungs effort at device control:
https://www.samsungknox.com/en
Here is Googles device management:
https://developers.google.com/android/management
You could write your own ROM of Android and be able to control the things you want, but that would require .. building a ROM aka a whole phone OS forked from AOSP.
The user should not be able to remove or disable the app
This is only possible if you have a system app.
Or something extreme (which with any extreme, is always possible to have problems), like having two apps, and they monitor each other for uninstall, and programatically reinstall (vs 1 app that can't do much when it is being uninstalled).

Mobile Device Managed Single App Devices

I like to have single android app in our managed devices, we want only that app to be used on the device with necessary restriction, such that,
Single use - Device will have only one app, user can't use other apps, like browsing, youtube or anything,
the initial setting like notification sound, GPS always on, notification and ring sound maximum level can't be modified.
user can not power off the device.
this setting can only be changed by our servers.
i think i have 2 option,
1) Using samsung knox sdk on samsung devices,
Here's MDM proving feature of Samsung Knox Standard!
2) General Android way, Set up Single-Purpose Devices, COSU solution
Android Developer's site.
Wanted to know your's view on this, may be if you guys have done any of the two or any other ways, i could use some of the guidelines or a path.
Thanks for reading, and please comment if i was unable to articulate the subject or it needs editing.

You can use Google's new Android Management API, it seems to suit your needs.
It is a new cloud API that allows to manage Android devices from a server, without having to build an on-device agent (a device policy controller).

I have broad experience of using Samsung Kiosk Mode from Knox Standard SDK which is free and Pro-Kiosk mode from Knox Customization SDK (which has more functions but is not free).
So I can tell you for sure that all 4 points that you have mentioned can be achieved by using Knox Standard SDK.
Singe Purpose: https://seap.samsung.com/api-references/android-standard/reference/android/app/enterprise/kioskmode/KioskMode.html
LocationPolicy (you can turn on GPS and restrict changing): https://seap.samsung.com/api-references/android-standard/reference/android/app/enterprise/LocationPolicy.html
Yes. It is possible but I forgot the exact implementation.
Yes, as well.
Only downside of using this SDK is:
You are tied to Samsung (which I personally okay with, since Samsung has such market penetration and you could get service almost anywhere in the world and in enterprise world it is critical)
About Android native functionality: never tried it
Update March 7, 2019: Now I am playing around Device Owner, we use it for Kiosk mode, works well and works on android Device with Nougat and earlier.

Programmatically disable Android OS upgrades?

We are the software development department of a company that makes industrial equipment and we have some Samsung Galaxy-Tab 4 tablets that we use as "remote controls" for the manufacturing equipment, using an app we wrote ourselves for the purpose and installed directly from Android Studio. This app is not distributed to other devices. We bought these tablets online, right out of the box from Samsung, i.e., there is no phone company or common carrier involved. These tablets are not registered with Google, i.e., there is no gmail account associated with them; in fact we can't even access Google Play with them. I unboxed these tablets myself and never registered them with with Google or Samsung.
So I was surprised when I came in this morning and saw a notice on the screen of one that a scheduled software update has been downloaded and was ready to go. It says it's 876.87 MB and it wants to do an OS upgrade to Lollipop.
I have no idea where the upgrade is coming from or how it's initiated. My concern is that if this happens at a customer site or trade show an unexpected upgrade could break our software or cause other mischief. Is there a way I can programmatically disable software upgrades?

As an app developer, no you cannot control firmware upgrades. They come from either the carrier, or if it's a wi-fi tablet, the manufacturer.
Your only option is to control the firmware. That means building your own firmware dist of Android for your chosen hardware. You can then disable (or otherwise control) the firmware update schedule / process my making changes in the firmware.
Owning the firmware is a very big deal compared to deploying an app.

I was surprised when I came in this morning and saw a notice on the screen of one that a scheduled software update
as a software developer I cannot understand your surprise. It's a very well known (and often criticise feature due to slow/delayed roll out) feature of the OS
I have no idea where the upgrade is coming from or how it's initiated
Those come from the device manufacturer (you said Samsung, right?) and do not need a login or account of any type. It's coded somewhere deep inside the OS to check the manufacturer server for updates. Same that happens with Windows, Mac OS, Linux or iOS.
There is absolutely nothing an app can do to disable the OS update from an API point of view. This would be a major security flaw. One can easily imagine a malicious app exploiting a known OS vulnerability and blocking the OS from update itself that would patch the vulnerability.
possible solutions for your case
Apart from creating your own custom OS to control the process the only possible way that I can think of, is to host your own VPN server that blocks the update server (or blocks the whole internet expect the resources you want to access from your app) and configure the device to this VPN under Settings -> WiFi.
ps.: I saw the mentioned link and I would advise against disabling system services (or at least test A LOT after you diable it) because that could cause other issues.

Android Tablet or iPad for Kiosk Device

We want to place a device in a store that operates as sort of a kiosk device. As in customers walk up to it and start interacting with our custom app. The app could be developed for Android or the iPad, so I'm trying to decide which one to use and would like comments on the following ideas:
Is it possible for Android or iOS to access services over the USB port? This would enable us to disable the network.
Is one particularly better for 24 hour always on?
I like the iPad as I think its supply will be more constant as we move forward and need to replace devices due to ones gone bad. Also, our app will probably work on future generations of the iPad. With Android, I'm not sure there will be that sort of consistency from the tablet vendors.
Kiosk mode? I think with the iPad by putting it in a kiosk case that removes access to the home button and turning on the restrictions we'll get what we want. What about Android? I'd rather not have to get into rooting devices and replacing their firmware.
Remote control? Any way to remotely control iOS or Android in a standard means? Our app will be a client to a master server which will obviously be able to control the app somewhat (when used purely as a display device to a customer, controlled from behind the counter).
My feeling is that neither Android tablets or the iPad is best suited for this. Are there other options?

I will try to answer your points, but know that I am probably biased towards Android, because that is where my experience lies.
With Android 3.1+, at least with the Xoom, you have full USB host capabilities. Things like USB flash/hard drives, keyboards, mice, even digital cameras, all work. If you need custom interop with a USB device, you could go as far as to write a driver for it.
24 hour always on is not good for any device with a battery, but neither is better in this situation.
While android apps are forward-compatible, bad programming practices and/or deviations from "vanilla" Android software and hardware CAN break forward compatibility. That being said, if you grab a Google Experience device like the Xoom, you won't meet as many surprises.
In Android 3.0, the navigation bar is built-in at a low level, and it is not possible for apps to remove it. Therefore, it is trivial for anyone to break a "software nanny."
I know that it is possible to control android devices remotely, but without knowing your specific needs, I can't really offer more information than that.
Good luck!

iPad NOOO believe me I am a convert to Apple for my home and business but when we went to launch kiosk the iPad FAILED Big Time.. Here are a couple of little (Big) issues we ran into.
If the device reboots you cannot auto launch you iPad app since Apple does not allow that.
There is a serious memory leak in the iPads browser. We were running javascript / CSS3 and it cratered intermittently. I literally spent 2 hours "today" on the phone with Apple getting the MAJOR run around. I finally said let me speak to an Enterprise Sales Manager as my project could mean thousands of iPads and I got NO WHERE. One Apple employee even told me they don't have enterprise sales managers.
If those weren't enough even though we are just in the proof of concept phase, we are already getting request for other options. These other options are going to require access to the OS which Apple yea right. We are moving to Android immediately.
Sorry Apple I love you but you loose here.

If your using an Ipad you should consider if it can support the power for the USB thing. Watch this Using Powered USB Port

Your idea about putting the tablet behind another piece of glass/plastic is neat. To then deal with remote controlling, you might consider doing some Bluetooth programming.
My mobile development has been primarily with iOS, so I am biased toward that SDK. I will mention that the data/sync/charge port for iOS has (I believe) never changed. Your Gen 1 iPhone sync cord works on your iPhone 4... and your iPad or iPad 2. So, in terms of third party hardware, you may see more consistency with Apple.
I haven't found a good answer regarding whether it is easier to do Bluetooth programming for iOS or Android, but I think to stay cost-effective, you might see which one is more open to third-party devices. Here is an SO post/answer about iOS and third-party Bluetooth devices; I've not found anything on Android regarding third-party Bluetooth remotes, but considering a lot of hardware running Android is third-party, your chances from a naive perspective seem pretty good. Here's the Android Bluetooth API.
Buying an iOS or Android handheld to remote control an iOS or Android tablet does seem a bit steep, but then again, maybe not. Cost also depends on your ratio of remotes to tablets. 1:1? 1:N? N:1? N:M?
The lowest end iPod goes for $229 as of May 20, 2011. Android does have more variety in terms of hardware. You may be able to get a cheap Android phone with no service plan to act as a Bluetooth remote for an Android tab.

I have provided a solution for the kiosk mode using iPad here Lock-down iPhone/iPod/iPad so it can only run one app
I am afraid that I don't really know for Android if the same thing is possible.
To address the issue of crashing applications you can use an exception trampoline (see discussion here https://blog.compeople.eu/apps/?p=275) to catch the crash and reboot your app.
If the entire device is restarted however then other apps that are on the device can be started and will subsequently be locked in.
To answer your other points:
You can use a configuration profile to control network access. Force it to use a VPN or Proxy that only allows your custom app with embedded credentials to use. That way other network access can be prevented.
Your concern over future compatibility is spot on. The Android marketplace is so fragmented then maintaining a fleet is difficult.
If you have an app that is behaving as a server and is locked in then remote control is possible.

We manufacture tablet kiosks that support both android and iPad devices. In fact we are the only iPad kiosk that has achieved apple approval.
Generally speaking i think you will have an easier time with an iPad as the software and hardware will remain more consistent over time. Which is important if you have to change out a fault unit or deploy more kiosks 6 months or year from now when the original device is no longer manufactured.

Android Emulator vs Real Device

What are the differences developers should be aware of?

I am aware of these limitations:
Pre-installed software. Real device can have preinstalled a lot more applications than emulator.
You cannot use "capture" photo/video functions in emulator.
According to emulator documentation, its limitations are:
The functional limitations of the emulator include:
No support for placing or receiving actual phone calls. You can
simulate phone calls (placed and received) through the emulator
console, however.
No support for USB connections
No support for device-attached headphones
No support for determining network connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insert/eject
No support for Bluetooth
IMO you can use emulator to simplify UI development, to view UI on "device screen", to be sure that app layout is ok, app can be run, you can test some special cases by simulating gps position, network speed or messaging etc. But testing on real device is a must.

With the 1.5 SDK the following limitations exists (from the SDK website):
No support for placing or receiving actual phone calls. You can simulate phone calls placed and received) through the emulator console, however.
No support for USB connections
No support for camera/video capture (input).
No support for device-attached headphones
No support for determining connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insertion/removal
No support for Bluetooth
No support for Multitouch
Based on experience I've noticed the following differences in actual developemnt:
There are bugs you'll be able to ignore in the emulator that will crash the device (not closing Cursors for example)
You interact with the device differently than the emulator. I use landscape mode a lot more with the real device than I do with the emulator.
There's a different CPU. Things that are fast on your emulator will be slower on the real device.
You can dogfood with the device. It is harder to dogfood with the emulator.
There is a google group here if you need real device testers.

One cannot test touch events with emulator which has to be tested only by means of mouse clicks on emulator which any developer going to develop an application based on touch screens should be aware of.

I'd say the main thing is that there are several "real devices" currently using Android, and there will be more, with different hardware endowments -- some will have GPS and some won't, ditto for touchscreen, real keyboard as opposed to virtual on-screen one, camera resolution, etc, etc.
While the OS will do a lot of the heavy lifting for you, you still want to make sure your design a user experience that makes sense on every Android device you intend to support, despite the variation in their HW features -- in this sense, designing applications for Android is more similar to designing them for, say, Linux, Windows, or the Web (cater for a wide variety of hardware-configuration details), rather than e.g. Macs or iPhone (where you need to consider a much narrower set of possible HW configurations).
The emulator is (or tries to be;-) "one" Android device -- but there will be others ("real" ones;-) with different screen resolutions, input peripheral devices, etc, etc...

One comment regarding google accounts: With version 8 of the google APIs for Android 2.2, you can add a google account on the device. However, it will only allow authentication for tests of the google APIs (e.g. google documents) but not syncing of contacts etc.

This is a bug, since camera and video support was attempted (incorrectly): the camera and video intents do not store their output in the MediaStore database after "capture."

In simple terms, an emulator is a device that runs on your computer (as software) whereas a real device is something you can hold. There will of course be a few differences between the two such as some device-specific features won't be available on the emulator.
Edit: Removed a link from the answer that had expired.