Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1911] Android: Titanium apps can't survive an activity relaunch

GitHub Issuen/a
TypeNew Feature
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2012-02-10T19:50:29.000+0000
Affected Version/sn/a
Fix Version/sSprint 2012-03, Release 2.0.0, Release 1.8.2
ComponentsAndroid
Labelsandroid, feature
ReporterBill Dawson
AssigneeBill Dawson
Created2011-04-15T03:05:22.000+0000
Updated2017-03-24T21:01:49.000+0000

Description

Because of the cleanup code in TiUIWindow (see release()), Titanium apps can't survive an activity relaunch. Even the simplest app:

/*global Ti, Titanium, alert, JSON */
Titanium.UI.setBackgroundColor('#000');
Titanium.UI.createWindow({  
    title:'Test',
    backgroundColor:'#fff',
    fullscreen: true,
    exitOnClose: true
}).open();

To cause an activity relaunch, change the locale while the activity is running. Example:

  • Open a titanium app.

  • Keeping it open (i.e., don't back out), hit your Home key.

  • Go to Settings -> Language & Keyboard -> Select language, then change the language.

  • Go back to the Titanium app -- it will crash.

What's happening can be shown in the attached relaunch_activity.png graphic. Apparently Android forces the activity to relaunch if the locale has changed. This causes onDestroy, which in our code results in the window cleaning up itself, but then activity create occurs again. Now the handler object is null, however, and all views are gone.

Is there some way for us to determine if onDestroy is occurring because of a relaunch?

Attachments

FileDateSize
relaunch_activity.png2011-04-15T03:05:23.000+0000172489
SendLog (2).txt2012-02-08T15:27:36.000+0000152840

Comments

  1. Bill Dawson 2011-04-15

    Assigning to Don for milestone/priority.

  2. Don Thorp 2011-04-15

    Need to add locale to the list of things we handle in the activity definitions in the AndroidManifest.xml see http://developer.android.com/reference/android/R.attr.html#configChanges"> Android Docs

    What I'm not clear of is if we should fire a localeChange event to the activity. It might be a good thing to do.

  3. Neeraj Gupta 2012-02-04

    We have suggested a way to fix this issue to Pedro and awaiting feedback from him.
  4. Opie Cyrus 2012-02-04

    Adding the android:alwaysRetainTaskState="true" flag to the root activity in the manifest section of the tiapp.xml should address the problem of the black screen for the root activity. The following is an example snippet from the Kitchen Sink tiapp.xml 
       <manifest><application>
   <activity android:name=".KitchensinkActivity" 
      android:alwaysRetainTaskState="true" 
      android:configChanges="keyboardHidden|orientation" 
      android:label="Kitchensink" 
      android:name=".KitchensinkActivity" 
      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>
  5. Nikolai Derzhak 2012-02-06

    This issue latest notification was not sent due to JIRA mail setting. Fixed now. Please check the issue for latests changes.
  6. Neeraj Gupta 2012-02-08

    We need to investigate the black screen issue with the work around.
  7. Bill Dawson 2012-02-10

    Testing notes

    The app should now be forced to re-start when the condition is recognized. To test it, put a Titanium app that has multiple heavyweight windows in it, or a TabGroup (like KitchenSink), on the device, and also put Astro or Advanced Task Killer on the device. Then these steps: * Open the Titanium App. Bring it to a state where at least one heavyweight window (or a TabGroup) is open. Then... * Press the Home key/button to go to the home screen, keeping the Titanium App fully loaded. * Now open your favorite task killer app. * Kill the Titanium App. * Restart the Titanium App. You will likely see a flicker while Titanium realizes the condition it's in (an unsupported restart from Android, whereby Android attempts to first show the Activity that was top-most at the time the app was killed, rather than going through the "normal" launch sequence) and then forces a full re-start. If the app hangs or otherwise stays in a non-functional state, then it's a fail. That's expected when you're testing the fail case with Titanium 1.8.1, but if you're testing the fix branch and this happens, then reject the Pull Request and shed a tear for me.
  8. Bill Dawson 2012-02-10

    Pull request ready https://github.com/appcelerator/titanium_mobile/pull/1400
  9. Sander Beck 2012-02-13

    Unfortunately..., the problem persists.
  10. Neeraj Gupta 2012-02-13

    Let us know the build you are using. Did you add the android:alwaysRetainTaskState="true" flag to the root activity in the manifest section of the tiapp.xml as per one of the comments in this bug?
  11. Shawn Lipscomb 2012-02-22

    SDK 1.8.2.v20120221114636 fixed this for me, and I'm *not* using android:alwaysRetainTaskState="true". However, the fix seems like a programmed workaround, in that the Black Screen of Death shows up for an instant, then the entire app goes away, then the app's starts up normally with the splash screen. The question is, why isn't the entire app going away in the first place, like other Android apps do? What's causing part of a Titanium app to stick around when the Android OS attempts to push it out of memory?
  12. Justin Toth 2012-02-22

    I'd like to echo what Shawn has said, that the black screen issue is fixed by upgrading to the latest CI build of 1.8 or 2.0 and that the android:alwaysRetainTaskState="true" isn't required. It seems that many times when the app errors, regardless of whether it's a user bug or a titanium bug, the app just closes and restarts (with messages about WIN DEATH and Tombstones) rather than giving a error popup like in earlier versions of Titanium and Rhino. I hope the Android team can look into this even though the task is resolved.
  13. Mauro Parra-Miranda 2012-02-22

  14. Neeraj Gupta 2012-03-21

    @Eric - Please provide a test case that reproduces this issue. The test case in this ticket does not exhibit this behavior anymore.
  15. Neeraj Gupta 2012-03-21

    @Eric - You should open another ticket for this issue.
  16. Neeraj Gupta 2012-03-21

    @Eric - The question is if you can reproduce the issue with the test in this ticket. If not, please open another ticket with a test case.
  17. Lee Morris 2017-03-24

    Closing ticket as fixed with reference to previous comments.

JSON Source