Behavior seems consistent in Android 1.5 to 2.1

Short version is this, it appears that when my (android search facility) search activity is fired from the android QSR due to either a suggestion or search, UNLESS my search activity in turn fires off a VISIBLE activity that is not the parent of the search, the search parents life cycle changes. It will NOT fire onDestroy until I launch a visible activity from it. If I do, onDestroy will fire fine. I need a way to get around this behavior...

The long version:

We have implemented a SearchSuggestion provider and a Search activity in our application. The one thing about it that is very odd is that if the SearchManager passes control to our custom Search activity, AND that activity does not create a visible Activity the Activity which parented the search does not destroy (onDestroy doesn't run) and it will not until we call a visible Activity from the parent activity.

As long as our Search Activity fires off another Activity that gets focus the parent activity will fire onDestroy when I back out of it. The trick is that Activity must have a visual component. I tried to fake it out with a 'pass through' Activity so that my Search Activity could fire off another Intent and bail out but that didn't work either.

I have tried setting our SearchActivity to launch singleTop and I also tried setting its noHistory attribute to true, tried setResult(RESULT_OK) in SearchACtivity prior to finish, bunch of other things, nothing is working.

This is the chunk of code in our Search Activity onCreate. Couple of notes about it:

• If Intent is Action_Search (user typed in their own search and didn't pick a suggestion), we display a list of results as our Search Activity is a ListActivity. In this case when the item is picked, the Search Activity closes and our parent Activity does fire onDestroy() when we back out.

• If Intent is Action_View (user picked a suggestion) when type is "action" we fire off an Intent that creates a new visible Activity. In this case same thing, when we leave that new activity and return to the parent activity, the back key does cause the parent activity to fire onDestroy when leaving.

• If Intent is Action_View (user picked a suggestion) when type is "pitem" is where the problem lies. It works fine (the method call focuses an item on the parent activity), but when the back button is hit on the parent activity onDestroy is NOT called. IF after this executes I pick an option in the parent activity that fires off another activity and return to the parent then back out it will fire onDestroy() in the parent activity.

Note that the "action" intent ends up running the exact same method call as "pitem", it just bring up a new visual Activity first. Also I can take out the method call from "pitem" and just finish() and the behavior is the same, the parent activity doesn't fire onDestroy() when backed out of.

if (Intent.ACTION_SEARCH.equals(queryAction)) {
    this.setContentView(_layoutId);
    String searchKeywords = queryIntent.getStringExtra(SearchManager.QUERY);
    init(searchKeywords);
} else if(Intent.ACTION_VIEW.equals(queryAction)){
    Bundle bundle = queryIntent.getExtras();
    String key = queryIntent.getDataString();
    String userQuery = bundle.getString(SearchManager.USER_QUERY);
    String[] keyValues = key.split("-");
    if(keyValues.length == 2) {
        String type = keyValues[0];
        String value = keyValues[1];

        if(type.equals("action")) {
            Intent intent = new Intent(this, EventInfoActivity.class);
            Long longKey = Long.parseLong(value);
            intent.putExtra("vo_id", longKey);
            startActivity(intent);
            finish();
        } else
        if(type.equals("pitem")) {
          Integer id = Integer.parseInt(value);
          _application._servicesManager._mapHandlerSelector.selectInfoItem(id);
          finish();
        }
    }
}

It just seems like something is being held onto and I can't figure out what it is, in all cases the Search Activity fires onDestroy() when finish() is called so it is definitely going away.

If anyone has any suggestions I'd be most appreciative.

Thanks,

Sean Overby