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

[VascoF]

I am trying to submit an app to the Samsung Apps Store, but they rejected it because:

a) if the app is running, and the device's on/off button is pressed, and then pressed again (and screen unlocked if necessary), the app doesn't resume; it just returns to the home screen.

b) if the app is running, and the device's home button is pressed, and then the app is launched again, the app doesn't resume from where is was left, but restarts.

Is there any way to avoid these issues? I have no ideia what could be causing this, or if it's even possible to fix. Any help is very much appreciated!

[Colin Holgate]

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.

[VascoF]

Wow, I did feel that they were being picky, but didn't realise it was that bad. Glad you finally made it.

Any ideas on what I could try to fix my issues (game not resuming)?

[Colin Holgate · Accepted solution]

Just something you doing on deactivate, or not doing on activate. What do you do at those times?

[VascoF]

Thank you so much. I'm a complete beginner at AIR apps and had no idea where to look, but indeed the problem was that I was calling "NativeApplication.nativeApplication.exit();" on deactivate, and I changed it to "NativeApplication.nativeApplication.systemIdleMode = SystemIdleMode.NORMAL;". Now it resumes after losing focus. Fingers crossed that it will pass validation now

[Justin_as3_rules]

My app passed on the first attempt.....but we had a lot of issues with them accepting banking account info.....had to submit info at least 4 times......anyhow, in 2 months have not had a single download, and this was after 100 indie had invited me to join......not sure if they gett a lot of activity compared to ios.....somewhat frustrated with that store.

[Colin Holgate]

Our second app is still “under device testing”, but the first one managed two sales yesterday! Mind you, that may have been our client doing tests.

[Justin_as3_rules]

Congrats Colin.....thanks by the way for all the help and tips you give us on the forum....there must have been at least 30 or 40 Colin tips I have used during this past 2 year adventure of mine.

I tried putting my app on sale for 0.99 and that did not help it move on that store.  I was quite hopeful with the invitation from 100 indie that it would help the app out...but nothing.

I found however, that developing an app on Android is by far easier to do for a beginner like me than to try starting with iOS. 

The beautiful thing about Flash and Air is that it took less than a month (working only an hour a day) to complete a port for iOS.  If I had followed your steps from the beginning about developing for multiple screen dimensions/ratios, it would have taken maybe a few hours.

Well done Adobe.  Please keep the updates flowing and thanks for all your hard work (especially the solution for icons, which worked perfectly for me using Flash PRO 6).

Justin

[AsterLUXman]

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.

[VascoF]

Well, my app was rejected again, now because sometimes when the game is resumed all that shows is a black screen, and the game doesn't respond. This is taking up too much time for what it's worth, so at least for now I give up

[Colin Holgate]

I read today that this was a problem fixed in December, though I think I’ve since the problem since then.

If you’re using a version other than 4.0.0.1619, try using that one. If you’re already using that one, then on deactivate set the stage quality to something other than what you want, and on activate set it to the quality you do want.

That’s what it took for me to get through the Samsung rejection about a black screen.

What’s happening is that the device is clearing all the GPU textures, and AIR doesn’t know that. Setting the stage quality forces AIR to recreate the textures.

[VascoF]

Seems simple enough, I'll give it a try then Thanks.

[AsterLUXman]

VascoF, don't despair, dealing with the Samsung app store can be maddening -- more so than any other ( incl. the fruity one )!

Re. black screen issue:

In case your are using the direct render mode + stage3D, minimizing the app can ( will ) definitely lead to a loss of context, eventually.

Getting a new context can take a few seconds on some devices ( up to 15 seconds on the Nook Color with the BASELINE profile !), and then you still have to go through with the rest of the initialization, including re-generating and re-uploading all the textures.  That last part tends to be very fast, though, in comparison to the requesting part -- in my last app anyway.

One thing that can speed up the delay in obtainning a new context from the time the Stage3D.requestContext3D() is called, is to use the BASELINE_CONSTRAINED profile, if your shaders are not too complicated ( compiling the swf will let you know if you can ).  In my Nook Color app, requesting delay went down to 7 secs ( from 15 ) with the constrained profile!

If you are using the GPU render mode, I suppose something similar must be happening.  If the delay, in that case, is due solely to the re-uploading of textures to the GPU, then maybe uploading a smaller-res, temporary, set might help.  If you are using CAB and CABM, maybe trying cacheAsBitmapMatrix = new Matrix( 0.25, 0, 0, 0.25 ), at first, and then switching matrices back gradually to the intended final resolution might help minimize black screen time, maybe.  Just an idea.

As a last resort:  some devices are pretty old and underpowered ( Nook Color, for example, is one of the worst ), which makes these kinds of issues even worse.  Since the Samsung reviews indicate wich device / class of device it is failing on, you could also just re-submit and exclude that class of devices, via their intake website.  End of story.

[AsterLUXman]

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