I'm about ready to release 6 apps on the Google Play market, and a guy at work brought in a new phone that was running a version of android that the manifest file stated was supported and it didn't work as expected even though it did work on the emulator. This brought up the question of
Short of buying every device, how can we ensure that our apps will work on all devices that run the versions of android that the manifest file says it supports?
Is there a suggested way to do this? The combinations of different screen sizes, densities, and android versions can make development for android a real pain.
Edit:
The part that "didn't work as expected" was some of the javascript calls. Especially calls like window.width and window.height, the width was reported as the height and the height was reported as the width on 2.3.4, but not 2.1, or 3+. Another issue, also with 2.3.4 and javascript was the window.open(url, target) call would only call the shouldOverrideUrlLoading on my WebViewClient the first time for each target rather than every time. Again, it worked with 2.1 and 3+.
Currently, I test on devices running 2.3.4, 2.3.5, 4.0.3, and 4.0.4. I also test on emulators running 2.1, 2.2, 2.3.3, 3.0, 3.1, 3.2, and 4.1 with various screen sizes and densities. The javascript bugs are not present on the 2.3.3 or any of the other emulators, which is why I would rather test on devices, they give me a more accurate feel of what the user will run into
To start, here is a presentation that discusses how to potentially address the problem. This is obviously not easy, but here is another similar SO post.
I don't exactly what you exactly mean by "didn't work as expected" but this can help you quite a lot:
In my opinion, the best way to test your Android application is to install a Jenkins Continuous Integration Server, and use the Android Emulator plugin to execute the application on your application builds on emulators with various settings (screen density, OS version, etc.). The plugin can take automatically screenshots so you can see afterwards how your application looks on each configuration. Also, builds and testing can be trigerred daily, or each time you commit some code on your SCM (Git, SVN, you name it).
The configuration of the plugin is detailed on the official page: https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin
Related
Obviously, there will be minor differences between the emulator and hardware, but I'm running across major issues and wondering if others have found any solutions.
I have an .apk of my application, which loads and starts fine on the 2 pieces of hardware I have on hand (both OS 4.1.2). It then freezes up on a screen switch inside the application. This has happened before and it was due to that exact version of the OS having a particular bug (which should be worked around). Anyways, those details are not terribly important, that's simply how I got to thinking I'd test other versions via the emulator. However, here's what I hit:
Newer versions (5+) of the OS have an "Intel" option and my .apk crashes immediately on start on those versions.
Newer versions (5+) the Google version and 4.x generic (including the very same 4.1.2 I have on 2 hardware devices) starts my .apk fine, except that all the graphics are missing!
No difference between architectures on any given OS/class (32/64 bit, mips, arm)
What's the difference between Intel and Google versions of Android that would cause such a huge difference? Also, why does my app have graphics on hardware, but graphics vanish on the very same OS on the emulator? Are there options I need to change somewhere?
First update your SDK.
Then install emulator system image you need.
In SDK Manager you can find that Intel/ARM Android images start from 4.0.3 . Google Intel/ARM start from 4.4.2 instead .
Make sure you have hardware virtualization enabled in PC BIOS because Intel images need that and they are much faster for that.
Try to reinstall Intel HAXM . You can find setup in <Android SDK Path>/extras/intel\Hardware_Accelerated_Execution_Manager
Intel/ARM images use different CPU architecture. Instead Google/Android images have only a different software configuration. Google images include Google services like Play,Maps,ecc. Android images haven't them
It appears to be due to timeouts. Differing versions and "equipment levels" of Android devices take varying times to respond. The difference is especially large in the emulator. By bumping up all the system timeouts in the code I'm able to avoid all of the avoid weird issues.
I am building an Android app for my company, using Android Studio 1.5.1 . I've discovered that the app won't work on some Galaxy S5 phones.
These phones just show a white screen when the app runs.
This error happens on Galaxy S5 devices with Android version 5.1.1 But not on an Galaxy S5 Device running Android version 5.0
I'm focusing on the Android Version as a clue to solving this bug.
I can't actually get one of the devices so I've created several Virtual Devices. There are 6 Downloadable system images of Android 5.1.1 in Android Studio's Virtual Device Configuration wizard. I've installed all of them. none replicate this white screen error.
What else can I do to uncover this bug?
If it helps answer my question, my app relies heavily on server communication. The whole app is just one Webview with a few html & JS files.
The problem with emulators is that they are not reproducing actual device behaviour(especially, once many OEMs like Samsung tend to customise Android based on their needs), so I'm afraid the only options you have are:
Get Samsung Galaxy S5 with 5.1.1
Apart from obvious ideas "go to shop and buy", I can recommend you:
to take a look at Open Device Lab. It operates around the world and there's an arguably good chance to find the device you need there;
build a pool of alpha-beta users you can talk to and share new builds. Google Play has quite rich functionality in this area. Samsung S5 is quite common model, so it shouldn't be a problem to find people with it. If your product is "public", you can try to find beta-users on services like BetaBound or just among your social media network;
Use Analytics tools to collect more data from affected devices and act based on the information you get
There're dozens of different frameworks for accomplishing it. I can suggest Crittercism as a super powerful and comprehensive tool. In particular, I'd definitely log:
All handled exceptions
Add breadcrumbs (short string to capture app run-time information) to all Activity/Fragment lifecycle methods, to Application's methods (as white screen on start might mean some issues there), to all meaningful async tasks, etc.
If app gets into suspicion state - log it as a handled exception, so you can see the whole trail of breadcrumbs and track history of exceptions for the user. Unfortunately, you won't get trail of breadcrumbs, before something has been logged as an issue (crash or exception). There're frameworks, which log everything, like MixPanel, for example, but I honestly think that Crittercism suits much more here)
Crittercism will also catch & report all crashes happen in the app and
The Get Started Guide is here and it's pretty straightforward: http://docs.crittercism.com/android/android.html
Saying that, I'd suggest you to integrate some analytics anyway, as it'll help you in the future and to try to get affected phone in hands for test.
I guess the culprit is webview. Can you check the webview version on which the issue is reproducible.
To check the version you need to go to settings->Application Manager-> Downloaded Apps-> check "Android System Webview"version
We had a similar issue when the screen used to go blank and it used to happen only on particular version of webview. The issue was fixed by Google later.
The chromium webview layer is now updatable from Google Play.
For more details refer-http://developer.android.com/about/versions/lollipop.html#WebView
I assume you are building a hybrid app.
If the webview is the culprit, you could try crosswalk.
It adds Mb's to your app but it makes sure every device uses the same webview (latest chromium). Moreover rendering differences etc are also minimized.
if you are using cordova run: cordova plugin add cordova-plugin-crosswalk-webview and that's it.
If you implement this and the whitescreen problem is gone, you debugged it in a sherlock holmish deduction way...
The problem is not with emulator. It is with WebView in Android versions 5.1 onward.
Try
uninstalling the updates for "Android system webview" app (go to
settings and look for it under "downloaded") it works just fine!
Source - similar question
I am trying to test my app and I have lots of problems with Android emulators. Finally, I got one emulator running using Android 2.2 . So I used this one and my app works fine.
I also tested my app using real device, Nexus 7 , Android OS 4.2. App works fine in both versions.
It is safe to consider my app will run fine for OS versions within 4.2 - and 2.2 band? The reason I am asking is because using emulator makes my computer very slow and it takes forever.
In the best case: yes. In worst case: no. It completely depends on the parts of the Android API you're using in your app. For example, private APIs might very well break or change. You should be fine with public APIs, but there's always the chance of a bug in one of the OS versions...
If you want to test your app on various devices and Android versions, you should give apkudo.com and testdroid.com a try.
You can also try https://www.elusivestars.com it allows you to select devices based on specs like OS version, brand... and offering 5 free reviews
I have heard good things about testflightapp, they used to be iOS only and now doing Android.
Something like http://www.perfectomobile.com/ might also be a good way to go.
Here is a list of tools, including test tools
http://www.apptamin.com/blog/app-developer-tools/
Cloud based real device testing is typically either devices you can access and manipulate/automate or users with devices. Personally I think starting with automated testing then finishing off with real user (usability testing) may give you good coverage.
I am the Founder of elusivestars
I've developed my first app and it worked fine on my phone (Android 2.2). When I tested in a Xoom (Android 3.2), it had lots of bugs, though. I need this app to run in many different versions of Android. How can I develop it and make sure it will, having only an Android 2.2 in hands for tests?
Developing with the last version targeted in the manifest while keeping a close eye to back compatibility is how you achieve this with the best efficiency.
Many libraries (ActionBar Sherlock, NotificationCompat2, ....) will help you in making your app back compatible without issues.
I strongly recommend making the app for the last version of Android so it is ready when this version gets some steam instead of targeting whatever version is the most popular right now. It is a bit more work at the beginning, but it will save you many headaches later on.
The emulator will help you test this, the best configuration is to have a terminal with the last version of android at your disposal (this is why the nexus are a very good choice for a dev) and different configurations on the emulator to test back compatibility or other form factors.
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.