• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
Locked
1

Android L with Beta - AIR 15.0.0.289

New Here ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

Hey,

We are running into a problem with the Android L developer preview and beta AIR 15.0.0.289. It's an app for Android and iOS with multiple native extension for ads and offerwall.

Problem

After closing the native overlay displayed by an extension, our application rendering is bugged and displays artifacts. The problem occurs on Android L developer preview (razor-lpv79-preview-d0ddf8ce.tgz Nexus 7 Wifi "razor") with GPU render mode on.

Is this a known issue? If so, how can we fix this and will all Android L users be affected?


Flow

Android L - Beta AIR 15.0.0.289.jpg


Logcat

W/UnimplementedWebViewApi( 4749): Unimplemented WebView method onKeyDown called from: android.webkit.WebView.onKeyDown WebView.java:2282)

I/am_finish_activity(  623): [0,900058684,22,air.com.flaregames.wordon/com.tapjoy.TJCOffersWebView,app-request]

I/am_pause_activity(  623): [0,900058684,air.com.flaregames.wordon/com.tapjoy.TJCOffersWebView]

I/am_on_paused_called( 4749): [0,com.tapjoy.TJCOffersWebView]

I/am_resume_activity(  623): [0,379306882,22,air.com.flaregames.wordon/.AppEntry]

D/[CoreMobileEx]( 4749): Restart.

D/[PushNotifyEx]( 4749): Restart.-

D/[GVExtension]( 4749): Resume->activate publish

D/[CoreMobileEx]( 4749): Resume.

D/[PushNotifyEx]( 4749): Resume.

D/[CoreMobileEx]( 4749): Canceled 1943748

D/[CoreMobileEx]( 4749): Canceled 1943749

I/am_create_service(  623): [0,413666469,.AdvertisingIdService,10007,2289]

I/am_on_resume_called( 4749): [0,air.com.flaregames.wordon.AppEntry]

W/art     ( 4749): Thread[25,tid=5915,Native,Thread*=0xb9d6f7f0,peer=0x785d40e0,"Thread-838"] attached without supplying a name

D/audio_hw_primary(  193): select_devices: out_snd_device(2: speaker) in_snd_device(0: )

D/ACDB-LOADER(  193): ACDB -> send_afe_cal

I/art     ( 2289): Heap transition to ProcessStateJankPerceptible took 84.747314ms saved at least -314KB

I/am_destroy_service(  623): [0,413666469,2289]

E/ActivityThread( 4749): Failed to find provider info for com.facebook.katana.provider.AttributionIdProvider

I/am_destroy_activity(  623): [0,900058684,22,air.com.flaregames.wordon/com.tapjoy.TJCOffersWebView,finish-imm]

E/chromium( 4749): [ERROR:aw_contents.cc(814)] Unable to free GL resources. Has the Window leaked?

W/Adreno-ES20( 4749): <core_glBindVertexArrayOES:288>: GL_INVALID_OPERATION

I/sf_frame_dur(  190): [air.com.flaregames.wordon/com.tapjoy.TJCOffersWebView,100,3,2,0,1,0,1]

W/Adreno-EGL( 4749): <qeglDrvAPI_eglCreateWindowSurface:1027>: EGL_BAD_ATTRIBUTE

W/art     ( 4749): Thread[25,tid=5943,Native,Thread*=0xb9ea4940,peer=0x785d4140,"Thread-839"] attached without supplying a name

W/art     ( 4749): Thread[27,tid=5942,Native,Thread*=0xb9ecce90,peer=0x785da0e0,"Thread-840"] attached without supplying a name

W/Adreno-ES20( 4749): <core_glUseProgram:1526>: GL_INVALID_VALUE

W/Adreno-ES20( 4749): <core_glUseProgram:1526>: GL_INVALID_VALUE

W/Adreno-ES20( 4749): <core_glUseProgram:1526>: GL_INVALID_VALUE

I/art     ( 2289): Heap transition to ProcessStateJankImperceptible took 60.241699ms saved at least 317KB

D/WifiService(  623): acquireWifiLockLocked: WifiLock{NlpWifiLock type=2 binder=android.os.BinderProxy@1c090246}

D/WifiService(  623): releaseWifiLockLocked: WifiLock{NlpWifiLock type=2 binder=android.os.BinderProxy@1c090246}

I/wpa_supplicant( 2496): wlan0: CTRL-EVENT-SCAN-STARTED

I/WifiHAL (  623): Found some events!!!

I/WifiHAL (  623): Found some events!!!

I/PowerUI.Notification( 1800): dismissing low battery warning: level=100

I/PowerUI.Notification( 1800): dismissing low battery notification

D/PowerUI.Notification( 1800): updateNotification mWarning=false mSaver=false mInvalidCharger=false

I/notification_cancel(  623): [10019,1800,com.android.systemui,100,low_battery,0,0,64,8,NULL]

I/wpa_supplicant( 2496): wlan0: CTRL-EVENT-SCAN-STARTED

I/WifiHAL (  623): Found some events!!!

I/WifiHAL (  623): Found some events!!!

I/PowerManagerService(  623): Going to sleep due to screen timeout...

I/power_sleep_requested(  623): 0

I/PowerManagerService(  623): Sleeping...

I/power_screen_broadcast_send(  623): 1

I/power_screen_state(  623): [0,3,0,0]

I/screen_toggled(  623): 0

I/am_pause_activity(  623): [0,379306882,air.com.flaregames.wordon/.AppEntry]

D/[CoreMobileEx]( 4749): Pause.

D/[PushNotifyEx]( 4749): Pause.

E/native  (  623): do suspend true

The above happened in GPU and CPU render mode but below only happens GPU render mode.

W/Adreno-ES20(13762): <core_glBindVertexArrayOES:288>: GL_INVALID_OPERATION

I/sf_frame_dur(  190): [air.com.flaregames.wordon/com.tapjoy.TJCOffersWebView,101,3,2,0,1,0,0]

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/art     (13762): Thread[37,tid=14108,Native,Thread*=0xb9bcb640,peer=0x783e53e0,"Thread-901"] attached without supplying a name

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

W/Adreno-ES20(13762): <gl_draw_error_checks:580>: GL_INVALID_OPERATION

TOPICS
Development

Views

1.1K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

I have seen similar things in other versions of Android OS. The general case is that in showing a native overlay the OS sometimes clears GPU textures to make room for what it needs. It does that in a way that AIR is not aware of, and so when you get back to your app you may even have a fully black screen, The fact that some things are not black suggests that those items are constantly changing, which is a problem you might want to look into! In an ideal case you would have a black screen.

The cure is to force your app to refresh everything. When you call up an overlay, change the stage quality. If you normally use "low" (which is often a good choice when doing GPU render mode), set it to "medium". If you use "medium", set it to "low". When the overlay is closed, set the quality back to what it was before. That may well fix everything.

If I'm right about this you'll find that the problem isn't an ANE one. You can do a test, set an alarm for one minute from now, go into your app, and when the alarm dialog comes up, close it. I think you'll find your graphics are messed up again.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

Thanks for your replay! We tested both your suggestions but with no result:( The stage quality change did not fixed the artifacts and the test with the timer succeed with the graphics intact.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

Man, I suck!

You should keep that fix in there anyway, it will help older Android devices. I must pester Google to send me an Android L device...

Is there anything about your backdrop areas that is handled in a different way to the other layers? Like, are the ones that go away bitmaps or vectors?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

Hey Colin, thanks for your suggestions. It seems to be hitting both vectors and bitmaps equally, but it's interesting to note that drawing the entire screen into a BitmapData results in perfectly good image (which tells me the internal draw, before the render output, is correct). Ofcourse, it's not something to repeat 60 frames per second, just thought I'd throw it out there. Besides elements disappearing (ie. going black), other display objects have palette swaps and some transparencies seem to be gone.

The video memory is garbled or references are lost, but it seems like an opengl issue in combination with AIR and Android L. I've only seem somewhat similar results with devices running modded firmware in the past.

And the only direct log lead we have is the huge amount of GL_INVALID_OPERATION warnings which keep for every frame refresh when interacting with the app.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

Colin, me again, I'm afraid we didn't test the StageQuality solution thoroughly (was implemented in handler after closing the native view). Having it attached to a button, being able to switch between various modes, I can now safely say that this indeed will 'shock' AIR into the correct display mode again. Having stepped into this direction further, it seems like we can go from "high" back to "low" right after eachother to get back to where we were.

But I have yet to achieve this in a secure way for different devices as it won't have any effect when switching straight from the activation callback for example [NativeApplication.nativeApplication.addEventListener(Event.ACTIVATE, OnActivate)]  (even though this is called, I can see it from my trace output when switching from the native view back into the AIR app). So it appears we have to delay for an undefined amount of time (Event.ACTIVATE and events from ANE like VIEW_CLOSED seem to be too soon. The glitches start happening *after* those).

So for now, the somewhat ugly workaround is to simply wait before toggling the quality in the Event.ACTIVATE handler. But surely, something like this should could be improved:

if (Settings.IS_ANDROID)

{

      setTimeout(function():void

      {

          stage.quality = StageQuality.HIGH;

          stage.quality = StageQuality.LOW;

      }, 500);

}

Any idea?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Sep 30, 2014 Sep 30, 2014

Copy link to clipboard

Copied

Glad to hear that I don't suck anymore! The two cases are that you do something that causes a deactivate, and then the activate should be able to fix the issue, or you're overlaying without involving a deactivate, in which case you have to track that yourself, and fix things after the overlay goes way.

I think you could go further than your current work around, and even use enterframe. I believe that there are no enterframes while these overlay things are going on, so you could set an enterframe listener that fixes things, and it will get triggered on either an activate or if you close your overlay.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Oct 01, 2014 Oct 01, 2014

Copy link to clipboard

Copied

LATEST

I've settled on the following workaround, which fixes the problem consistently, albeit with a slight flicker sometimes:

  • Check if you're on Android;
  • Add an ENTER_FRAME listener to the stage in the activation handler (called when returning to the app from an overlay displayed by a native extension);
  • Use a ticker to have 2 frames delay between the quality switch, anything quicker than that resulted in inconsistent or non-functional behavior for our app;
  • Switch from StageQuality.LOW to StageQuality.HIGH and back again. Going to MEDIUM and back did *not* result in a fix.

In my case, the code for the switch itself looks like this:

private function OnActivate(event:Event):void
{          
     if (Settings.IS_ANDROID)
     {
          _Ticker = 0;
          stage.addEventListener(Event.ENTER_FRAME, OnEnterFrameFixGPUContextLoss);
     }
}
private function OnEnterFrameFixGPUContextLoss(event:Event):void
{
     _Ticker ++;
               
     if (stage.quality.toLowerCase() == StageQuality.LOW) // stage.quality returns string in capitals
     {
          stage.quality = StageQuality.HIGH;
     }
     else
     {
          if (_Ticker > 2)
          {
               stage.quality = StageQuality.LOW;
               stage.removeEventListener(Event.ENTER_FRAME, OnEnterFrameFixGPUContextLoss);
          }
     }
}

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines