I am using the default simulator, Can I make simulator identical to some common device
I mean one identical to HTC, one identical to droid motorla, one of samsung, dell, acer,..etc
Here identical I mean all the features that it provide.
Thanks
Yes labbeb Brother, you can download the various devices skin as Htc, samsung and mortolo droid from the following url
http://teavuihuang.com/android/
and unzip the skin which is downloaded and put in the android sdk directory/platform/android3/skins.
Like that do the same for android4,7,8 too
These different devices can be determined by the sets of capabilities that they have as well as which version operating system they support. That's what the "Android SDK and AVD Manager" is for. When you create a new device in the manager, you can select the target API version, screen resolution, and hardware supported in order to emulate a certain type of phone.
For instance, if I was developing on an HTC Hero I would want to ensure that I specify the target API as Android 2.1-update1 - API Level 7 since it is the highest that the Hero supports without a custom ROM at the moment.
Another example is the upcoming Motorola i886. It is an Android OS phone that does not have a touch screen, so for it's hardware you would add the property "Touch Screen Support" = "No".
Generally speaking, a simulator is just that -- it can't provide full and true emulation of the target hardware. To get all features, nuances, bugs, skins, add-ons, pre-installed apps, and whatnot that the target hardware comes with you must acquire the target hardware. There's no full-proof alternative to this yet.
You can, however, simulate many of the important characteristics of the target device. Tilsan linked to a good resource for downloading a whole bunch of skins. You can create your own, too (see
http://mobile.tutsplus.com/tutorials/android/common-android-virtual-device-configurations/).
The default or generic simulator is to display the general functions and may not be specific to any present or future model in the final form. Only authorised developers, manufacturers and industry organisations like OHA the open handset alliance are permitted to develop for specific models as some of the internal hardware including the processor may be proprietory or patented for use in specific countries and open access to the internals could be a breach of rights protection. When using API and APP type environments as application programmers and hobbyists then the development kit can be specific to models and is provided by the brand name or manufacturer by download or on CD and is a concession to the user community.
Related
Can I test my AOSP built (Custom Os) on redmi5a phone (rooted)? And How (Explaination will be appreciated) ? Does it requires some specific built?
Usually, Android build for a specific device includes a huge amount of modifications by SOC vendor and OEM (OEM is Xiaomi in your case).
AOSP is a general SW project. And every device model has a different HW.
OEMs integrate SoC and board-specific SW drivers and configs into AOSP to make it run on a particular device.
Most probably you can't get access to the device-specific parts.
So the simple answer is: you can't make this kind of test.
AOSP vs Android:
The AOSP contains everything developers need to build Android but it doesn’t include everything you need for a finished smartphone. First, Google and the AOSP can’t provide kernel device drivers for every hardware configuration out there. By device driver, we mean the firmware required for a phone’s hardware, such as the processor or cameras. Phone and SoC manufacturers, such as Qualcomm and Samsung, have to incorporate these drivers into their Android build. This is partly why updates take time to trickle down from AOSP to the smartphone in your hand.
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.
How come Android Studio only provides Nexus phones in "Device in Editor" instead of Samsung?
I just downloaded Android Studio this week. Here's the phones available in "Device In Editor":
When I go to "Create New Virtual Device", again only Nexus Phones are available, no Samsung. What's going on?
Also, why is the PLAY STORE check only for the Nexus 5X and Nexus 5 devices. Why not any newer devices?
The purpose of the devices in 'device in editor' is not to cover every existing phone. Rather, it is to offer a spectrum of various screen sizes, densities, ratios, etc. So it really does not matter what type of device it is, as long as there is a diverse set of devices and screens offered (which there is). As for the play store thing, I am not sure.
The short answer is because Google isn't Samsung. Why aren't there LG configs in the Device Editor? Or HTC? Because there are thousands of devices and it would be impractical to manage, even if those OEMs provided the info. Fortunately, they don't need to be pre-defined in there because you can configure your own AVD with any resolution, memory config, etc, to create any device you need to emulate. More or less.
Of course, there's more to it than just defining the right resolution, etc. Many OEMs, including Samsung, roll their own OS updates, so even if you configure an AVD to match the S7, it won't really be accurate because the emulator will be running stock 7.1.2 (for example) and not Samsung's own flavor of 7.1.2. But it'll be close enough for design work and general testing.
Going back to Samsung specifically, they do provide device details and skins to help you configure the emulator to more or less match their devices. You can find info about it here:
http://developer.samsung.com/galaxy/emulator-skin
As for the Play Store indicator, Google has a brief and fairly unsatisfying explanation:
Notice that only some hardware profiles are indicated to include Play Store. This indicates that these profiles are fully CTS compliant and may use system images that include the Play Store app.
https://developer.android.com/studio/run/managing-avds.html
I am new to Android App Development. (Did a year back but completely forgot)
A year back I had created a Virtual Device and I had setup the Emulator using the AVD Manager. Back then, it only asked me to choose the Target and I chose 2.2 everytime so that it supported in the latest versions too.
One year down the lane, the problem I am facing is, it is asking me to choose a target device too. I use a Galaxy Fit but there are other people with different handsets and resolutions for tablets, smartphones, notes, etc. I referred to all the tutorials on YouTube, Google and the Android Documentation itself, it only gives information about the old setup, the one without Device information.
I want to know which device to choose so that my app can be compatible on all devices and screen sizes(I chose Android 2.2 for the target) because without choosing the Device, the OK button is not getting activated.
Thank You
Making an app to be compatible with all devices depends on how you design your app, not on the virtual device chosen.
Some recommended Android documentation on how to polish your app for different screens can be found here.
Regarding sensors or other features that may be present or not in some devices, you should check if they are available before making use of them.
If you follow those, you are probably in a good position to be compatible with the phones that support the minimum API set you have chosen.
However, testing in different virtual devices can help you verify that your app is compatible in different real devices.
By the way, the device option when creating an AVD is for creating an AVD that matches a specific device (there is a question about it here). However for compatibility, you do not need to test specific devices, but a wide range of features values (resolution, screens, and on)
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.