Skip to main content
Known Participant
October 1, 2013
Question

Android 4.2.2 update breaks AIR apps

  • October 1, 2013
  • 1 reply
  • 1921 views

Hi there,

I just got the update to Android 4.2.2 on my Samsung Tab 2 10.1 and it seems to break my captive AIR app. On the very first launch of the app, I see the initial screen (loading screen) of my app and then the entire app goes black and remains black. If at this point I switch to the home screen and then come back to my app I am able to see and use my app like normal.

This seems to be an issue after the update to 4.2.2. I have another Samsung Tab 1 10.1 with Android 4.0.4 and it works fine. I have tested with AIR SDK 3.8 as well as AIR SDK 3.9.0.960 and the issue exists in both versions.

When this issue occurs I see the following error messages in LogCat:

10-01 19:08:32.955: E/BufferQueue(464): [SurfaceView] queueBuffer: SurfaceTexture has been abandoned!

10-01 19:08:32.955: E/SurfaceTextureClient(15043): queueBuffer: error queuing buffer to SurfaceTexture, -19

10-01 19:08:32.955: I/Choreographer(15043): Skipped 51 frames!  The application may be doing too much work on its main thread.

10-01 19:08:32.971: V/WindowManager(491): Window{41cddbf0 u0 Keyguard}mOrientationRequetedFromKeyguard=false

10-01 19:08:33.088: E/BufferQueue(464): [SurfaceView] queueBuffer: SurfaceTexture has been abandoned!

10-01 19:08:33.088: E/SurfaceTextureClient(15043): queueBuffer: error queuing buffer to SurfaceTexture, -19

Any ideas?

Thanks,

- Abey

This topic has been closed for replies.

1 reply

abeymgAuthor
Known Participant
October 2, 2013

Update: This seems related to the <containsVideo></containsVideo> tag in the app descriptor. The issue seems to occur when this is set to true. Removing this resolves the issue.

But I see now that removing this causes layering bugs that render the app unusable. So removing this is not an acceptable solution.

- Abey

Participating Frequently
May 21, 2014

I know this is an old post, but just in case it helps someone looking for a work-around for this: we had the same problem and got around it by setting the stage.quality when the first movieclip is displayed, so we added this to the framescript:

  theMovieClip.addFrameScript(1, function():void {stage.quality = StageQuality.LOW;});


when theMovieClip hits the second frame (addFrameScript is zero relative) it sets the stage.quality, which forces the graphics to refresh again.


hth,

Hudson