Why doesn't AIR Android app resume after pressing off or home button?

VascoF,

On re-reading your original post, this behavior looks symptomatic of an app whose GPU memory usage is very close to maximal.  You need headroom in GPU memory, or it's very easy to go overboard, especially as the device overlays the standby ( lock ) screen, or something like that ( like the manufacturer's own Android skin -- ex: Samsung's Touchwiz UI ! ).

Best solution in this situation is simply to reduce the sizes of the textures you are storing in GPU memory, by:

• If you are the direct render mode + Stage3D, by putting a cap on the maximum texture res possible, for example, and/or knocking down the largest ones.

• if you are using the GPU render mode, by setting cacheAsBitmapMatrix to half-res ( new Matrix( 0.5, 0, 0, 0.5 ) ) or less.

• OR: by simply authoring all your source bitmapDatas at a lower res.

Notes:

• When resuming an app that uses the GPU, it is possible ( frequent ) to get a momentary black screen ( up to several seconds ), if you lost the 3D context and/or if the textures got flushed from GPU memory.  But a full automatic restart, like you are describing, is most likely due to being borderline on texture memory in the first place, and going over the top -- for a particular device!

• One detail:  careful with Texture.dispose() if you rely on it, as it seems to require a couple render calls to truly kick in.  If you flood the texture memory with a new set of textures before the dispose on the old ones has taken effect, you could run out of texture memory, as mentioned here:          http://forums.adobe.com/message/5991506#5991506

FYI, some of the points above recoup parts of the discussion in an earlier thread:

http://forums.adobe.com/message/5846948#5846948

Re. Samsung QA:

They are both good in some respects and awful in others.

The bad:

• They will nit-pick trivial stuff, which other stores won't.
• They will occasionally fail an app based on arbitrary 'defects' which anywhere else would be considered features or 'as designed'.
• Their intake website is terrible, and so are the financial reports.
• You have to wait a long time for each iteration.
• Financial returns are very low compared to other app stores.

The good:

• Because they are very thorough ( even if arbitrarily, so ), they can occasionally find true defects, on devices you most likely never had access to.
• The videos showing the defects are great.  They definitely put a lot of effort in their feedback.

I just managed to get an app into the Samsung store. Took about six weeks, and three rejections. I have another app on its fourth rejection, and back into their device testing (which seems to take about 7 days each time). Samsung are very tough, be prepared to have to submit the app several times!

Here are the reasons for rejection that I had to fix, some of which is the case for you too:

Problem: Pressing the back button would take you to the home screen, and returning to the app would leave it in a confused state.

Fix: I changed things so that the back button would take you from the game you were in back to the main menu of our app, and pressing the back button again would be ignored. That worked around the issue. Resubmitted, but was rejected after a few days.

Problem: Back button does not exit to device home screen.

Fix: This meant I had to really fix the main issue! Had to tinker with the activate and deactivate routines. Resubmitted, but was rejected after a few days.

Problem: While our app was running, and playing sound, pressing the power button would silence the app, as it should. Pressing the power button, but not unlocking the screen, would cause our app to start playing its sound again.

Fix: I looked around the Internet, and found plenty of other Samsung sufferers! The solution that seemed to work the best was to throw up a “pause” screen in your app, that on returning the user has to touch in order to resume. So I did that too. Resubmitted, rejected a few days later…

Problem: Before playing our app the Samsung QA person set an alarm for 1 minute from now, then played our app. When the alarm kicked in they cancelled the dialog, leaving themselves in our app. The screen was black, but sounds could still be heard.

Fix: Again, Mr Google helped out here. It’s a low memory issue, where Android OS clears out the GPU textures if another app needs the space. The alarm dialog had cleared the graphics in our game. The solution is a work around, where on activate you set the stage quality. For our game we’re running in “low”, so on deactivate I set the stage quality to “medium”, and on activate I set it to “low”. That is enough to force the textures to be recreated. Resubmitted.

A week later is was “ready for sale”. A day more later it appeared in the Samsung store:

http://apps.samsung.com/mars/topApps/topAppsDetail.as?productId=000000770501

The above list is somewhat of a combination of errors in the two apps. In addition to all the technical testing that Samsung do, they also do testing of the playability of the app, and we’ve had a couple of rejections based on game play issues. Really, it’s like having your own QA department!

The second app, that is on its fourth submit, had a game play issue, which I fixed. Hopefully it will get through this time.