Develop Reference

How can I test my app for a specific device?

I am building an application with React Native but the app not working well on a few android devices. So I need to see what's going wrong but I don't know how to set up an emulator for a specific device. Are these problems depends on phone's brand and model or it just depends on their android versions?

Its not really possible. There's two major problems:
Software. Real devices don't ship pure AOSP like runs on the emulator. They add patches and features and there's no way to know what they actually run.
Custom UIs. Many phones provide custom UIs like TouchWhiz and the like which can override Android behavior
Hardware. If your app depends on things that are very hardware specific, like GPS or Camera, they could have issues due to hardware bugs.
If you just want to emulate a specific OS version like KitKat, or specific low memory conditions its possible via emulator configuration. If you really need to test on a device, either buy one or use a service that allows you remote control over specific devices. Amazon has a nice device farm that you can rent over AWS.

One of the biggest challenges when developing for Android is the wide variety of devices and "optimizations" manufacturers make to their Android versions.
The Android emulator is based on AOSP (vanilla Android) and was only recently published with Google services included. This is the most clean version of Android. You can use the emulator to test UI scaling for different screen sizes but it will always behave like an AOSP Android. Google packs a bunch of hardware configurations into Android Studio which you can simply select when creating an virtual device. You can always create a custom hardware profile with custom screen size and resolution. Some manufacturers also change the DPI value of the OS causing the UI to be bigger or smaller, keep this in mind when creating a custom hardware configuration.
Further, you can use the emulator to test the default behaviour on different Android versions. Again, manufacturers change their Android usually causing slightly different behaviour.
I assume that your question is focussed on different behaviour of e.g. Samsung phones having crashes only occuring in Samsung phones (Samsung can be exchanged with any other brand here). Unfortunately, there is no simple way to test this but getting your hands on the faulty device. One option is to use a cloud based test lab (e.g. Firebase Test Lab, App Center or AWS device farm) to test your code on the faulty device or rent the device at a local shop. Most bigger cities have companies renting phones and tablets on a daily or weekly basis.
In the end you will need if statements checking for a specific device, manufacturer or Android version or any combination of them and doing something slightly different to fix the undesired behaviour.
I know that this is not the answer you are looking for, but it's the best I can offer. To tell a little tale of my worst experience: I had once a bug were calling a crypto function caused a kernel panic on HTC (?) phones. This means the user opened my app and the phone rebooted. I was required to implement the entire encryption logic again just for HTC with Android 6.0.

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.

Samsung KNOX compatible apps

Does anyone know how to build a test app that plays well with Samsung Knox? What do I have to so differently to build an app for samsung devices that have Knox installed on them?

From KNOX 2.0, App wrapping is not required.
This is from the Samsung KNOX 2.0 whitepaper:
The KNOX 2.0 platform features major enhancements to the Application Container from the original KNOX platform. The most significant enhancement is the elimination of application wrapping. This is achieved by leveraging technology introduced by Google in Android 4.2 to support multiple users on tablet devices. This enables enterprises to easily deploy custom applications without requiring Samsung to wrap the applications. It also reduces the barrier to entry for independent software developers wishing to develop applications for the KNOX container.
Complete White paper can be found here: http://www.samsung.com/ca/business-images/resource/white-paper/2014/03/Samsung_KNOX_tech_whitepaper_Final_140220-0.pdf
Multiple user: (Complete Ref: http://developer.android.com/about/versions/android-4.2.html#MultipleUsers)
Android now allows multiple user spaces on shareable devices such as tablets. Each user on a device has his or her own set of accounts, apps, system settings, files, and any other user-associated data.
As an app developer, there’s nothing different you need to do in order for your app to work properly with multiple users on a single device. Regardless of how many users may exist on a device, the data your app saves for a given user is kept separate from the data your app saves for other users. The system keeps track of which user data belongs to the user process in which your app is running and provides your app access to only that user’s data and does not allow access to other users’ data.

Might want to take a look through here https://www.samsungknox.com/en/blog/what-app-wrapping and here https://www.samsungknox.com/en/resources.
Looks like you have to develop the app and then send it in to Samsung to have them 'wrap' it.

Personal data on Samsung devices is protected from mobile threats such as ransomware, malware, and unauthorized rooting, even while you’re using your device.
Secure Folder
Samsung Pay
Samsung Health
Samsung Pass
Empower enterprise mobility by leveraging Samsung Knox and ensure seamless device deployment with advance security, taking device management to next level.

How can I programmatically disable automatic updates from Google? (Ice Cream Sandwich)

My company makes a tablet Android app to control an industrial process. We had been using a Galaxy Tab 10.1, but as that's no longer available in the US we're evaluating the Galaxy Tab 2 10.1, running 4.03. We ship the tablet pre-installed with our app, and the app is carefully tested with the version of Android software running on the tablet.
As I was setting up one of the new tablets the setup wizard put up a message saying "You agree that your tablet may receive and install updates from Google" It wasn't asking me, it was telling me; there was no place to say "no" or disagree. Auto update is DISabled in settings.
How can I programmatically prevent a force-feed update to the tablet? Our users are connected to a local area net because the tablets are used to control other industrial products, but there is never any need to connect to the web beyond the factory walls, but we have no way to enforce that on our customers. The risk is that Google could force a change onto the tablet that might break our app.
Thanks in advance.

How can I programmatically prevent a force-feed update to the tablet?
Build your own firmware and use that rather than the stock firmware.
The risk is that Google could force a change onto the tablet that might break our app.
The risk of blocking the firmware updates is that Samsung (not Google) could deliver an update to the tablet that fixes flaws in the firmware that your customers would appreciate (e.g., better WiFi connectivity).
Please understand that the devices that you are using are consumer devices. Such devices are not intended for use "to control an industrial process". The expectation is that if you are using Android in such settings, that you would source your own device and have control over your firmware. Alas, there is not a whole lot of support for that at the moment, something I blogged about recently.

As long as you target your desired API, an update to the system should not break any functionality of your app. To answer your question, you cannot programatically disable automatic updates, it is a user function.
Check this link as well: Programatically enable/disable market auto-update

How will using the Samsung Galaxy Tab Add-on affect/fetter my Android Market deployments?

I have run my android app against the new build target provided by the add-on mentioned here. This appears to be working correctly in the emulator, but now I am very unsure as to the implications of using this build target when delivering an app to the marketplace.
It would appear that I have to use this build target to get the emulator to work. Is this true of the device in general? (i.e.) could I build against the standard android/google APIs and have it run correctly on the actual Galaxy Tab?
If I deploy an app with this build target to the Android market, will this adversely affect other (smaller screen) devices that I already run on? (I.e. is the galaxy tab "special sauce" a superset of Android functionality? I see grumbles about the Google APIs for maps not working in it, etc.)
Will i have to have two versions of my app in the market? One for "standard" devices and one for "large" screen devices? One for the Galaxy Tab specifically?
When Android Tablet vNext (whatever that may be) comes out and has its own custom add-on and build target, will I have to clone my repository and publish/maintain a device specific version of that (presuming that any add-on special sauce for the galaxy tab will not be in vNext's add on and will not be "compatible")
What I am driving at is that I can't find reliable documentation on how an add-on like this will affect the fragmentation of my app deployment and maintenance. I want to be able to support new Android devices like the Galaxy Tab, but I don't want to be building a bunch of one-off device-specific app implementations. Isn't the point to be able to have one app work on the gamut of devices?
Thanks in advance for any insight you might have on the situation.

It's not the case that you need to use the Samsung-provided build target to deploy your app on the Galaxy Tab (definitely not the real device, and for me the emulator works fine).
I build all my projects with a target SDK of 4 (Android 1.6) and they run fine on the Tab AVD.
One implication of the advice from Samsung that needs consideration is that they want min SDK (not the same as target SDK) set to 4, which will exclude Android 1.5 devices. You probably do not really need to do this but should test to be certain.
In general with hardware vendors (Motorola, Samsung):
- do take advantage of the AVDs, especially if you don't have the budget for the real device or it's not yet available
- do not use the custom dev environment, stick with the Google standard tools.
My two cents.

It would appear that I have to use
this build target to get the
emulator to work. Is this true of
the device in general? (i.e.) could
I build against the standard
android/google APIs and have it run
correctly on the actual Galaxy Tab?
This shouldn't be required. After all, most market apps run just fine on the galaxy tab. The only problem seems to be that the GT emulator doesn't have the Google APIs installed, though AFAIR the actual device does. But I might want to check on that as soon as I get back to office.
If I deploy an app with this build
target to the Android market, will
this adversely affect other (smaller
screen) devices that I already run
on? (I.e. is the galaxy tab "special
sauce" a superset of Android
functionality? I see grumbles about
the Google APIs for maps not working
in it, etc.)
Well, I don't think so, but you should probably use one of the regular build targets anyway. The GT plugin only helps you by specifying the API version and the devices parameters, there is no special sauce involved.
Will i have to have two versions of
my app in the market? One for
"standard" devices and one for
"large" screen devices? One for the
Galaxy Tab specifically?
No, you shouldn't need to. You actually don't have to change anything in your app to make it run decently on the GT, since Android handles most of the heavy lifting. Android won't help you provide a different layout for tablets though, since they are not officially supported yet. But by looking at screen size and density, you can still choose to do so manually.
When Android Tablet vNext (whatever
that may be) comes out and has its
own custom add-on and build target,
will I have to clone my repository
and publish/maintain a device
specific version of that (presuming
that any add-on special sauce for
the galaxy tab will not be in
vNext's add on and will not be
"compatible")
Simply put, no. In the future, tablets will most likely be supported directly by Android, and, if the current state of affairs is any indication, it will provide numerous ways to help you adopt your application for all kinds of tablet devices as well, without having to fork your code.