Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-15253] Android: singleTask launchMode with HeavyWeight window hangs after 1st launch

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2017-03-29T18:46:12.000+0000
Affected Version/sn/a
Fix Version/sRelease 6.0.3
ComponentsAndroid
Labelsandroid, heavyweight, launchmode, merge-6.0.3, singletask
ReporterFokke Zandbergen
AssigneeGary Mathews
Created2013-08-26T08:57:50.000+0000
Updated2019-01-11T03:37:20.000+0000

Description

When launching your app with it's main activity set to android:launchMode="singleTask" and it's main window a HeavyWeight one, it will hang on the second and every following launch. This bug blocks me from allowing users to open my app by using an URL scheme on a webpage or in a email message, send to them when they lost their password, received an invite to play a game etc.

Why use launchMode?

By default, when launching your app via another app, e.g. using an URL scheme in the browser, your apps main activity will be stacked onto the current app's task. If your app was already running in the background, you will have 2 instances of the app running. Android has a [launchMode](http://developer.android.com/guide/topics/manifest/activity-element.html#lmode) attribute that allows you to instruct the OS to always open the activity as the root of a new task, using singleTask as value. This works fine, but not when the app's main window is HeavyWeight, for example a Ti.UI.TabGroup or a Ti.UI.Window with modal:false.

To reproduce

Create a new project: titanium create -p android -n test

Build (only) to generate manifest: titanium build -b -p android

Open the generated build/android/AndroidManifest.xml and copy the first <activity> tree to the tiapp.xml under ti:app/android/manifest/application. You will need to create the empty <manifest> and <application> elements yourself.

Add android:launchMode="singleTask" to the <activity> element and save tiapp.xml.

Build the app to the device: titanium build -p android -T device

Open the updated AndroidManifest.xml to confirm the only effective change is the newly added attribute.

Seeing the app properly launched on the device, move it to the background by clicking the device's home button.

Lookup the app on the device and launch it again. You'll see a black screen with a titlebar (test) only.

Now replace the app's app.js with a lightweight window instead of the default heavyweight tabgroup:

    Ti.UI.createWindow({backgroundColor:'white'}).open();

Repeat steps 5-8 and this time, the app will properly launch.

Comments

  1. Fokke Zandbergen 2013-08-26

    For a use case see my blog at: http://fokkezb.nl/2013/08/26/url-schemes-for-ios-and-android-1/
  2. Fokke Zandbergen 2013-08-28

    Update: Even if the main application window is light, opening any heavy window will cause the app to hang on a black screen the next time you launch it from the app list. Please make this an urgent issue for 3.2 guys!
  3. Fokke Zandbergen 2013-08-28

    Update: I think this is somehow related to the ti.android.bug2373.finishfalseroot (TIMOB-9285). I was working on a workaround that was binding the URL scheme to launch the app (which is the main use-case I need singleTask for) to a new activity/JS file like this: 
    	<android xmlns:android="http://schemas.android.com/apk/res/android">
   		<activities>
   			<activity url="incoming.js">
                   <intent-filter>
                       <action android:name="android.intent.action.VIEW"/>
                       <category android:name="android.intent.category.DEFAULT"/>
                       <category android:name="android.intent.category.BROWSABLE"/>
                       <data android:scheme="incoming"/>
                   </intent-filter>
   			</activity>
   		</activities>
   	</android>
    In the incoming.js I tried to launch the actual app by doing: 
       var intent = Ti.Android.createIntent({
       action: Ti.Android.ACTION_MAIN,
       category: Ti.Android.CATEGORY_LAUNCHER,
       className: 'nl.fokkezb.test.scheme.TestActivity',
       packageName: 'nl.fokkezb.test.scheme'
   });
    
   Ti.Android.currentActivity.startActivity(intent);
    This actually worked, but showed the An application restart is required message. So I added the ti.android.bug2373.finishfalseroot property to my tiapp.xml. And guess what? I got the exact same behavior described in the test case of this ticket: a black screen of death. Hope this is of some help?
  4. Fokke Zandbergen 2013-08-28

    [~ingo], any change we can have this fixed in 3.1.3?
  5. Motiur Rahman 2013-09-16

    Hi, Could you please provide test case. Thanks,
  6. Fokke Zandbergen 2013-09-16

    The description already includes the steps to reproduce, under *Why use lauchMode* I explain why this should be fixed and at http://fokkezb.nl/2013/08/26/url-schemes-for-ios-and-android-1/ I have a use case. What is it what you need more?
  7. Fokke Zandbergen 2013-09-19

    Ugly workaround is to launch the app using the [intent-based URI](https://developers.google.com/chrome/mobile/docs/intents) with the [FLAG_ACTIVITY_NEW_TASK](http://developer.android.com/reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK) flag set: 
       <a href="intent://#Intent;scheme=myscheme;package=my.package.name;launchFlags=268435456;end;">
  8. Romain 2013-10-12

    Same issue for us. Really annoying :(
  9. Allen Yeung 2013-10-25

    Unfortunately, we can't support the singleTask mode with the current Titanium architecture. When you background the app, and go back to it, the screen is black since the tab group activity gets destroyed. The singletask mode seems to destroy all other activity in the task, besides the activity that is marked as single task. This is a problem since we don't re-run the app.js code in this case (and we shouldn't since this is done as a part of the v8 runtime initialization). Fokke actually pointed out a workaround which I have tested and seems to work well. Inside the tiapp.xml of the 'singletask' app, you need to place the finishfalseroot flag. 
       <property name="ti.android.bug2373.finishfalseroot" type="bool">true</property>
    In the other app that you want to launch the 'singletask' app, You need to do the following: 
       var intent = Ti.Android.createIntent({
       action: Ti.Android.ACTION_MAIN,
       flags: Ti.Android.FLAG_ACTIVITY_NEW_TASK,
       category: Ti.Android.CATEGORY_LAUNCHER,
       className: "com.mytest.MytestActivity",
       packageName: "com.mytest"
   });
   Ti.Android.currentActivity.startActivity(intent);
    The key here is to use the FLAG_ACTIVITY_NEW_TASK flag when launching the app with the finishfalseroot set to true. We are actively working to make this a non-issue in the Ti.Next architecture.
  10. Fokke Zandbergen 2013-10-27

    I hate seeing this postponed to TiNext, but I understand why it has too. To call the intent from an URL, you would have to attach a scheme to the activity and then use the #Intent anchor to add the same flag like this: 
    intent://#Intent;package=com.myTest;scheme=myScheme;launchFlags=268435456;end;
     For more details check my blog: http://fokkezb.nl/2013/09/20/url-schemes-for-ios-and-android-2/
  11. Brenton House 2015-06-08

    Is there a workaround for this that works in 4.0.x?
  12. josh rose 2015-07-23

    Would very much like to see this fixed!
  13. Fokke Zandbergen 2015-09-25

    I think it would be good if we'd test and fix the underlying results developers want to achieve: * Be able to launch the app from an email/browser using a URL or other data scheme without creating a second instance off the app in the current activity stack if the app is already open in another.
  14. Hieu Pham 2015-11-16

    Behavior is expected for "singleTask". So the Titanium flow is something like this: 
        Root activity -> first window/tabgroup -> second window, so on
    When you assign the Root Activity as "singleTask" launch mode, your first launch would do: Root activity -> first window/tabgroup (it works as expected) However, when you hit the home button, all activities after the root will be destroyed, so when the app is relaunched, only the root activity is shown. This result in the black window, cause the splash screen is now gone. This used to work with Lightweight windows is because LW is actually a view on top of the Root Activity.
  15. Hieu Pham 2015-11-19

    I did some research and I don't think "singleTask" is a viable solution to this problem. This is because all activities but the one assigned with "singleTask" are destroyed when the app is resume. Even if we can make it work, the app would have to restart every time you background/foreground, which is not what we want. We would need to investigate further for other solutions.
  16. Fokke Zandbergen 2015-11-20

    It's a long a time ago but I think we started using singleTask because: {quote} By default, when launching your app via another app, e.g. using an URL scheme in the browser, your apps main activity will be stacked onto the current app's task. If your app was already running in the background, you will have 2 instances of the app running. {quote} So in the end the ticket is not about singleTask but about the question: _How to to open a Titanium via a custom URL *AND* prevent multiple instances *AND* without requiring launch flags with the URL_
  17. Ganna Kozynenko 2016-01-20

    I am currently struggling with the same (branch.io request that I have my launcher as single task), and I added an OnResume function onto the main (launcher) activity, in which I re-read my index.... so far so good, that seems to work. Anyone sees any problem with this approach? This comes very early in my alloy.js : 
        if (OS_ANDROID)
    {
    	function resumeLauncher() {Alloy.createController('index',{});}
    	if (Ti.Android.currentActivity) {Ti.Android.currentActivity.setOnResume(resumeLauncher)}
    }
  18. Fokke Zandbergen 2016-01-22

    [~annakozy@direcciona.me] thanks for sharing that workaround! [~cng] if this works then it seems like when the app resumes in singleTask launchMode the existing activities (windows) are killed and [~annakozy@direcciona.me]'s code handles this by re-opening the index controller. Do you see any downsides? If not, then this might be documented as the official way to implement singleTask launchMode and we can support URL schemes on Android, jay!
  19. Ganna Kozynenko 2016-01-22

    Yes, there is a problem, not so much with the workaround as with single task itself. It indeed destroys all the activities above the one marked as single task, so maintaining the application state (other open windows) becomes a problem, including background audio. Update: I did more testing. No, it does not actually destroy anything when put into background, even audio keeps playing, it's FOREGROUNDING that creates problems. If you foreground it from the list of activities (on my phone it appears by pressing and holding home button), nothing happens. However if you restart the activity from the icon again, then the child activities are destroyed/restarted
  20. Fokke Zandbergen 2016-03-01

    I created TIMOB-20490 to talk about this from the user POV.
  21. Ganna Kozynenko 2016-03-01

    I have read more about it, and to me it looks like a generic Android problem, not even really Appc-specific.... applies to any app where some activities are single task and others are not. I am using my workaround which is kinda working, but I am not really sure where to move from there.
  22. Abdiel Aviles 2016-06-28

    I tried the workaround mentioned by [~annakozy@direcciona.me] and it works... but it makes my app unstable and crashes sporadically when resumed. Without the workaround, resuming the app from a URL scheme freezes on the Splash screen. I followed [~fokkezb] article on implementing URL schemes. Any further suggestions?
  23. Ryan Gartin 2016-08-26

    I believe this bug is preventing full integration with Branch.io.
  24. Ashraf Abu 2016-08-29

    What exactly is needed for Branch.io?
  25. Ryan Gartin 2016-09-07

  26. Ganna Kozynenko 2016-09-07

    In the first place, if you dont use singleTask, and you already have your application open, you will have two or more instances of your application open when you launch it from Branch link. As a user, you can see all those instances if you click that button to show the list of running apps on Android It is confusing for the user and I also dont know if it might be confusing for Branch statistics in some way
  27. Ganna Kozynenko 2016-09-07

    Just for the record. I still keep re-reading index controller. I did have to do some usual magic to make sure index.js knows it is being reopened (I send it a parameter in arguments like for any other controller), so that it does not add some listeners for the second time. It's been rather stable except for some not frequent cases when it STILL gets stuck at launcher. But this looks like the app fails to register onResume function with the launcher activity (Ti.Android.currentActivity must be something else at the beginning of alloy.js in this case - it often happens when I launch the app from Ti.Studio, but it works ok in normal workflow). Separating launcher in a separate variable could help with this (so I can always add onResume for launcher) But other than that and the typical bugs of duplicated Ti.App.addEventListener, I am fine
  28. Ganna Kozynenko 2016-09-07

    Its been since mid-january that we've been rather integrated with Branch and using single task Its not perfect (in testing environment, I can recreate some less-than-perfect behaviors), but this does not seem to cause many user complaints
  29. Ganna Kozynenko 2016-09-07

    Point is, I do not experience "sporadic crashes" documented earlier by someone when I am re-reading index controller, or any instability that cant be solved by usual measures of sorting things into "must only do on cold start" and "can do always" (the difference between those cases is easy to spot by passing a parameter into index, when you reopen it)
  30. Ganna Kozynenko 2016-09-07

    As a matter of fact, if we teach appcelerator developers to treat index.js like any other window.... most of the problem with singleTask will go away. The problem is perhaps due to the programming style when people assume that index.js is only being read once and put a lot of unsafe stuff there (having listeners added and not removed, ignoring the usual cleanup etc.). Everything that cant be safely repeated should probably be ideally in alloy.js
  31. Gary Mathews 2017-01-12

    master: https://github.com/appcelerator/titanium_mobile/pull/8747
  32. Lokesh Choudhary 2017-03-02

    Did a check with the PR & found an issue. Commented about it in the PR. Will continue to test after the issue has been looked at.
  33. Creative 2017-03-02

    bump, i would appreciate this to be fixed soon since its an ongoing issue since 2013. I am too running into issues because I'm implementing push notifications and url schemes
  34. Lokesh Choudhary 2017-03-10

    PR merged. Waiting for build to close the ticket.
  35. Brian Knorr 2017-03-10

    If this fix is going in 6.0.3, when will 6.0.3 be released? We just ran into this issue for one of AppC's big clients - we are the dev shop. Should I open an enterprise support ticket or is this going out really soon?
  36. Gary Mathews 2017-03-10

    6_0_X: https://github.com/appcelerator/titanium_mobile/pull/8879
  37. Hans Knöchel 2017-03-10

  38. Lokesh Choudhary 2017-03-10

    Verified the fix with SDK 6.1.0.v20170309181051. Waiting for 6.0.3 built to close the issue.
  39. Lokesh Choudhary 2017-03-10

    Verified the fix with SDK 6.0.3.v20170310122139. Closing the ticket.
  40. Michael Kazmier 2017-03-22

    Hi everyone, I recognize that this ticket is closed, but I am testing the functionality on 6.0.3.v20170322115949 and I still do not think this is working correctly. Let me provide a quick example. My app's main activity looks like this (from tiapp.xml): com.kudoso.mobile.KudosoActivity Now, we have a service that runs that fires off a new intent with Extras when certain system events happen. Using SDK 6.x and either singleTop or singleTask mode, we correctly launch our app now (that is win!) BUT we are still losing the intent information. In our app, we log the new intent, and it is missing the extras, see here: [DEBUG] ----------------------------------- EVENT newintent ----------------------------------- [DEBUG] NEW INTENT {"type":null,"packageName":"com.kudoso.mobile","className":"org.appcelerator.titanium.TiActivity","action":null,"flags":0,"data":null,"apiName":"Ti.Android.Intent","bubbleParent":true} WITH EXTRA: null What is important to note is the class name of the intent! Our service fires off the intent as com.kudoso.mobile/com.kudoso.mobile.KudosoActivity but the app receives com.kudoso.mobile/org.appcelerator.titanium.TiActivity. Why??? I cannot seem to track this down in the SDK.
  41. Caio Iglesias 2017-03-27

    I still see it hanging as soon as the android:launchMode="singleTask" flag is added, running on 6.0.3.GA. It works on the first launch only. If the app was already running and you try opening a link, it hangs.
  42. Brian Knorr 2017-03-28

    We are seeing the same issue with it only working on first launch using 6.0.3.GA. Please re-open this ticket.
  43. Brian Knorr 2017-03-28

    Also I don't know if this makes a difference, but we are using Hyperloop as well.
  44. Eric Merriman 2017-03-28

    Reopening to investigate field reports.
  45. Gary Mathews 2017-03-29

    Updated documentation and intent filter guide as part of https://github.com/appcelerator/titanium_mobile/pull/8897
  46. David Jones 2017-03-29

    I saw the documentation update in the most recent PR stating: "Defining launch modes using android:launchMode is not supported by Titanium Android. However, singleTask behaviour can be accomplished when using [intent filters](http://docs.appcelerator.com/platform/latest/#!/guide/Android_Intent_Filters)." If we are responding to a custom scheme link initiated from the user's browser - how can we specify a true 'singleTask' launch of our application? I did not find any corresponding information for this in the linked-to documentation on intent-filter. It works for us if our app is closed, but when our app is already open we get stuck at the splash screen. Note we have set this property as well, with no change in result: {noformat} true {noformat}
  47. Abdiel Aviles 2017-03-29

    We have exactly the same situation as @jonesdhtx We currently have our schemes disabled for our Android users and enabled for our iOS users... not good at all.
  48. Brian Knorr 2017-03-29

    I just saw that this issue was marked as resolved....what is the resolution for handling url schemes in Android? Are you opening another ticket for this? Do we need to open a new ticket?
  49. Gary Mathews 2017-03-29

    [~jonesdhtx] What Titanium SDK version are you using? Could you provide example code to reproduce the issue?
  50. David Jones 2017-03-29

    Using 6.0.3.GA Here is some example code for showing the app is not getting launched as a new task for 2nd/subsequent invocations. Referring to the code below: 1) In initial state, app not running - In the phone browser click on the link in the test html page 2) App logs our custom message: "Launched as New Task" and opens successfully. 3) Now leaving app open, return to the test html page, and click on the same link again 4) App logs our custom message: "Launched as Resumed/Recycled Task" and the app ux shows only the splash screen Tiapp.xml is setup as: {noformat} http://ti.appcelerator.org"> ... true true ... http://schemas.android.com/apk/res/android"> ... 6.0.3.GA ... ti.alloy hyperloop ... ... {noformat} Code from our top-level alloy controller: app/controllers/index.js to let us know if app is being started as new task or not: {noformat} if(Alloy.Globals.hasBeenPreviouslyLaunched) { console.log('Launched as Resumed/Recycled Task') } else { console.log('Launched as New Task') Alloy.Globals.hasBeenPreviouslyLaunched = true; } {noformat} The html test page used to launch the app: {noformat} Launch App {noformat}
  51. Abdiel Aviles 2017-03-29

    resolved? kudos to [~jonesdhtx]
  52. Brian Knorr 2017-03-31

    Can we get this ticket re-opened now that we have the test case from David? Our client has an enterprise support ticket that is tracking this jira issue, but if you decide to not reopen we will need to reference a new ticket.
  53. Creative 2017-04-04

    request re-open. I cant seem to retrieve intent data now when resuming my app from background
  54. Hans Knöchel 2017-04-04

    Please try https://github.com/appcelerator/titanium_mobile/pull/8897 (TIMOB-24316) for SDK Release 6.0.4.
  55. Creative 2017-04-04

    i guess this has to be built from source? Anyone able to provide a .zip?
  56. David Jones 2017-04-04

    Looks like @Gary Mathews has put together a newer PR for 6.0.4 that includes #8897 as well as a couple other related PR's: PR# 8910 (https://github.com/appcelerator/titanium_mobile/pull/8910) which includes cherry-pick of #8894 #8897 #8908 addressing TIMOB-24497, TIMOB-24316, TIMOB-24527 How can we get an sdk build w/ these changes incorporated (prior to 6.0.4 release) to verify these fixes addressed our problem?
  57. Lokesh Choudhary 2017-04-04

    Everyone, please check this build below which is built for PR https://github.com/appcelerator/titanium_mobile/pull/8910 & let us know if this resolves your issue. Link: https://www.dropbox.com/s/lbc9tvzl8z7e34w/6.0.4.zip?dl=1 *NOTE* : Do not use this for any of your production apps as this build is not GA & might have bugs/issues.
  58. David Jones 2017-04-05

    The #8910 PR build (https://www.dropbox.com/s/lbc9tvzl8z7e34w/6.0.4.zip?dl=1) is an improvement but the issue is not fully resolved.

    Before #8910 PR, I was getting this:

    1) From initial state with app not running - In the phone browser click on a link in a test html page eg: Launch App 2) Our app opens successfully and handles the link accordingly 3) Now leaving app open, return to the test html page, and click on the same link again 4) Our app ux hangs and shows only the splash screen

    Now with #8910 applied, I am getting this:

    1) From initial state with app not running - In the phone browser click on a link in a test html page eg: Launch App 2) Our app opens successfully and handles the link accordingly 3) Now leaving app open, return to the test html page, and click on the same link again 4) Our app now opens successfully and handles the link accordingly 5) Repeat steps 3 and 4 any number of times and note it continues to work as expected 6) Now still leaving app open - return to the test html page and click on a *different* link this time: eg: Launch App 7) Our app ux now hangs and shows only the splash screen

    ALSO: I noticed that it will fail in the same way if the app is open before the initial link click:

    1) From initial state with app not running - start the app from the app launcher 2) With the app launched and running normally, leave it open and then in the phone browser click on a link in a test html page eg: Launch App 3) Our app ux now hangs and shows only the splash screen
  59. Hans Knöchel 2017-04-05

    Thanks for the feedback David, we are looking into it. But please use the Preview button on the left to check your comment before submitting. All watchers (62+) just received 11 mails regarding your edited comment. We are trying to keep the flow as clean as possible, thx.
  60. Creative 2017-04-05

    I'm having issues with the test build of 6.0.4.GA too. I've created a post at https://github.com/appcelerator/titanium_mobile/pull/8910 (i dont know if this is the preferred location to post that)
  61. Brian Knorr 2017-04-05

    Can we get this ticket re-opened so the axway support team doesn't update our enterprise support tickets as resolved?
  62. Gary Mathews 2017-04-06

    [~jonesdhtx] I can't reproduce your problem, try this build: [6.0.4_20170406_ddc37c0.zip](https://www.dropbox.com/s/404tr0d1kv54o9w/6.0.4_20170406_ddc37c0.zip?dl=1)
  63. David Jones 2017-04-07

    @Gary Mathews - The 6.0.4_20170406_ddc37c0.zip build did not help the failing scenarios I encountered, and it also re-introduced the earlier problem I was having as well. Since you are not able to reproduce the issue on your side - I will try to find some time to put together a full minimal project demonstrating the issues that I can zip up and attach to this ticket.
  64. David Jones 2017-04-17

    @Gary Mathews - Here's a link to a sample project zip that demonstrates the problem: https://www.dropbox.com/s/5o4v1bayqlsr83t/SampleProject.zip?dl=0 However, after playing around with it some more, I'm thinking the reason you weren't seeing the problem before might have to do with the use of back button vs home button (or task switcher). Here's a copy of the sample project readme w/ more details:

    SampleApp README

    This sample app demonstrates that under the scenario outlined below, the app is not getting launched as a new task on Android. Once the sample app is built and deployed to device, you can access the following web page to launch it: [https://obscure-beach-58781.herokuapp.com] The above page simply contains the following 2 links for launching the app: 
          <a href="sampleapp://order/11112222">Manage Order 11112222</a>
      <a href="sampleapp://order/33334444">Manage Order 33334444</a>
    One more note: As mentioned by another poster, there is another issue that is occuring when the app is closed and opened for first time. When doing so we see a "double" launch effect where splash screen and initial screen seems to get displayed twice quickly upon launch.

    Failure Mode

    If you use the "Task Switcher" to switch between apps you see that the app is not started as a new task. Alternatively, if you press the home button to leave the app and reopen the browser from launch screen it will fail in the same way. * App closed * In browser, launch sample app w/ link to order 11112222: 1: *_ App started as New Task _* 2: Handling: sampleapp://order/11112222 * Use the "Task Switcher" to go back to browser * Launch w/ link to order 11112222 again: 1: *_ App started as Resumed/Recycled Task _* 2: Handling: sampleapp://order/11112222 * Use the "Task Switcher" to go back to browser * Launch w/ link to order 33334444: 1: *_ App started as Resumed/Recycled Task _* 2: Handling: sampleapp://order/33334444

    Success Mode

    However if you use the back button to switch between apps it is behaving as expected: * App closed * In browser, launch sample app w/ link to order 11112222: 1: *_ App started as New Task _* 2: Handling: sampleapp://order/11112222 * Use the "Back Button" to go back to to browser * Launch w/ link to order 11112222 again: 1: *_ App started as New Task _* 2: Handling: sampleapp://order/11112222 * Use the "Back Button" to go back to to browser * Launch w/ link to order 33334444: 1: *_ App started as New Task _* 2: Handling: sampleapp://order/33334444

    Notes:

    The key may be in the differences in back vs home button handling on android. There are multiple sources of info on this, here's a quick description grabbed from [http://stackoverflow.com/questions/34081835/difference-between-back-press-and-home-button-in-android] {quote}After you start an activity, if HOME key is pressed, then the current activity is stopped and its task goes into the background. The system retains the state of the activity - i.e. onSaveInstanceState will be called. If the user later resumes the task by selecting the launcher icon that began the task again, the task comes to the foreground and resumes the activity at the top of the stack. However, if BACK key is pressed, the current activity is popped from the stack and destroyed. The assmuption is the activity is done and will not be used again. So the system does not retain the activity's state - i.e. onSaveInstanceState will not be called. {quote}
  65. Gary Mathews 2017-04-19

    [~djonesax] That is expected and usually preferred behaviour, [FLAG_ACTIVITY_NEW_TASK](https://developer.android.com/reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK) states "_When using this flag, if a task is already running for the activity you are now starting, then a new activity will not be started; instead, the current task will simply be brought to the front of the screen with the state it was last in._".
  66. David Jones 2017-04-19

    However - the current task is not simply being brought to front of the screen. We are seeing that the our app is being "pseudo-restarted" when we get the second invocation. In other words: we see that our Alloy.Globals object is still intact via an explicit property we set when first launched , but yet a new instance of our application controller/view is being created and shown.
  67. David Jones 2017-04-24

    Were you able to recreate the issue? Are you planning to address the issue on this ticket or should we create a new one?
  68. Andrea Vitale 2017-07-06

    This is definitively not resolved for me. I'm on 6.1.1.GA and I added <property name="intent-filter-new-task" type="bool">true</property> inside my tiapp.xml: - launch the app - push it to the background using the home button - click on a link that can be handled by the app - the app tries to reopen itself but it crashes with the stacktrace reported below 
        07-06 19:46:35.953  7451  7451 E AndroidRuntime: FATAL EXCEPTION: main
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: Process: com.myapp, PID: 7451
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.myapp/com.myapp}: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Object org.appcelerator.kroll.KrollDict.get(java.lang.Object)' on a null object reference
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2416)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2476)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.ActivityThread.-wrap11(ActivityThread.java)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1344)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:102)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:148)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:5417)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.Object org.appcelerator.kroll.KrollDict.get(java.lang.Object)' on a null object reference
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.kroll.KrollProxy.onPropertyChanged(KrollProxy.java:965)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.kroll.runtime.v8.V8Runtime.nativeRunModule(Native Method)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.kroll.runtime.v8.V8Runtime.doRunModule(V8Runtime.java:196)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.kroll.KrollRuntime.runModule(KrollRuntime.java:241)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.titanium.TiLaunchActivity.loadActivityScript(TiLaunchActivity.java:128)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.titanium.TiLaunchActivity.windowCreated(TiLaunchActivity.java:183)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.titanium.TiRootActivity.windowCreated(TiRootActivity.java:172)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.titanium.TiBaseActivity.onCreate(TiBaseActivity.java:676)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.titanium.TiLaunchActivity.onCreate(TiLaunchActivity.java:169)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at org.appcelerator.titanium.TiRootActivity.onCreate(TiRootActivity.java:161)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.Activity.performCreate(Activity.java:6237)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1107)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2369)
    07-06 19:46:35.953  7451  7451 E AndroidRuntime: 	... 9 more
  69. Eric Merriman 2018-08-06

    Cleaning up older fixed issues. If this issue should not have been closed as fixed, please reopen.
  70. Jake Dempsey 2018-12-19

    I am experiencing this same issue with 7.4.1GA. If my app is not started and I launch it with a url scheme it launches. If the app is already running and I launch it with a url scheme it freezes at the splash screen. This issue seems to still be broken.
  71. Joshua Quick 2019-01-11

    This "singleTask" behavior is not a bug and is by Google's design. When using launch mode "singleTask", the Android OS will automatically close all child activity windows when resuming your app. The splash screen is the root activity. So, the app is not hung. The child windows have been forcefully closed by the Android OS and Titanium does correctly fire their associated "close" events. As of Titanium 8.0.0, we're providing another option which doesn't involve "singleTask" (which I recommend that you don't use). In 8.0.0, we've completely refactored our intent handling so that an existing app instance will be resumed and the "newintent" event will be correctly fired when a new intent has been received. This way an Android app behaves a bit more like iOS, which is what everyone is after. Please see [TIMOB-26075] for more details.

JSON Source