0

I made an exceedingly simple app consisting of a launch activity (.TestActivity) with nothing more than a button on it, and a 2nd activity (.second) with nothing more than a piece of text on it.

Then I create an .apk file from it and sideload it to my phone, I open the app, click the button and go to the 2nd activity, press Home to make the app leave the screen, and then press the icon of the app to open it again, it resumes on my FIRST activity and not the 2nd one that I would expect.

After I force close the app it works properly, though! Where is the problem here? It's not my phone because I've seen this on several other devices that I've tested with. It's not necessarily Eclipse because it works as expected on Eclipse (and the emulator), it's possibly the manner in which I package the .apk file (but even then it's a pretty standard "export" that I'm doing from Eclipse so I'm not sure what that would be). Any other ideas?

Here's the manifest:

  <application
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name" >
    <activity
        android:label="@string/app_name"
        android:name=".TestActivity" >
        <intent-filter >
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
      <activity
        android:label="@string/app_name"
        android:name=".second" >
         </activity>
</application>

Why would force closing the app make it work how I want it to work the 2nd time, though?

  • 3
    Probably an issue in your android manifest, post it and the code. – bbedward Mar 19 '12 at 19:30
  • As I said, this works how I would expect it to work (2nd activity is "resumed") when I run this on my phone from Eclipse. It only seems to not work initially after being installed as an .apk and prior to a force stop of the app. – milkboneUnderwear Mar 19 '12 at 19:52
  • It's possible that someone may skim my original question above, create an app this simple in about the 57 seconds it takes to do so, and test it from their IDE (they won't see a problem and they'll think I'm crazy). But this problem only seems to be applicable to when the app is packaged and run as an .apk. This has obvious ramifications for published apps on the Marketplace. – milkboneUnderwear Mar 19 '12 at 20:00

2 Answers2

1

Here's the deal. In your Android Manifest you identify which Activity you want to load when launching your app. If, for some reason, your app is not resident in the task stack Android will launch that Activity. If your app is in the task stack Android may choose to bring it to the front and you could be looking at whatever Activity was showing when you left the app. The thing is you cannot count on this. If you want the first Activity to show only te very first time the user launches your app you need to set a flag and then on subsequent launches you can automatically launch the second Activity based on that flag.

CaseyB
  • 24,780
  • 14
  • 77
  • 112
  • I just don't understand why it works as I feel it should (2nd activity is resumed) when I run this in an emulator or on my phone from Eclipse, it does NOT work as I feel it should (1st activity is resumed) when I run it on my phone as a sideloaded .apk, and then it does work as it should (2nd activity is resumed) indefinitely after I do a force stop of the app. – milkboneUnderwear Mar 19 '12 at 19:57
  • It's going to very from device to device. That's what I'm trying to tell you. Just because it seems to "work" on your device doesn't mean that it will always work, every time on all devices. You need to develop your app to match what the docs say and that is that your Activity, while in the background, can be killed at any time and that you are only guaranteed to launch the Activity that you can defined in your Manifest as the launch Activity. – CaseyB Mar 19 '12 at 20:11
  • I don't think you understand my problem but thank you for taking the time to try and help me. I'm going to post something I just found that is the closest thing I've found to a solution. – milkboneUnderwear Mar 19 '12 at 20:26
  • It's not letting me post my own answer yet... But this http://stackoverflow.com/questions/3042420/home-key-press-behaviour/4782423#4782423 and this http://code.google.com/p/android/issues/detail?id=26658 are the real crux of my issue. This looks pretty obviously like a bug to me and the workaround looks like it's going to get me by. – milkboneUnderwear Mar 19 '12 at 20:32
  • This is what I was saying with the "set a flag" bit. – CaseyB Mar 19 '12 at 21:04
  • Setting a flag won't help if you side load your app as an .apk and click "Open" instead of "Done". Until you force close (if you click "Open") your app will not work as it should. I understand what you're saying about there being no guarantee that an activity will hang around indefinitely in memory, but I think you're missing the forest for the trees in this case. This turned out to be a very specific bug that would have gone unnoticed if I did something as simple as clicking "Done" instead of "Open" after I sideloaded the .apk. – milkboneUnderwear Mar 19 '12 at 21:35
1

I just found the following links:

http://code.google.com/p/android/issues/detail?id=26658

and a decent workaround here: Home key press behaviour

I understand what CaseyB is getting at, but I can reproduce this every single time. If my app has a memory leak or ends up getting killed due to inactivity or the need for Android to reclaim some of its resources, that's one thing. But this seems pretty obviously like a bug to me and I'm just going to have to live with the workaround for now.

Community
  • 1
  • 1