I'm very curius about one thing:
Is it possible that for instance, Jelly Bean on HTC differs from Jelly Bean on Samsung, or Sony, Motorola..etc? If "YES" why?
Actually this IS programming question because, some apps that i'm testing are working on HTC, but not (not fully working, or with "bugs" ) on Samsung, or vice versa.
Is it possible that for instance, Jelly Bean on HTC differs from Jelly Bean on Samsung, or Sony, Motorola..etc?
Absolutely.
If "YES" why?
Because they can. Android is open source software, meaning that anyone can modify it as they see fit.
Devices that legitimately have the Play Store app on them must meet certain compatibility criteria, including passing a test suite designed to ensure that the Android APIs are not horribly broken.
Although any "Jelly Bean" version is based on the same ASOP core there are a bunch of reasons why things could differ. The inclusion of Google Mobile Services (on Nexus7 for instance, but not Kindle Fire), chipset level changes that are developed by TI or Qualcomm etc to support the hardware platform as well as customizations and optimizations my OEMs and ODMs (eg a custom launcher or inclusion of Dolby Digital to the audio pipeline) are going to mean potentially different behaviors, though mostly they should not change core API functionality
Within any given major release there are also fixes and changes for the point releases which may show up in your tests.
Do you have examples of the sorts of things you are seeing
Yes, because some companies all vary, and it takes time to get the next Android Version into their devices. Say for instance when Android 5.0 Key Lime Pie comes out this May, Motorola will be the first to have it with the Motorola X, but it will take other companies such as LG some time to get to it. My LG Android device doesn't even go to Android 3.0 Honeycomb yet.
Related
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.
I am working on an Android app that I want to run on all Android devices without any problems, but I'm having a hard time trying to determine how many device configurations and how many hardware devices I should have for testing.
There are several features that I am using which are not supported in the emulator, as mentioned at the bottom of Using the Android Emulator in the Dev Guide:
Emulator Limitations
In this release, the 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 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 insert/eject
No support for Bluetooth
The Multiple APK Support page states:
...we encourage you to develop and publish a single APK that supports as many device configurations as possible...
Android Market allows you to publish multiple APKs under the same
application listing. Android Market then supplies each APK to the
appropriate devices based on configuration support you've declared in
the manifest file of each APK.
I would assume that it's not necessary to cover every single permutation of all the available feature sets, but it's not clear to me how many device configurations would be considered sufficient to cover all the devices available.
If I wanted to confirm on hardware that my app is almost guaranteed to work on every device, how many phones and how many tablets would I need? Also, are there any special considerations I need to make for manufacturer- or carrier-specific modifications?
Answer Updated on 11/15/2011
Use android website stats to glean info on the most popular os version(s).
Use android website stats to get the most popular DPI/screensize combination(s).
Use a combination of 1&2 to determine the specs of devices you want to cover.
Prepare a rough listing of devices which would meet (3) above.
If you have A lot of money, -or- if you work for a big company then order the phones. If not, then as others have already mentioned choose the one device which can provide you with max coverage. Sadly, the difference between the emulator and devices can be ridiculous at times. The other option that i found out only recently is that you can outsource this process to companies which exclusively focus on this market need. Unfortunately, I don't have any specific company to recommend in this area. Good luck !
Updates:
I came across a couple of companies that are offering Android Testing as a Service. These would be good options to test your APKs without having to purchase the devices.
You may want to give APKUDO a try: http://www.apkudo.com/
"
See your app run on every Android device. Free.
Apkudo helps developers release with confidence by installing, executing, and exercising their apps on every Android™ device, with detailed test reports & streaming video. Currently in private beta.
"
[Update - 3/25/2013]
TestDroid also has a cloud testing service
http://testdroid.com/product/testdroid-cloud
"
Test online on Real devices Testdroid Cloud is the simplest way to test your application against various real Android devices – from different manufacturers, with different HW platforms, OS versions and screen resolutions. You can also pick and choose on what devices to run your tests, just on the devices you are interested in
"
AppThwack is another solution
Ranorex is yet another solution (http://www.ranorex.com/mobile-automation-testing/android-test-automation.html)
One of the big problems with android is that each manufacturer may change pretty much whatever he wants in the firmware. It may have many advantages, but it might be a big problem when trying to test compatibility.
You should have at least one device, but there is no limitation, or even a number that is "enough", the more devices you test on - the better.
Regarding carrier modifications, usually those are smaller and will change less than manufacturer modifications, but this might change as well.
I have encountered many issues with many different phones for Android. Each phone has its little quirks and so the more phones you test on the better. I had an app that had well over 200K downloads and was really surprised about some of the issues. Now there are things I do and stay away from due to these quirks I discovered. Also each version of Android has its issues to. So I guess my answer is, get as many phones from at least each of the versions of OS's from say 1.6 to 3.x.
ListViews with custom Adapters is one, I created custom adapter to add icons to each item in a ListView. I had repeated crashes from 2.2 phones like DroidX to name one but on others it worked fine. It ran fine on a G1 too. Also with ListViews and SimpleExpandableListAdapter are fraught with issues on other phones where the icons don't line up or on large lists it just crashes the app. I stay away from ListView now since I want to try and keep my apps deployable across many different OS's
Pertaining to the other answer here are the list of phones I encountered for mostly US deployment. Not sure why the Samsung Galaxy S is listed 3 times or Motorola Droid II is twice, may have to do with OS versions.
1 Motorola Droid X 9.3%
2 HTC Evo 4G 6.2%
3 Samsung Galaxy S 4.9%
4 HTC Desire HD 4.4%
5 Motorola Droid 4.4%
6 HTC Droid Incredible 4.1%
7 Motorola Droid II 3.4%
8 Samsung Galaxy S 3.3%
9 Samsung Galaxy S 2.7%
10 Motorola Droid II 2.4%
This is why when I program I keep in mind to be agnostic to the OS API and just try to make sure it works for the majority of the users.
One possible way of deciding how many mobiles you'd need for testing is to look at the market using your application.
One of my applications has the following mobile phone breakdown (be aware this is in the UK). So in my region these 10 mobiles will give you approxpimately 70% coverage
1 HTC Wildfire 15.2%
2 Samsung Galaxy S2 10.5%
3 HTC Desire 10.2%
4 Samsung Galaxy S 9.7%
5 HTC Desire S 8.6%
6 HTC Desire HD 7.5%
7 Samsung Galaxy Ace 3.1%
8 Samsung Europa 2.7%
9 ZTE Blade 2.1%
10 Samsung Galaxy Tab 2.1%
Your aim should be to cover as more android users as possible for your project. Important parameters that you need to cover are by api level, ppi, screen size and resolution.
How it could be achieved:
1. Find most popular devices for your project (for example using google analytics)
2. Group those devices by parameters
3. Find most popular groups
4. Find most popular devices in each group
Such approach is realized on http://choosedevice.com.
So based on your budget you should buy devices from step 4, starting from devices from most popular group.
I am beginning Android app development and I would like to know which device would give me the most comprehensive testing environment. I would like my app to be compatible with the most number of devices without breaking the bank by buying a dozen devices. Just testing on the emulator is not an option because it runs at 1/10th of normal speed.
OS Version
Should I purchase a device with the most common OS? As of now, 2.2 is the most popular. Obviously, a 2.2 device wouldn't be able to test run an app made for 3.0. But is the reverse also true? If I buy a 3.0 device, would that allow me to test all lower versions?
Tablet or Phone
Given that my app won't be dealing with phone calls, should I be buying a phone or tablet? Are the two sufficiently the same except for resolution? Has your app ever worked on a tablet but failed on a phone? The Apple iPad has a neat emulation mode for iPhone apps. Is this feature also available on Android tablets?
Price is also a big consideration when choosing a tablet over a phone. I'm not going to sign up for another cellular plan, so most phones would have me fork over $500+. That would come out to be the same price as the Motorola Xoom. But arguably Android phones are much more popular than tablets, so a Xoom wouldn't let me see what most of my users would be seeing.
In general it's up to you, I suggest you Google Nexus S, because of NFC module in that phone (only that phone nowadays as I good know have NFC), besides that it has everything you need. Big plus for screen.
Android 3.0 is made generally for tablets but of course you can write application in 3.0 and run it on 2.2 or 2.3 just look for backward compatibility, and use reflection.
Also good to know that it does not depend of your phone which version you have it's up to SDK ver which you choose during creating project, in general you can set 7 as min SDK and test it on phone with 9.
If you are creating applications which requires a lot of custom drawing/animating such a game, then a slew of devices would be ideal to test against resolutions, DPI, RAM, CPU power, etc.
If you are using more of the native components then you do not have to worry as much about the different screen types and sizes as these tend to scale very well.
This question was brought up at GDC's Android Developer Day, you may be able to find the video online. Basically, it boiled down to trying to get one of each kind of device, low end, mid, high. It was also recommended that you built for the newest SDK, then start building against older ones, fixing, testing, rebuilding.
Therefore, I would personally recommend the Nexus S.
The company I work for does Android development on the original G1, HTC Hero, Samsung Epic 4G, and HTC Incredible.
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.
My boss recently gave me an HTC Wildfire phone for doing an Android version of one of our mobile apps, which is all fine and good, except that the app requires API level 8 (ie Android 2.2), and the phone itself only has Android 2.1 installed. After much googling, I discovered that this phone does support Android 2.2, and carriers will be rolling out updates over the air for this model phone "in the near future".
Since I'm not entirely certain what our lazy carrier's definition of "near future" is, it would be nice if I could download images for particular releases and install them on my phone. Coming from the world of the iPhone, it seems that this should be something rather necessary in order to successfully develop an Android app.
Yet, it doesn't seem that Google offers any Android OS updates themselves. Have I no choice but to wait for the carrier to release an update?
Edit: Thanks for the suggestions regarding the emulator, but I'm asking about testing on hardware only. I already have a working 2.2 emulator image, but I need to test on hardware now, since the emulator does a very poor job of things like video playback and audio processing.
There's a few ways you can test your application on Android 2.2:
1) You can use the Emulator provided by Google in the SDK. It is possible to create a virtual machine of any version of Android with various hardware options. However, the emulator does have some limitations such as not supporting certain hardware options (such as bluetooth) and it's also dreadfully slow to boot.
2) If you have to use an actual phone with 2.2, you can root your phone and flash a custom ROM. I'm not particularly familiar with how to root the Wildfire, or what custom ROMs are available for that specific phone, but Cyanogen Mod has pretty good ROM support for HTC phones, as well as an active forum with tutorials.
No, it's not possible to download images before OTA. You could check CyanogemMod from time to time - they're working on Wildfire support. Also you could use an emulator.
If you are wanting to bounce around with newer versions, I recommend the Nexus One as a dev phone if you can get your hands on one. Or, if you can deal with the constraints, start with a built-in AVD emulator with API 8 until your phone gets the OTA update.
The Motorola Droid is also getting/has 2.2 on it. At least in the States, in seems that most of the phones on Verizon already have it (non-scientific, just from talking to people I know). So if that phone is available, it may be a decent choice.