Obsolete
Status Update
Comments
as...@gmail.com <as...@gmail.com> #2
This issue needs fixing. Our Apps are having this issue and there does not seem to be a
ready solution available. Google please fix this issue!
ready solution available. Google please fix this issue!
vi...@gmail.com <vi...@gmail.com> #3
Faced this on 2.0.1 and 2.1.
Is there a workaround for this?
Is there a workaround for this?
to...@gmail.com <to...@gmail.com> #4
Face same issue at 2.1.
Is there any solution or walkaround to avoid it?
Is there any solution or walkaround to avoid it?
as...@gmail.com <as...@gmail.com> #5
I wanted to ask a Google engineer if using a status persistent flag and then use some way of identifying the instance would work and whether it would be fine to go this way ?
da...@gmail.com <da...@gmail.com> #6
Any news on this? It's a serious problem for us. Is there any kind of workaround available?
dt...@gmail.com <dt...@gmail.com> #7
I haven't had a chance to write up my workaround. The problem is that the Intent that's launch the app from the home screen is different than all of the other launch points. Looking through the source, it looks like this problem might have accidentally been fixed in mid July, but it's not in any shipping code as far as I can tell.
Look in the onCreate ofhttp://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/org/appcelerator/titanium/TiRootActivity.java you'll see how I detect the problem. Then in the onRestart I look for a configuration setting in our system as to the behavior. In dev mode, we don't force restart the app. You can also look for the restartApp() method on how I'm affecting a restart.
HTH.
Look in the onCreate of
HTH.
da...@gmail.com <da...@gmail.com> #8
That's spectacularly evil --- but it *works*. Thank-you very much!
I'm a little worried that if the device is busy the 500ms delay might not be long enough. OTOH with any longer delay the user experience is very poor, so I think we'll just have to live with it.
I'm a little worried that if the device is busy the 500ms delay might not be long enough. OTOH with any longer delay the user experience is very poor, so I think we'll just have to live with it.
cw...@gmail.com <cw...@gmail.com> #10
This issue seems to still exist. The above workaround doesn't seem to work for me. The app refuses to launch with it.
cw...@gmail.com <cw...@gmail.com> #11
Sorry, I retract that. The problem does still exist but the workaround works. It was user error on my behalf. I had specified the StartupActivity twice in my AndroidManifest.xml.
Thank you for the workaround.
Thank you for the workaround.
mi...@gmail.com <mi...@gmail.com> #12
[Comment deleted]
mi...@gmail.com <mi...@gmail.com> #13
[Comment deleted]
mi...@gmail.com <mi...@gmail.com> #14
Thanks for the workaround, it'll have to do for now.
Does anybody know if this workaround is pretty much the standard for Android apps? Are most apps out there creating a dummy startup activity to work around the issue?
I've installed quite a few apps and about 50% of them show this bug (many games restart a new game if hitting the Home button and then relaunch the app (then hit back button and there's your old game in progress :) )).
But the other 50% seem to handle the problem, I'm curious if they're using the workaround shown here.
Frustrating that this discussion has been going on since 2009.
Does anybody know if this workaround is pretty much the standard for Android apps? Are most apps out there creating a dummy startup activity to work around the issue?
I've installed quite a few apps and about 50% of them show this bug (many games restart a new game if hitting the Home button and then relaunch the app (then hit back button and there's your old game in progress :) )).
But the other 50% seem to handle the problem, I'm curious if they're using the workaround shown here.
Frustrating that this discussion has been going on since 2009.
sh...@gmail.com <sh...@gmail.com> #15
At my previous company we shipped 2 games with the workaround and it worked great. Yes, it's frustrating that you have to do it, but it was absolutely necessary for us because we'd start to run out of bitmap memory otherwise.
mi...@gmail.com <mi...@gmail.com> #16
[Comment deleted]
[Deleted User] <[Deleted User]> #17
[Comment deleted]
ka...@gmail.com <ka...@gmail.com> #18
MarketPlace launch is solved by google. but browser app launcher still there
This problem still exists on 4.2.1
This problem still exists on 4.2.1
ad...@gmail.com <ad...@gmail.com> #19
This issue also occurs if the app is opened using the 'Open' button after installing using the Package Installer.
This problem still exists on 4.4
This problem still exists on 4.4
er...@gmail.com <er...@gmail.com> #21
[Comment deleted]
er...@gmail.com <er...@gmail.com> #22
I was searching how to fix this issue and I found that the activity that must not be launched has the flags (intent.getFlags() ) equals 274726912. This is working for me ...
if (intent != null && intent.getFlags() == 274726912) {
finish();
}
if (intent != null && intent.getFlags() == 274726912) {
finish();
}
gr...@gmail.com <gr...@gmail.com> #23
Same thing happens when launching the app from the lock screen.
en...@google.com <en...@google.com>
dw...@sharpmind.de <dw...@sharpmind.de> #24
So why was this marked obsolete? As far as I know it is still broken. Has this been fixed? If so, where/when?
Description
Noticed this behavior with the package installer through marketplace/ browser. Pick any app
from marketplace, for my test I'll use "US Yellow Pages Search".
1) Download the app from marketplace.
2) When it's finished downloading, open the notifications panel, and choose to run it.
3) App starts up.
4) Pause app by hitting the home screen.
5) Resume the app by hitting the Yellow Pages app icon from your app tray.
6) Hit the back button.
7) Now you can see that there was another instance of this app running underneath - the back
button should return you to the homescreen here, instead it brings you back to the other
instance of the Yellow Pages app you started from the marketplace launcher.
It's easier to see this behavior, when, on step #4, before pausing the app by hitting the home
screen, navigate to a new activity in the Yellow Pages app (do a search for some business, then
view its details, it will start a new activity). Then it's easier to see that when you resume the app,
instead of returning to the business details activity, you're shown a new instance of the app,
starting from its root activity.
This may be the same bug affecting developers using eclipse to launch their apps:
id=2373&q=defunct&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
you can see that when the marketplace / browser launches your app, it uses the same intent flag
as eclipse (which also exhibits this behavior):
Intent { flags=0x10000000
(FLAG_ACTIVITY_NEW_TASK?)
so it seems that if there's an instance of your app running which was launched with the above
flag, the system won't simply resume that running app if the user tries hitting that app icon from
the app tray.
This is confusing for the user, it would probably make more sense if the system just resumed
the already-running app for them.
--------------------
This behavior exists on 1.5 through 2.0, emulators and G1 / Droid / Hero (haven't tried on other
devices).
--------------------
**By "browser install", I mean you can host an apk file on a server, then download the apk
through the device browser. When downloaded, you're presented with the options "Open" or
"Done". If you choose "Open", the installer will use the flag mentioned above and this behavior
starts.