Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-9285] Android: Message "An application restart is required" fires incorrectly.

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2013-05-23T06:47:27.000+0000
Affected Version/sRelease 2.1.0, Release 2.0.1
Fix Version/sSprint 2012-16 Core, Release 2.1.2, Release 3.0.0, Release 3.1.0, 2012 Sprint 21 Core, 2012 Sprint 21, Release 2.0.3
ComponentsAndroid
LabelsSupportTeam, core
ReporterPaul Hamilton
AssigneeBill Dawson
Created2012-05-21T09:04:52.000+0000
Updated2019-01-11T03:29:26.000+0000

Description

Attachments

FileDateSize
crash-nexus7.txt2012-08-01T20:16:42.000+000012206

Comments

  1. Frank Apap 2012-06-11

    This is happening to me a lot. I'm on a ICS phone and it's even worse then before. If I exit my app and then try to start it from the "recent apps" pull down this "error" occurs.
  2. Sindre Sorhus 2012-07-09

    Seriously, this is bad... Please prioritize this ticket! Still happening in Titanium SDK 2.1.0
  3. Zane Wright 2012-07-11

    Recreating the home screen icon stops this alert from appearing. Doesn't fix the issue of launching from installer activity though.
  4. Frank Apap 2012-07-16

    It appears that this issue can also cause a crash report: http://developer.appcelerator.com/question/139282/crash-reports-with-this-message#comment-132936 I can't reproduce at will but have witnessed the stack trace seen in the above link occur after clicking OK on the restart message.
  5. David Asher 2012-07-21

    This happens every time for my app, using 2.1 and 2.02. This does NOT happen when building under 1.8. My first user after the app was posted found this bug, posted a comment and one star for my app. After five months of work this is tragic and I had to pull down the app. The fix that was introduced by Appcelerator, tiapp.xml settings, is shameful because it presents no acceptable solution for an end user experience. My source code is open: https://github.com/mapocosm/Map-Explorer-Open
  6. Taka Torimoto 2012-07-22

    Please get this fixed - a huge concern from clients - I am using 2.1.0 on a ICS 4.0 device directly installing an APK file - doesn't happen in the Emulator running Android 2.3.3.
  7. Bill Dawson 2012-07-27

    Discussion

    This discussion serves as a little background on the infamous Android bug [2373](http://code.google.com/p/android/issues/detail?id=2373) (and its offshoots, bugs [5277](http://code.google.com/p/android/issues/detail?id=5277) and [26658](http://code.google.com/p/android/issues/detail?id=26658)) and describes: a) What we've done in the past to help developers get around it, b) What the bug was that gave rise to this specific JIRA ticket, and c) A new option I'm providing to approach the handling of Android bug 2373 in, I think, a better way.

    2373 backgrounder

    Many of you will know this stuff already, but since so many people are following this JIRA ticket, I thought it might be worthwhile to hearken back to the original problem and give some background information. 2373 is a "bug" that has been around for quite a while. I use scare quotes around "bug" because I think it's safe to say at this point that Google does not consider the behavior a bug, though I and many others certainly do. In a nutshell, the bug manifests itself like this: a) Your app is downloaded from the Play Store and installed (automatically) using the Installer app on the device. b) When the Installer app is finished, it shows an option to "Open" the app. Alternatively, if the installation was occurring in the background, you get a Notification when the installation is completed. c) If you then click "Open" in the Installer app to run your app right away (or, alternatively, select the Notification, which also launches it right away), your app's launcher Activity (that's defined in AndroidManifest.xml) gets started with flags 0x10000000. (I think that's the right number of zeroes. :-) ) d) If you then put your app in the background, and later go back to it using the apps screen (i.e., _not_ the app history / recent apps list), your launcher Activity will then be started with flags 0x10200000. e) This difference in the flags will cause the launch from the apps screen to create a wholly new instance of your launcher Activity and put it on top of the Activity stack. Meanwhile, that first instance is still back there as well. The fact that a second instance of your launcher Activity is created and shown to the user is considered a bug by many including myself. After all, it is definitely _not_ what a user would expect. Before backgrounding your app the first time, they may have gone "deep" into it (opening additional Activities, etc.) When they background it and go back to it using the apps screen, they expect to see exactly what they just left, not your launcher Activity all over again. In Titanium's case, this bug means that app.js would get run twice. Of course you might do all sorts of setup work in app.js that you only want to do once and that might even be dangerous or buggy if done twice in the same application. Some native app developers apparently _don't_ care about this anomalous behavior. Presumably their startup code isn't dangerous if run twice. One example is Google itself with their Google I/O 2012 application (the [source code](http://code.google.com/p/iosched/) for which they have made available to the public.) If you install Google I/O 2012 from the Play Store and go through the steps I describe above, you'll see the 2373 behavior: a) Install Google I/O 2012 from the Play Store. b) When done installing, launch it from the "Open" button shown to you by the Installer app, or by selecting the Notification if you get one. c) When it loads, you'll be presented with a screen to verify which Google ID you want to use for the app. Leave that screen there and background the app by touching the Home button/icon. d) Go back to the app using the apps screen (_not_ the list of recent apps). e) You'll again see the screen to select the Google ID to use for the app. f) Press the back button to back out of that screen. g) It will look like the back button didn't work, because you'll still see the screen to select a Google ID. In fact, what just happened was you backed out of the second instance of their home activity, only to land back on top of the first instance of it. Indeed if you look at the app's [source code](http://code.google.com/p/iosched/), you'll see that they didn't put any kind of special logic/handling in there to account for the 2373 anomalous behavior. It could be they don't think it's anomalous. But a lot of people do think it is. You can see the same behavior with the Facebook app, by the way.

    The original Titanium workaround

    Of course we have no control over which flags the Installer app sets on the Intent to launch your application. Our goal was therefore to provide you with a way to restart the app with the "better" Intent flags so that a second instance of your launcher Activity (i.e., app.js in Titanium parlance) wouldn't run when the user selected your app from the apps screen. We considered the behavior anomalous enough to make forcing a restart the _default_ behavior in Titanium. Because it's obviously distracting to the user, we provided ways to disable the restarts (and thus "live with" 2373 behavior) or at least customize what you show the user to force the restart. These options are the [tiapp.xml properties](http://docs.appcelerator.com/titanium/2.1/index.html#!/guide/tiapp.xml_and_timodule.xml_Reference-section-29004921_tiapp.xmlandtimodule.xmlReference-Androidspecificsection) whose names begin with "ti.android.bug2373".

    The bug in this JIRA ticket

    Beginning with Android 3.0, the Intent flags that are sent to start your Activity if your app is selected from the history / recent apps list are different than they were pre-3.0, and this fact messed up our logic that detects the 2373 condition. The result is that if your app is installed from the Play Store and started right away from the Installer or a Notification, and then the user backs out of your app and later goes back to it from the history list (a very common usage pattern, of course), they would see the "Application restart required" message _again_. I've fixed that by changing our detection logic.

    A new approach to 2373 handling

    The last thing we want is yet-another-2373-related-tiapp-property, but indeed I've introduced one now in the commits related to this ticket. I'm hoping this new property can give a near perfect user experience. The goal of this new property (and the code that goes along with it) is to not bother the user at all, and at the same time not show the 2373 anomalous behavior. It works by simply putting this one 2373-related property in your tiapp.xml as such: 
       <property name="ti.android.bug2373.finishfalseroot" type="bool">true</property>
    This "finishfalseroot" (finish false root) property, if set to true, will mean your app will not need to be restarted when opening from the Installer/Notification, and then, when the 2373 anomalous behavior is detected -- namely, a new, second, unwanted instance of your launcher Activity comes into being if the user selects your app from the apps screen after backgrounding it -- the unwanted Activity is simply destroyed immediately (the native code calls finish() right away in the Activity's onCreate handler -- if you've followed the state of the art in suggestions provided in comments to bug 2373, you'll know about this approach.) Because the Activity is destroyed immediately, the user won't even see any part of it. Meanwhile your app has also come forward, so what they _will_ see is where they last were in your app, which is precisely the behavior you want. So once my commits are merged, I encourage those of you who are watching this ticket to use a new build from the [continuous build server](http://builds.appcelerator.com.s3.amazonaws.com/index.html) and try out this new property with your app(s). If it seems stable and works as expected, I believe we would like to make it the default behavior in a future version.
  8. Bill Dawson 2012-07-27

    Testing Notes

    Fail case / test case

    These instructions use the ASTRO File Manager app as an easy way to get the Installer app to run when opening an .apk on stored on the sdcard. An alternative approach would be the dropbox app, or mailing yourself a link to an apk stored on the web. But these instructions will be for using ASTRO. 1) Create any app in Titanium Studio. 2) Build and install the app on a Honeycomb-or-later device. (The problem does not occur in Froyo or Gingerbread.) 3) Uninstall the app from the device using (optional). 4) Move the apk that you just built on to the /sdcard of the device. (This and the next few are steps that can be changed by you if you don't wish to use ASTRO to make the Installer app install the APK. The point is, you want the Installer to install the app.) For example: adb push build/android/bin/app.apk /sdcard. 5) Using a file manager such as ASTRO to view your SDCard and select the .apk file you copied there. "Open" it (i.e., tap it in ASTRO) and select the option to Install. 6) If you did not do step (3), you'll be asked if you're sure you want to replace the existing app. You are sure. 7) Go through the Installer steps to install the app. At the end, do *not* select "Done", but rather "Open" so as to launch the app immediately. 8) When the app launches you will see our "app needs to be restarted" (or whatever it says) warning and button. Tap the button to allow the restart to occur. 9) After the app relaunches, just back out of it. 10) Use the history/recent apps list to go back to the app (not the main apps screen, but the history/recent apps list). In the fail case scenario, you will _again_ be told that the app needs to be restarted. When testing the fix, this should *not* happen.

    Test new option

    For this test case, use KitchenSink since it has multiple activities. _This test should be done at least twice: once on a Froyo or Gingerbread device, and once on a Honeycomb or greater device_. 1) Open the tiapp.xml for KitchenSink. 2) Add this property: 
       <property name="ti.android.bug2373.finishfalseroot" type="bool">true</property>
    and save the file. 3) Use the steps from the above fail case instructions to build KS and put its APK file on the /sdcard, open it with ASTRO and start the Installer installing it. (Or use your preferred method of getting the Installer to start installing the KitchenSink .apk file. 4) When the Installer is finished, don't click "Done", but rather "Open" so you run the KitchenSink app right away. 5) When the app loads, you should *not* see the warning about needing to restart it. 6) Go to the "Base UI" tab. 7) Click "Views" to load the list of Views tests. 8) With the Views test list showing, put the KS app in the background (either by tapping the Home button/icon or switching to another app using the history/recent apps list.) *Don't* back out of the app -- just leave it with the Views test list showing. 9) Go back to KS by selecting it from the history / recent apps list. There should be no warning whatsoever, and you should be put right back to the Views test list, just as you left it. 10) Again put KS into the background, leaving it sitting at the Views test list, just like step (8). 11) This time, go back to KS using the main apps screen. 12) Again, you should see no warnings whatsoever, and you should be put right back at the Views test list. 13) In general, you should be able to use KS, put it in the background, bring it forward again, without any warnings or anomalies.
  9. Bill Dawson 2012-07-27

    Pull request ready: https://github.com/appcelerator/titanium_mobile/pull/2651
  10. Frank Apap 2012-07-28

    First, thanks for fixing this! Second, how do we know what CI build has the change?
  11. Arthur Evans 2012-07-31

    Frank: When this fix is merged, this bug will be moved to the Resolved state. At that point, the next CI build should contain the fix.
  12. Josh Roesslein 2012-08-01

    Having issues running KS with the "ti.android.bug2373.finishfalseroot" set to true. Attached the log which includes the stack trace from the crash if you try backing out. Device: Nexus 7 (Android 4.1)
  13. Josh Roesslein 2012-08-01

    This crash might actually be the same bug as TIMOB-10227.
  14. Shawn Lipscomb 2012-08-03

    Testing should also include updating the app from the Play Store app. Right now, with SDK 2.1.0.GA and these TiApp.xml settings: true Initializing... when my app is updated from the Play Store app and then the user hits "Open", my app's splash screen appears, the "Initializing..." toast message appears, then the screen goes right back to the Play Store app. My app never starts. Note that doing a virgin install of my app via the Play Store app, then hitting "Open" starts my app correctly.
  15. Bill Dawson 2012-08-07

    PR for 2_1_X ready: https://github.com/appcelerator/titanium_mobile/pull/2689
  16. Vinayakam 2012-08-12

    Any update on this. I am still facing this issue on Samsung Galaxy 10.1 with SDK 2.1.0 GA. true 500 0 true Initializing Restart Required Continue The finishfalseroot doesn't seem to have any effect.
  17. Shannon Hicks 2012-08-12

    Vinayakam: If you look at the ticket status, it's fixed in 2.1.2 and 2.2. You can try the CI build if you need the fix sooner rather than later.
  18. Vinayakam 2012-08-13

    I'm sorry for not specifying the problem correctly. Even with SDK 2.1.0 earlier, after using special properties I wasn't seeing the popup but a black screen shows up after the initial splash screen. Even with the latest Mobile SDK build, I am seeing the same behaviour http://builds.appcelerator.com.s3.amazonaws.com/mobile/2_1_X/mobilesdk-2.1.2.v20120813164609-win32.zip
  19. Chris Carranza 2012-08-14

    I implemented this fix on the latest version of my app and it did the trick. So glad that headache is over. I used the 2.1.2 ci build along with the true
  20. Vinayakam 2012-08-14

    Hello Chris I am not seeing a restart needed popup anymore but I still see a black screen after the splash screen. Are you seeing anything of this sort?
  21. Chris Carranza 2012-08-14

    Vinayakam, I haven't noticed any black screen from my app. Do you have any of the previous properties still in your tiapp.xml? Like these: true 500 0 true Initializing Restart Required Continue All i have is the new property true along with the new ci build. Maybe one of the previous properties is interfering.
  22. Eric Merriman 2012-08-25

    Verified setting the property works with SDK 2.1.2.v20120824144611 and: mac: Lion: Android 2.2.x, 4.0.x, 4.1.x Mountain Lion 2.3.x, 3.1, 3.2, 4.0.x, 4.1.x Linux: Android 2.2.x, 3.2.x, 4.0.x, 4.1.x Win 7: Andorid 2.2.x, 2.3.x, 33.1, 4.0.x, 4.1.x
  23. Shawn Lipscomb 2012-08-28

    In [this Q&A](http://developer.appcelerator.com/question/121201/titanium-studio-android---an-application-restart-is-required-and-also-mcafee-blocking-the-studio-from-building-into-emulator#answer-246128), the user reports that after restarting, in-app billing can't connect. In-app billing only works when launching from the icon, not from the installation screen. Using 2.1.1.GA.
  24. Neeraj Gupta 2012-08-28

    @Shawn - Thanks for the update. Would you mind opening another ticket for this issue as it is related to in-app billing?
  25. Shawn Lipscomb 2012-08-29

    Neeraj, I will suggest to the reporting user that he file a JIRA ticket. I'm not having this problem (although I'm also not doing in-app purchasing in an active app right now).
  26. Neeraj Gupta 2012-08-29

    @Shawn - Thanks.
  27. Ingo Muschenetz 2012-10-10

    Reopening to edit labels. Bill this needs a backport to 2_0_X. Can you give an ETA on when that could be done?
  28. Bill Dawson 2012-10-10

    2_0_X PR ready https://github.com/appcelerator/titanium_mobile/pull/3149
  29. Ingo Muschenetz 2012-10-14

    PR merged. Resolving issue.
  30. Lokesh Choudhary 2012-12-06

    Verified using the two scenarios mentioned by Bill Dawson & the app behaves as it should in the fixed case. Titanium studio : 3.0.0.201211301903 SDK Version : 3.0.0.v20121204154658 CLI version : 3.0.19 OS : OSX 10.8.2 Android 4.0.4 galaxy s3
  31. Jean-Sébastien GALLOO 2013-02-18

    Got the same problem using Ti 3.0.0GA... fixed by using the previous trick in TiApp.xml true 500 0 true Initializing Restart Required Continue
  32. Jean-Sébastien GALLOO 2013-02-18

    and this before, i forgot: true
  33. Doug Benson 2013-05-14

    Lanica is seeing very similar behavior on Android with 3.1.0GA: Problem: When installing the .APK over ADB there is no problem and there are no alerts given to the user. When installing the .APK by copying it to a folder on the device (as described above) then installing it from within that folder, user gets "Restart Required" message OR an immediate hang on launch. Steps: Install APK by copying it to an "sdcard folder". Open the .apk from within that folder on the device. a) the user is told to allow apps from unknown sources (as expected) b) the user is asked to approve the app access to various device services (as expected). c) the app installs. User is given choice of Done and Open d) *If choosing "Open," the app returns an alert "Restart Required"* during the app splash screen. NOTE: Intermittently, some devices fail to display "Restart Required" and instead *hang during the initial splash screen.* For devices that fail to launch: if the user subsequently uninstalls that .apk and then reinstalls it over ADB, the app will launch normally. Note that logcat references *issue 2373* (as described in previous comments): E/TiLaunchActivity( 3163): (main) [10,947] Android issue 2373 detected (missing intent CATEGORY_LAUNCHER or FLAG_ACTIVITY_RESET_TASK_IF_NEEDED),
  34. Matt Langston 2013-05-14

    Lanica is seeing very similar behavior on Android with 3.1.0GA: Problem: When installing the .APK over ADB there is no problem and there are no alerts given to the user. When installing the .APK by copying it to a folder on the device (as described above) then installing it from within that folder, user gets "Restart Required" message OR an immediate hang on launch. Steps: Install APK by copying it to an "sdcard folder". Open the .apk from within that folder on the device. a) the user is told to allow apps from unknown sources (as expected) b) the user is asked to approve the app access to various device services (as expected). c) the app installs. User is given choice of Done and Open d) If choosing "Open," the app returns an alert "Restart Required" during the app splash screen. NOTE: Intermittently, some devices fail to display "Restart Required" and instead hang during the initial splash screen. For devices that fail to launch: if the user subsequently uninstalls that .apk and then reinstalls it over ADB, the app will launch normally. Note that logcat references issue 2373 (as described in previous comments): E/TiLaunchActivity( 3163): (main) [10,947] Android issue 2373 detected (missing intent CATEGORY_LAUNCHER or FLAG_ACTIVITY_RESET_TASK_IF_NEEDED),
  35. Allen Yeung 2013-05-23

    Closing this issue again. When you load the app to the sd card and install it from there, it is expected behavior that the dialog comes up. It is essentially mimicking an install from the play store which is what the restart dialog is supposed to address. If the user doesn't want to use this, we have a tiapp.xml flag to disable it: 'ti.android.bug2373.disableDetection'. If the restart is not working correctly, that is a different issue and a separate ticket should be filed for it. The purpose of this ticket is to address when we show the restart dialog. [~ dsbenson] and [~ mlangston], could you please file a separate ticket with relevant logs if you are still running into the issue? You can also link it to this ticket. Thanks.
  36. Joshua Quick 2019-01-11

    This issue has been resolved in Titanium 8.0.0. Please see: [TIMOB-26075]

JSON Source