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
Related
I'm trying to teach myself JavaScript by creating an little puzzle/game app with Cordova. I've got a basic prototype thing working, and have successfully got it to build on iPhone, and it runs perfectly.
I have 3 android phones to test with, 1 Marshmallow (BLU branded), 1 Lollipop, and 1 Kitkat... and the app works perfectly on those as well. I sent the app to 2 friends on the other side of the country to test, and it crashes on their Samsung Marshmallow phones ( a Galaxy 7, and a Galaxy Edge 7). It runs for a bit, and then just crashes without any user input.
So, I tried 2 separate crash analytics plugins, Fabric and Crittercism. I can verify that both of these are working, as I can force a crash in the app, and it shows up as a crash report.
But when my friends run the app with the crash analytics, whatever is going on that makes the app blowup, it isn't triggering any reports from Fabric or Crittercism. I've tried to get the android emulator running on my PC, but unfortunately it is an AMD processor, which is missing some necessary virtualization. I can't even get the super slow ARM version of the emulator to run on my PC, it just hangs forever.
I just recently installed cordova, and took all the defaults during setup. So from what I can tell, it should be targeting android API 23 (Marshmallow). But maybe there's some other kind of build issue that is messing things up?
So I'm kind of at a loss of how to debug this problem. Short of finding someone locally who can lend me a Samsung Marshmallow phone to debug with, I can't think of anything else that would work. Does anyone have any ideas?
The ARM emulator is indeed excruciatingly slow. I would suggest a third-party emulator. I use GenyMotion (which uses VirtualBox under the hood). You might have some luck with that. Alternatively, ManyMo is a cloud-based solution that might prove useful.
The system web view used by PhoneGap/Cordova will vary widely across Android devices, which means you can run into different issues across Android versions and device manufacturers. I suggest using the Crosswalk plugin to mitigate those problems. Do note that this will increase the size of your APK and footprint of the installed app on your device.
When the app crashes, does it actually crash to the launcher, or does the app reload itself (or just show a background color)? I wouldn't expect Crashlytics to handle JavaScript issues unless the JavaScript caused the app to crash out to the launcher.
I have this Phonegap application I'm working. Unfortunately, I having problems pertaining to a particular feature at the moment. I tried deploying on any iOS device, the error is present. Though by default, we programmers, should solve this problem right away. But I was wondering how I could see console.logs("..."); on Android.
I've search for related answers regarding this. Most of the answers mostly suggests I should use WebInspector using jshybugger. That won't be a problem unless I will be building the project on a level below API L19 (Kitkat) and maybe as low as API L10 (Gingerbread).
Using the AVD emulator was also a suggestion, yet I can't find a way to boot the emulator properly on my computer. And as we all know, Android Emulator is a hell of a snail compared to iOS Simulator.
Unlike for iOS I could just use the Safari Device Inspector to view the console logs and resources. I was hoping for a similar feature without using jshybugger and can be supported by at most Android API L10?
console.log should appear on the adb, you can see it on eclipse or on android monitor (monitor comes with the android sdk)
Or you can use this online debugger, it creates a javascript script that you put in your index and then you can see your phone debugger there. You can do it locally too using weinre
I've been developing a mobile app for both iOS and Android. Due to time/budget constraints, we initially selected PhoneGap/Cordova as mobile app framework so we could write once and deploy to both platforms.
This plan has worked fine for iOS, but we're finding that Android's browser/engine is kind-of a piece of garbage (to put it nicely). Every time we add a new feature, we find one more thing that the Android browser doesn't support, or only partially supports, or fully supports but will randomly fail from time to time, etc. Even once we code around the Android issues and get things working smoothly, test it on multiple devices/versions, and deploy a new app to the Android market, we immediately start getting emails and reports from customers who can't get the app to work on their device. We have them uninstall/reinstall, reboot their phone to clear the memory, etc., and their device still consistently fails (and by "fail", I mean it typically just freezes and/or won't respond to touch input - it usually doesn't crash, or anything). The app works fine for most people, but there are still quite a few devices that inexplicably fail.
I don't mean for this to be a rant, I'm trying to analyze whether the Android+PhoneGap path is the correct path for us. Specifically, I'd like to find out the following:
Are there people out there having success with an Android+PhoneGap app? or is Android+PhoneGap always going to be a problem on certain devices?
Am I likely to have more luck with a native Android app (I've never attempted one)? Or are multiple devices/versions always a problem on Android, even with a Native app?
1) Yes. There are are good apps which are based on Phonegap and works well in all devices.
2) It depends on what features of the Android you are going to use. Few versions that does not support some features that's available only to new version.
BTW, what is the minimum required version that you have selected for your app? I assume you are developing the app with Android as base version.
When creating a new Android project, you have to set the minimum required platform version. If you set something higher and use the app in a lower version which does not support the feature, results are going to be different.
After having worked with Android+Cordova for some time now, I have the following suggestions/comments for anyone thinking of going that direction.
Consider using Sencha Touch, or jQuery Mobile, or another mobile framework that has already coded around the Android-browser issues (which there are a LOT of). Consider not straying too far from the default styling that come with those frameworks. Simply styling a normal web page to look like a mobile app is a constant headache to get working on multiple versions of the stock Android browser.
Although the stock Android browser is garbage, Mobile Chrome is pretty nice. In Android 4.4, the Chrome engine becomes the default engine used by a webview of an Android app. If you don't like Sencha or jQuery Mobile or the like, you could hold off and just use a mobile web site for a while until Android 4.3 and below become insignificant. It's not hard to get things working on Mobile Chrome.
Even without Sencha/JQM, you can still muscle your way around the stock browser issues, but it's almost as frustrating as developing for IE6. Okay, maybe not that bad… but close.
I've started experimenting some with a native Android app, and, so far, it seems like less of a headache than building an app with Android+Cordova+lackOfSenchaOrJQMorTheLike. The things I've experimented with work pretty consistently among different Android versions. But I don't have much experience there, so I can't comment too much on a native Android app.
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
I've an app in the market with a few crash reports of "java.lang.RuntimeException: native typeface cannot be made". This is covered elsewhere on SO and I know where in my code it is. That's not my problem - the problem is finding out which Android version and handset type is causing it. I've never seen this on any handsets the app is tested on, nor does any version of Android on the emulators raise it. The only crash errors I see are these and always on "Platforms OTHER". I'm assuming if a different crash was reported I'd get a better clue regarding the platform - I'd expect to see "8", "11" etc.
It's a paid app. It happens right on first run so the users are cancelling the purchase.
Does anyone know what this platform is please?
In my experience, the developer console reports very few of the crashes occurring in your app.
If your app already requests internet permission you can use an error reporting library.
I use ACRA in my app. It's very easy to integrate and you'll be amazed at the number of crashes that don't get reported in the market developer console.
The Platforms section displays the device the crash occurs on, not API level. However, as you've seen, it's very limited. The only values I've seen besides OTHER are
T-Mobile myTouch 3G
Nexus One
Droid
Anything else is lumped in with OTHER. Obviously, the list of devices it separates out is vastly incomplete and not very helpful. Until Google improves it, the Platforms sections is essentially useless and I recommend using a third party library to get better information.