Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-7293] Android: App Freeze after being too much time in the background

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionDuplicate
Resolution Date2017-03-29T22:23:48.000+0000
Affected Version/sRelease 1.7.5, Release 1.8.0.1
Fix Version/sn/a
ComponentsAndroid
Labelsn/a
ReporterMauro Parra-Miranda
AssigneeBill Dawson
Created2012-01-19T11:21:07.000+0000
Updated2017-03-29T22:23:52.000+0000

Description

PROBLEM DESCRIPTION

blank (black in my case) screen after being to long in the background. App then freezes and the generated report says:
ANR keyDispatchingTimedOut in TiTabActivity
Freeze
Activity appname.android.app/ti.modules.titanium.ui.TiTabActivity
Cause ANR keyDispatchingTimedOut

MORE INFO

Customer tried this, without any success:
<android xmlns:android="http://schemas.android.com/apk/res/android">
        <tool-api-level>8</tool-api-level>
        <manifest android:installLocation="auto" android:versionCode="2" android:versionName="1.1">
            <uses-sdk android:minSdkVersion="7" />
            <supports-screens android:anyDensity="true"
                android:largeScreens="true" android:normalScreens="true" android:smallScreens="true"/>
            <application>
                <activity android:alwaysRetainTaskState="true"
                    android:configChanges="keyboardHidden|orientation"
                    android:label="Applabel"
                    android:name=".ApplabelActivity" android:theme="@style/Theme.Titanium">
                    <intent-filter>
                        <action android:name="android.intent.action.MAIN"/>
                        <category android:name="android.intent.category.LAUNCHER"/>
                    </intent-filter>
                </activity>
            </application>
        </manifest>
    </android>

Attachments

FileDateSize
stacktrace.txt2012-01-19T11:21:33.000+00006302

Comments

  1. Jakub Rzepecki 2012-01-24

    I have these same problem in my app. When it stays in background too long - it freeze to black screen. This same problem occurs when I run two,tree other apps and then try to get back to mine.
  2. Sander Beck 2012-01-30

    Same here! App is Black
  3. Jake H 2012-01-30

    I'm seeing this as well. It's a huge issue that is preventing us from launching our apps. Android only- not happening on iOS.
  4. Thomas Hill 2012-02-06

  5. Joe Falcone 2012-02-10

    There is something seriously wrong with the Activity events which is related to this problem. Our testing was done on 1.8.1 with real Android hardware from HTC, Moto and Samsung. We've also seen this happen with 1.7.x SDK apps. We started monitoring the events thrown by the currentActivity and when the app is started up we get: 02-10 16:56:40.928: I/TiAPI(2528): onCreate: {"source":{"_events":{}},"type":"create"} 02-10 16:56:41.022: I/TiAPI(2528): onStart: {"source":{"_events":{}},"type":"start"} 02-10 16:56:41.022: I/TiAPI(2528): onResume: {"source":{"_events":{}},"type":"resume"} 02-10 16:56:41.030: I/TiAPI(2528): onPause: {"source":{"_events":{}},"type":"pause"} 02-10 16:56:41.538: I/TiAPI(2528): onStop: {"source":{"_events":{}},"type":"stop"} The onPause and onStop appear to be erroneous since the app is running! When the Home button is hit, we get NO EVENT at all - no onPause or onStop events. When the Back button is hit, we get an onDestroy event. Then we duplicated the blank screen problem with the Activity events monitored - and Bingo! This is what we did to get the Blank Screen: 1. Start application X 2. Hit Home Button 3. Go away for 30-45 minutes, maybe use some other apps, maybe not - doesn't seem to make much difference (see note below) 4. Click application X icon to resume 5. Blank screen Now, when we click on the application icon to get the Blank Screen, we get these events: 02-10 17:06:21.117: I/TiAPI(2528): onStart: {"source":{"_events":{}},"type":"start"} 02-10 17:06:21.127: I/TiAPI(2528): onResume: {"source":{"_events":{}},"type":"resume"} And when we click on the Home button again, we get these events 02-10 17:06:29.889: I/TiAPI(2528): onPause: {"source":{"_events":{}},"type":"pause"} 02-10 17:06:30.109: I/TiAPI(2528): onStop: {"source":{"_events":{}},"type":"stop"} Which bizarrely now appears to be normal behavior. Possible workaround is to recognize when we get an onStart + onResume without an immediately preceding onCreate and either kill the app or restart the app.
  6. Bill Dawson 2012-02-10

    cf TIMOB-1911. Though the titles don't suggest it, it's the same underlying issue.
  7. Joe Falcone 2012-02-12

    Attempts at creating a workaround by detecting an onStart + onResume without an immediately preceding onCreate haven't worked. When the app resumes with the blank screen, global variables are available and I'm able to put up an alert screen, but I haven't been able to either kill or restart my app. Sometimes the app goes unresponsive and you get an ANR message.
  8. broadcast zero 2012-02-21

    @joe: how did you manage to get an alert-screen? maybe that could help me...
  9. Joe Falcone 2012-02-26

    You have to maintain a state variable to detect when you get an OnStart + onResume without an immediately preceding onCreate. current.addEventListener ('start', function (e) { Ti.API.info ('onStart: '); if (astate !== 'create') { Ti.API.error ('BLANK SCREEN'); alert ('BLANK SCREEN'); } astate = 'start'; }); What we did is that we restructured our program so that all windows and views are created in functions that are called from the main line code in app.js. And we put code into this event listener that would re-initialize the window state if it detected a BLANK SCREEN problem. But the funny thing is that once we did this, we stopped having these problems. And I think it is because whoever is trying to kill the app to reclaim resources is somehow better able to do a clean kill when the app is structured this way without having its main window declared in the main line in app.js. So the problem went from being predictable every 30-35 minutes after going from the App to Home to not happening at all - but instead we're noticing that the OS is reclaiming the app and we're starting from Splash more often. In my view, no big deal.
  10. broadcast zero 2012-02-27

    thank you for your answer, I'm still suffering from that problem..however, let's try this. thanks again.
  11. broadcast zero 2012-04-05

    -
  12. Paul Hamilton 2012-04-24

    Has this fix been released to any build yet?
  13. Mauro Parra-Miranda 2012-04-24

    Hello Paul, this was fixed in the latest 1.8.x and 2.0.1GA2. Let me know if is still happening to you. Best, Mauro
  14. Paul Hamilton 2012-04-24

    was using 1.8.1 build for my app and was still happening. Going to 2.0.1 and seeing if it still occurs.
  15. Mauro Parra-Miranda 2012-04-24

    AFAIK, it's fixed on 1.8.2/3 and will be easier to go from your app with 1.8.1 SDK to 1.8.2/3 than to 2.0.1GA2. BEst, Mauro
  16. Miles Lyon 2012-04-24

    Similar issue here and I'd like to just upgrade to 1.8.2 if possible, but via Titanium I could only update to 2.0.1GA2. Unfortunately this introduced some new bugs and issues into my app. How do I get the 1.8.2 or 1.8.3 version specifically so I can address this bug with less impact to my app?
  17. Miles Lyon 2012-04-25

    Actually another follow up question as well. If I update to 1.8.2/3 can I leave my app 'as is' or do I still specifically need to add changes to tiapp.xml as listed above? Like is the behavior corrected regardless in 1.8.2 and 2.0.1GA2 or just corrected so that the tiapp.xml changes will now work?
  18. Miles Lyon 2012-04-25

    Can I get a response on how to get v1.8.2 of the SDK?
  19. Neeraj Gupta 2012-04-25

    Please use the steps described here and specify the SDK that you want to use: http://docs.appcelerator.com/titanium/2.0/index.html#!/guide/Installing_Titanium_SDK_Continuous_Builds
  20. Paul Hamilton 2012-04-26

    I wouldn't say this bug was 'fixed'. Bug still exists. The problem is less and the workaround imposed is... interesting. Certainly better then before and i applaud the effort. App goes from being unreleasable to 'i can live with it if i MUST'. I've seen many sweeping changes to Appecelerator and many of the breaking bugs i've encountered have been fixed in a timely manner, within an update or so. Calling this fixed though is a bit of a stretch, although the damage is certainly mitigated. On Android the app still times out and goes to a blank screen. However, when starting back up Titanium seemingly detects this state and closes the app. The user must then manually open the application a 2nd time. This is just terrible user experience, which i know Appcelerator prides itself on. Calling this resolved and not working on it further would be a mistake. Thoughts: Either prevent this state from occuring in the first place or perhaps just have app.js run again if this state is detected? This would occur rather then closing the app. Apps in memory are freed after a period of time and it would not be unreasonable and/or expected to have to start from the beginning after being away from the application for a long period of time.
  21. Lee Morris 2017-03-29

    Closing ticket with reference to the linked issues.

JSON Source