I wish to test my Android application against different versions of the Android OS on physical hardware. The need comes from testing interactions of my program with 3rd party hardware (barcode scanners).
In order to "switch" between Android OSs, I assume in order to "reimage" my phone, that I will have to root the phone then set the particular OS version with various images.
There seems to be much discussion on how to root the phones, however I'm curious if there is a easy/standard way to do this for developers (e.g. standard hardware which allows for this process to happen quickly/easily)? If not, how can I proceed?
Unfortunately, other than rooting your phone and flashing it w/ various OSs, you don't have a lot of options. My company keeps a tone of devices on hand running various different versions of android to address this exact challenge.
Otherwise, there are services out there that may be of help to you. Take a look at these:
http://www.deviceanywhere.com/
http://www.perfectomobile.com/
I'm sure there are others as well.
If it is just a testing of release candidate (not your BAU testing development), you may publish your app on Google Play as closed beta and then ask your friends (or some other community you trust) to play with the app.
Related
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.
I've never made an app before and am looking to get into it. I also need to upgrade my phone because it's really old. I've heard people say that it is best to test your app on stock android. But I really wanted to buy a Huawei, which might be running an older version of android not stock. What extra benefit would I get by spending the extra $500 to buy a Google Pixel phone for testing. Or is it fine, if I go ahead and test my app on a Huawei? What would be the pros and cons?
Android is an open-source operating system, which means companies can modify it to their liking. They do so by adding what’s known as a custom skin or user interface on top of the OS, which changes its look and feel as well as adds new features. These skins include Samsung Experience, HTC Sense, EMUI (Huawei), and OxygenOS (OnePlus), to name a few.
Some skins, like Huawei’s EMUI, change the overall Android experience quite a bit. For example, until EMUI 5.0 came along, owners of Huawei smartphones didn’t have an app drawer. All the apps installed on a device were placed on the home screen, just like on iPhones.
With stock Android, you get none of that — you only get the features developed by Google.
You can see the comparison of "Stock OS" and "Forked OS" here
https://www.androidauthority.com/what-is-stock-android-845627/
https://www.digitaltrends.com/mobile/what-is-stock-android/
With stock android, you get updates a little faster than other OS.
Coming to your scenario, you can even test an Android App without a physical device and by using Android's Emulator(Virtual Device) which has an Android Stock OS. You can select any version of Android(latest to old) and test your app there. If you are looking only for the purpose of testing I would not recommend you to buy PIXEL you can go ahead with your instincts.
People say it is best to test your app on stock android because the functionality you implement in pure android must work in the other OS as it is a layer on top of the stock OS but there are some chances(very few & negligible) that the functionality you implement in other OS might not work in stock OS. You can always use an Emulator for testing.
I am an Android developer. In my 5 years experience, I used both pixel and Oneplus, I did not find any advantages for stock android over Oneplus's Oxygen Os.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Android Emulator vs Real Device
Is it better to test your app on an emulator or on an actual Android device? As in to test your app while you are still developing it.
In addition, does testing on the emulator gives you more computing power than actual devices?
It is always better to test on a real device, as the emulator lacks certain inputs like sensors etc. (especially the older version of it). You will also have problem testing services like In app billing and LVM as the emulator doesn't come with Google Play, and the accounts that can be configured on it are limited.
The best solution is to have a few devices to test on, and use the emulator for testing different screen sizes and how they react to your layouts. There was a Google I/O talk this year that gave you a breakdown of what devices you needed to test on to make sure you have maximum compatibility. I don't remember which one though, sorry.
Concerning the development period,you should test the application on emulator first so that you can test it on multiple targets having different versions eg:2.2, 2.3, 4.0 to find out the loopholes and the resolution issues.
After completion of development you can test it on your actual device for hands on experience.
I would say it certainly depends on your needs. Since you are developing an application that will be consumed not by yourself actually, it will be consumed by your targeted audience and what will they have? They will definitely have real devices to use your application.
There are some features that are not available or really hard to configure on the emulator, like for example you are developing an app that uses a bluetooth feature.
The emulator is certainly designed for developers to test their apps in a virtual environment with limited functionality.
It really depends on the kind of app you are creating. If you are creating a game that requires the accelerometer then a real device would be beneficial. Yet if you are creating an app with a simple layout and you want to test for different screen dimensions and so on, the emulator is pretty good with this.
Yet you should always have a real device, since the emulator is very limiting.
Android simulator provides a platform very similar to the actual phone, so if your application is running in the simulator, it goes to 94% given the same result in the actual phone, except that sometimes there are modules that must be compulsorily test on a phone like the GMap, Push, screen size..
I am trying to write an android application that uses several of the android apis(like policy manager, package manager, wifi apis etc).
The concern i have is, android being open, manufacturers/carriers are free to take any specific version of android as their start point and customize the same and ship it with the device.
Note:Please excuse me if this post is in anyway a repeat of earlier posts on the same/similar topic. In such a case, appreciate anyone sharing the earlier post.
Few things that bother me are:
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
how do i ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know these are some naive questions for many of you who may have been on android for a while, but any pointers in this regard would be of immense help.
Any other information in general w.r.t cross version, cross device incompatibilities and strategies to deal with them would be very helpful.
Thanks a lot in advance.
Regards,
Deepak
Your concerns (and many other developers) are addressed by: http://source.android.com/compatibility/index.html
But this still does not guarantee that manufacturer will not change API and break your application.
The common approach is to initially target subset of devices that make up large percentage of market and then implement workaround for other devices (if necessary). Sample info about device market penetration can be found at:
http://opensignalmaps.com/reports/fragmentation.php?
Kind regards,
Bo
First off, I don't believe you should need to worry about this. Only after you have thousands of users will you end up needing to face the more complex issues caused by the great number of manufacturers offering Android devices. This should not discourage you from developing for Android.
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
No. But it would certainly work against them if they remove important APIs from the system. The core exists as a whole, though there really isn't anything preventing them from removing or disabling chunks as they wish. For example, AT&T had disabled the ability to sideload apps on Android devices some time ago (but I don't think they still do that). An example of a device with reduced functionality: Amazon Kindle Fire. It doesn't at all look like Android in the majority of its interfaces (except within third-party apps) and it doesn't offer the complete API set. Even with those dramatic changes, Android app developers still have great success building and selling apps that run well on the Kindle Fire.
Even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
That's the idea, but there isn't anything in place to forbid them from breaking things. Nor is there anything that will keep them from introducing bugs accidentally.
How do I ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know that some manufacturers will offer an emulator for their devices/configurations to help test against their systems. For example, Motorola offers MOTODEV Studio for this purpose.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been intrigued by all the android world since I first learned about it and would like to get my hands dirty developing for it. The question that comes to mind is if it's worth buying the unlocked phones that Android sells directly or not.
Those phones (link) quoting the Android page:
Run and debug your Android™
applications directly on a device.
Modify and rebuild the Android
operating system, and flash it onto a
phone. The Android Dev Phone 1 is
carrier independent, and available for
purchase by any developer registered
with Android Market™.
Please note that this device is
intended for development purposes, and
may not include certain features found
on consumer Android devices.
So will it be worth it to purchase one of those as a tool for app testing as opposed to developing and testing just on Eclipse or one of the other IDEs and emulators.
-Have you tried it, do you own one?
I'm assuming they have the same specs as the HTC Dream and the HTC Magic, since they look exactly the same although they have a 'developers edition' custom black design not that I really care about the design for this particular item.
All comments are welcomed,
Thanks in advance.
Update:
I'll leave it open until tomorrow to see if there are any more answers, then I'll just pick the most voted since it's really a subjective question with no good or bad answer.
It depends what sort of applications you wish to develop. I find that the emulators very accurately reflect how things work on genuine devices; you can seamlessly connect to either an emulator or a dev phone using the command line tools, the Eclipse tools, the debugger etc.
Also, while you can flash your dev phone to a new OS version, HTC often lag behind (e.g. there's still no 2.0 image available) and it's much easier and faster to just use the emulators. The emulators also allow you to create and test with different screen resolutions, whereas the two dev phones available are only "standard" resolution.
I find it's quite rare that I need to use my ADP1 dev phone for development -- my rooted consumer HTC Hero works fine for most of the development I do.. allowing me to pull files from the device etc. Though the only reason I use my Hero rather than an emulator is because I've been working on an app that uses audio recording functionality.
However, where having a physical device would help is where you need to do specific stuff regarding the camera, audio hardware, orientation and compass sensors, GPS, wireless network access and so on. Should you need to connect a debugger to work on hardware-related issues like the above, then you would definitely need a dev phone.
Overall, it's definitely worth buying an Android phone for testing and demonstration purposes, but whether it's a development phone is up to your requirements.
If you plan on developing apps that you intend to put on the Android marketplace, it's absolutely critical to test on real hardware. You can get away with developing on the emulator for quite a while, but at some point, you'll want to use a real device.
That being said, you can use any android phone for development. There are some restrictions on locked devices, but if you're simply developing against the SDK, any phone will work. With android, you can install an apk directly on the phone without special permissions, so the only real advantage to a dev phone is that you can install new roms without having to root the phone.
Personally, I'd hold off on purchasing one of the older dev phones. From what I understand, they only support up to SDK 1.6, whereas the Droid and some of the other new phones are supporting SDK 2.0 ++.
Wait for the release of the Nexus One from G. The latest rumors are that it'll be released on Jan 5th. So it's just a week or so.
I think that you need a real android device whether it's the dev phone or another handset but a real phone is primordial. The emulator is great but you can't get an idea about the execution speed of your app until you use it on a real phone.
As said before there are a lot of rumors about the nexus one so wait and see!
As for which phone to buy (assuming you're going to get one) I think ablerman is right. I'd wait until January to see if there is going to be some new hardware available.
With regards to the more general question of should you buy one, I think it depends on what you're doing. For the most part, the emulators are fine. They can emulate GPS (you can even load KML to simulate a path), SMS, phone calls, etc. They cannot however emulate acclerometer/compass/orientation sensor data and actually will crash (actually I believe it hangs...) if you try to run code that relies on it. Also, it's difficult to actually debug phone-call related functionality without the dev phone.
They're good phones, I've used the Dev phone 1 (the G1/Dream) and it's nice. It also is a bit faster than the emulators and if you're writing something like a game, it would be really good to test it on the actual hardware.
All in all, it just depends on what you're writing. They're definitely fun to play with regardless as you can do pretty much ANYTHING you want on them.
Good luck with the decision!
I've been developing with the emulator since June. I've found it to be a very near substitute for the real deal, and it's easier to switch between handset configurations/versions. However, not knowing how quickly my apps will run is a concern for me.
The reason I've personally held off buying a handset is that 2009 was the wrong year to buy one. I have a feeling 2010 will very much be the long-awaited "Year of the Android".
+1 to Christopher and I will add - the emulators are great but having a physical phone will give you instant access to the Android Market to verify publishing, statistics and user comments. I also believe using your own app on a physical phone will help you to develop a better app. You do not need a development phone - but at least one physical phone - absolutly.
FYI. Belgium is one of the few countries where it is possible to buy any mobile unlocked. Indeed, the Belgian regulators forbid the forced bundling.
One more Pros for buying a real developer phone :
HierarchyViewer does not work on user builds (i.e. with devices
available in stores.) This is for security reasons.
See the original thread
Hierarchy viewer can be very useful if you have problems with layout being slow, although I don't think it would worth buying a real Developer phone only for this.
As some people made workaround for that problem : https://stackoverflow.com/a/7801475/62921.