[TIMOB-16538] Android: Analytics crashes App intermittently onResume
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2014-07-16T18:31:25.000+0000 |
Affected Version/s | Release 3.2.1 |
Fix Version/s | Release 3.4.0 |
Components | Android |
Labels | n/a |
Reporter | Vladimir S |
Assignee | Ping Wang |
Created | 2014-02-02T03:14:08.000+0000 |
Updated | 2017-03-16T22:17:06.000+0000 |
Description
From time to time, when the application is resumed, it does not start. The logcat reveals a stacktrace leading to the Analytics module. Seems like this has been already reported
http://developer.appcelerator.com/question/156480/application-crashes-after-a-period-in-the-background-including-services
I will try to workaround it by catching the exception, hoping that there are no other dependencies
Attachments
File | Date | Size |
---|---|---|
ANR_reproduction_jay.rtf | 2014-06-30T20:51:43.000+0000 | 608526 |
bug_report_out.rtf.zip | 2014-06-30T20:51:43.000+0000 | 2209831 |
keyDispatchingTimedOutOnForce.rtf | 2014-06-30T18:21:58.000+0000 | 127907 |
logsOpeningAppAfterCrash.txt | 2014-06-05T17:10:10.000+0000 | 215180 |
logsToCrash.txt | 2014-06-05T17:10:11.000+0000 | 178633 |
new 3.txt | 2014-02-02T03:14:08.000+0000 | 6062 |
PushService-OnForce.rtf | 2014-06-30T18:21:58.000+0000 | 127927 |
TiApplication.java | 2014-02-11T03:47:26.000+0000 | 27939 |
TiBaseActivity.java | 2014-02-11T03:47:26.000+0000 | 40091 |
I am curious if you encounter this issue with a specific application or is this issue unrelated to an application? Do you notice this issue under certain circumstances i.e. when the system is running low on memory? I was not able to reproduce this issue with a simple test case.
I cannot reproduce it consistently either... It happens now and then. Just - the last time it happened i was near my computer so i could connect and see the logcat. What i did now is to wrap the coding to catch the exception, to see whether something else wouldn't fail.
Resolving this ticket as "Cannot reproduce" as we have not been able to reproduce the issue in-house. Attached stack trace is also not very helpful as it points to native generic stack. We just don't have enough information at this point to diagnose this issue further. We would be happy to reopen this ticket if you can reproduce it again with more specific use case (for example, device was running low on memory).
I have a Samsung Galaxy S2, and I am able to reproduce this exact stack trace reliably. This will happen after a random period of time, but it can be caused by either leaving the app in the background with the screen off for a period of time (with no other applications running), or it can happen if using the phone for several other activities. When this happens, the application will disappear from the task manager. If I go to open the app back up, it will open to a black screen, with the application name displayed in a bar up top. This locks up the home button and back button, and eventually Android will ask if I want to kill the app. After this, I can open up the application normally again. Vladimir, were you able to find any sort of temporary solution to prevent this?
Hi Jack, This is exactly the same behavior that I get on my S4. Currently i've tried to try/catch the exception in TiActivity.postanalyticsEvent (See attached source). Yet - it seems like this has reduced the number to crashes, but once it happend again - with no exception visible in the logcat. In an attempt to investigate further - i have added some dumps to TiBaseActivity.onResume. But since then it did not happen again. If you like - you can try those fixes (i simply put the java files in a new project, and all jar files from the SDK in the classpath, build it with JDK 1.6, and then copy the built .class file in the corresponding jar). Another workaround, that i am going to apply once I see the app crashing again - is simply to close it when it goes to background (at least in my case the startup is fast, so it will not kill usability) (i just have to find a reliable way to know that the app is going to pause, and not just a new activity is being open, which causes the main one to go to pause) Regards, Vladimir
Thanks Vladimir, I'll try with the files you posted and report back. Unfortunately, my application is a messaging app, so for me closing it when it goes to the background isn't an option. And some more information: this issue appeared for me in my most recent release which is using SDK 3.1.3. I've been able to replicate the problem in 3.2.0. Our previous release used SDK 3.1.0, and the issue was not present.
Hi Jack, it is offtopic, but i do not know how to send you a PM - have you considered using Services on Android for this, or using the Notifications API (Google cloud Messaging or Apple Push
Thank you for the suggestions. We are using push notifications if someone is offline. However, the nature of the application requires rapid response, and push notifications aren't as reliable or as quick as an xmpp message coming in. So that's the main reason for wanting it to stay open in the background, but it's more complicated than just a simple IM client, so there are additional reasons for wanting it to stay open if possible. iOS gave us tons of problems with keeping it open in the background, and Android always just worked (until now). So we may need to reevaluate how we handle Android staying open (we ping iOS devices every minute).
Alright, then - have a look on the workaround. and perhaps if it is easier to reproduce it in the S2, you can see if it really fixes the issue, and if it makes sense to do something in addition
Vladimir, unfortunately running it with the java files you posted did not correct the issue for me. It didn't display the exception at all in the logs, and went to a completely black screen without even having the application title up top like it used to. I'm thinking that since the app disappears from the task manager when this happens, the exceptions we do see are a result of the problem, not the cause. I'll continue to mess around with it. I'm able to reproduce it in 3.2.1 now also. While it will happen if the app just sits in the background with nothing else going on, using other apps definitely speeds up the process. I've been keeping an eye on memory usage though, and I don't think the device running out of memory is the issue.
Ritu, Here are some additional details I've found to possibly get this issue reopened. Firstly, the easiest way to identify that the problem has occurred is to have a task manager widget on the main screen of the test device if possible, since the app will disappear from the task manager when the problem occurs. After this happens, opening the app will result in a black screen. DDMS provides no information when this happens. The only indication that something went wrong in the logs, is when you try to reopen the app, and the exception that Vladimir first posted shows up. I was able to reproduce the problem using a bare-bones test app. However, I found that when the problem occurred, reopening the test app would cause the black screen to show for a moment (or maybe not at all), and the app would restart itself. Adding
Reopening this ticket based on latest comment.
I can confirm the claims made by Jack Wilson using my company's Android app. My company has been receiving numerous complaints from our Android customers experiencing the "black screen of death." I followed the same exact steps as Jack did to investigate his claims, as well as our customers' claims, (including the extra tests involving the Gamestop app) and received the exact same results. The only differences I've encountered involve the
alwaysRetainTaskState
parameter. When the parameter is not specified or explicitly set totrue
the app crashes as expected, however, there is no way to force the app to restart unless you force-quit the app via Android app settings. When thealwaysRetainTaskState
parameter is set tofalse
it crashes as expected but in this case it allows the user to press the back button twice upon which time it will restart the application. This is very very critical to us as the app appears to be entirely broken and useless to our users on a regular basis. In the meantime we are looking to revert to a Titanium version that does not produce this bug. Any further insight as to how to patch this in the meantime would be greatly appreciated.Moving this ticket to engineering for further evaluation. I have not been able to reproduce this issue but it has been reported as an intermittent issue and multiple people are running into this issue.
3.2.x PR: https://github.com/appcelerator/titanium_mobile/pull/5703
Pull 5703 has the same effect as the code that Vladamir posted months ago, that surrounded that entire method in a try/catch. The crash still happens just as easily, but the postAnalyticsEvent exception doesn't get thrown when you go back into the app after the crash. Also, it goes to a completely black screen, as opposed to a black screen with the app name in a bar up top (for me anyway). I believe the postAnalyticsEvent exception is a result of the crash, and has nothing to do with the cause.
Looks like I'm experiencing the same issue. I posted a ticket on appcelerator.com, on http://developer.appcelerator.com/question/156480/application-crashes-after-a-period-in-the-background-including-services. Is anyone of you can tell me when is it going to be fixed, and if there is a workaround ? I saw in previous comments that some of you used try / catch statements but can I use one with a service since I would have no idea where to place it as I have no idea where the code is wrong ! If anyone is available a few minutes on IRC to help me out on that it would be your good action of the day and I'll owe you a beer !
[~davidfabreguette] Can you please post the crash you are experiencing here?
Sure here it is : 06-11 14:24:34.014: E/TiApplication(21142): (main) [41115,41712] Sending event: exception on thread: main msg:java.lang.RuntimeException: Unable to resume activity {com.idfuze.prestatech/org.appcelerator.titanium.TiTranslucentActivity}: java.lang.NullPointerException; Titanium 3.2.3,2014/04/22 10:17,b958a70 06-11 14:24:34.014: E/TiApplication(21142): java.lang.RuntimeException: Unable to resume activity {com.idfuze.prestatech/org.appcelerator.titanium.TiTranslucentActivity}: java.lang.NullPointerException 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2826) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2859) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2274) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread.access$800(ActivityThread.java:139) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1210) 06-11 14:24:34.014: E/TiApplication(21142): at android.os.Handler.dispatchMessage(Handler.java:102) 06-11 14:24:34.014: E/TiApplication(21142): at android.os.Looper.loop(Looper.java:136) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread.main(ActivityThread.java:5102) 06-11 14:24:34.014: E/TiApplication(21142): at java.lang.reflect.Method.invokeNative(Native Method) 06-11 14:24:34.014: E/TiApplication(21142): at java.lang.reflect.Method.invoke(Method.java:515) 06-11 14:24:34.014: E/TiApplication(21142): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785) 06-11 14:24:34.014: E/TiApplication(21142): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601) 06-11 14:24:34.014: E/TiApplication(21142): at dalvik.system.NativeStart.main(Native Method) 06-11 14:24:34.014: E/TiApplication(21142): Caused by: java.lang.NullPointerException 06-11 14:24:34.014: E/TiApplication(21142): at org.appcelerator.titanium.TiApplication.postAnalyticsEvent(TiApplication.java:690) 06-11 14:24:34.014: E/TiApplication(21142): at org.appcelerator.titanium.TiBaseActivity.onResume(TiBaseActivity.java:1045) 06-11 14:24:34.014: E/TiApplication(21142): at org.appcelerator.titanium.TiActivity.onResume(TiActivity.java:35) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1215) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.Activity.performResume(Activity.java:5327) 06-11 14:24:34.014: E/TiApplication(21142): at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2811) 06-11 14:24:34.014: E/TiApplication(21142): ... 12 more
All, we believe this may have been solved in SDK 3.3.0 (or that the exception above noting the error of org.appcelerator.titanium.TiApplication.postAnalyticsEvent() is a red herring and will now be replaced with the true error). Can you all please try this with SDK 3.3.0 and let us know if the issue is resolved or if you get a different error.
There doesn't appear to be any difference between SDK 3.3.0 RC and Pull 5703. When opening the app into the black screen there's the message APSAnalytics has not been initialized. Call APSAnalytics.enable(ctx, key) to initialize. but otherwise no mention of Analytics that I can see. No exceptions are being thrown, it just goes into the black screen as usual after disappearing from the task manager.
All, please try build #77 of 3.3.X (from http://builds.appcelerator.com/#3_3_X) to see if this addresses the issue. This includes a fix for thread-safety in analytics.
It's still crashing the same, but now instead of going to the black screen it gets stuck on the splash screen with the following exception.
All, is it possible to get a copy of the application? We can handle it in confidence and delete it when done.
PR: https://github.com/appcelerator/titanium_mobile/pull/5908 For FR, please also test TIMOB-15971.
My app did restart after vanishing from the task manager, as opposed to going to the black screen. Thank you to everyone who worked on getting this resolved.
Thank you, everyone, and thank you Jack for providing them information!
Thank you everyone for that ! How can I test this out ?
David, Install the latest build from here: [http://builds.appcelerator.com/#master] Copy the url to the zip file for the OS you need, then in Titanium Studio under Help -> Install Titanium SDK choose install from URL and paste the copied URL. After it's installed, change the sdk in your tiapp.xml file.
Thanks ! I'm giving it a try :)
One problem that I am seeing with this solution: if the app has died in the background, and a push notification comes in, when the app restarts it doesn't fire the callback, so the payload of the push is effectively lost. I tested this with Urban Airship.
[~jwincao], that behavior is expected. By default, all components of the same application, including activities, services, receivers and providers, run in the same process. When the app is killed in the background due to low memory, what actually happens is that the whole process is killed. In that case, the BroadcastReceiver is unable to listen to the notifications until the app is relaunched.
Thanks for your response, Ping. To clarify, I do still get a push notification even though the app has died in the background, and clicking on the notification it opens up the app as expected. I think the problem is that when the app reopens in this somewhat dead state, and the app is forceably restarted as a result, instead of it having been opened with the push notification which contains a payload, it's being opened through another means, and so the push is now lost. So in other words, the app is being opened twice. Once from the push notification, and then a second time as a result of being immediately restarted as per the fix you implemented. When it opens the second time, it no longer has the push payload. That may be the exact situation you're describing, but I just wanted to clarify. Thanks for your help.
I ran into the error below today (same as you Jack Wilson) even though I upgraded to Titanium latest pull on master (SDK 3.4.0v20140716113312). I had it on my emulator GenyMotion CustomPhone 7, Android 4.1.1 API 16. Any idea of what's happening ? [ERROR] : TiApplication: (KrollRuntimeThread) [71,280] Sending event: exception on thread: KrollRuntimeThread msg:java.lang.IllegalStateException: APSAnalytics has not been enabled. Call APSAnalytics.getInstance().enable(ctx, key, deploytype) to enable.; Titanium 3.4.0,2014/07/16 11:33,9d1b1f0 [ERROR] : TiApplication: java.lang.IllegalStateException: APSAnalytics has not been enabled. Call APSAnalytics.getInstance().enable(ctx, key, deploytype) to enable. [ERROR] : TiApplication: at com.appcelerator.analytics.APSAnalytics.throwUnlessEnabled(APSAnalytics.java:251) [ERROR] : TiApplication: at com.appcelerator.analytics.APSAnalytics.sendAppGeoEvent(APSAnalytics.java:155) [ERROR] : TiApplication: at ti.modules.titanium.geolocation.TiLocation.doAnalytics(TiLocation.java:155) [ERROR] : TiApplication: at ti.modules.titanium.geolocation.GeolocationModule.doAnalytics(GeolocationModule.java:230) [ERROR] : TiApplication: at ti.modules.titanium.geolocation.GeolocationModule.onLocationChanged(GeolocationModule.java:248) [ERROR] : TiApplication: at ti.modules.titanium.geolocation.android.LocationProviderProxy.onLocationChanged(LocationProviderProxy.java:112) [ERROR] : TiApplication: at android.location.LocationManager$ListenerTransport._handleMessage(LocationManager.java:234) [ERROR] : TiApplication: at android.location.LocationManager$ListenerTransport.access$000(LocationManager.java:167) [ERROR] : TiApplication: at android.location.LocationManager$ListenerTransport$1.handleMessage(LocationManager.java:183) [ERROR] : TiApplication: at android.os.Handler.dispatchMessage(Handler.java:99) [ERROR] : TiApplication: at android.os.Looper.loop(Looper.java:137) [ERROR] : TiApplication: at org.appcelerator.kroll.KrollRuntime$KrollRuntimeThread.run(KrollRuntime.java:112)
Just had it as well on real device : Moto G / Android 4.4.4 :(
Anyone still having this issue ?
Verified the fix with the analytics app feature test app for QE & did not see any crash. Will be verifying with the customers app & update with the results. Environment: Appc Studio : 3.4.0.201409161950 Ti SDK : 3.4.0.v20140916181713 Mac OSX : 10.9.4 Alloy : 1.5.0-rc2 CLI - 3.4.0-rc4 Code Processor: 1.1.1 Nexus 5 - android 4.4.4
[~sliang] Please provide a new test case to reproduce the issue.
[~ingo], Main problem happened here.
[~sliang], you mentioned the crash happened when the android app was killed. Did you mean swiping app away from the recent apps list? If yes, you can take a look at TIMOB-15180 and TIMOB-14674 to get some idea what happens when you swipe app away. In the code you attached above, can you tell me when the app crashed, what value gcm.isLauncherActivity returns, true or false?
[~pwang], We had customer close the case for now since iamyellow module is not our product. thank you for your feedback. Will contact you if still need something more.
Closing ticket as fixed.