Event.TEXTURE_READY not dispatched on Android

[marpies]

It's an AIR issue but I thought I should let you know about it. I recently found it's possible to crash an app if a texture is disposed while the bitmap data is being uploaded asynchronously; Adobe is currently looking into it.

The actual problem is that the Event.TEXTURE_READY event fails to be dispatched after some time on Android, practically leaving the texture in the "uploading" state. Once this occurs, the event is never dispatched for subsequent texture uploads; the app has to be restarted. There is no error and the app continues to run, it's just that any further async texture uploads do not work. Unfortunately, Adobe says they cannot reproduce this, but I think it's pretty serious issue as it eventually breaks the app down.

I'm able to reliably reproduce it on devices like Nexus 7 2013 or Sony Xperia Z3, both running Android 6. I haven't encountered this issue on old samsung phone running Android 4. I was wondering if you have ever seen this happen?

In case you'd like to test it on some of your devices, I've created a sample project where a bitmap data is uploaded and disposed repeatedly. If you create apk-debug and launch a logcat, you will see a counter that tracks the number of uploads. I've seen the event to stop being dispatched randomly, for example at 90th, 250th or 700th cycle. I'm using AIR 25.0.0.126 and -swf-version=36.

sample-project-upload.zip

EDIT: Added ready-to-use APK of the sample project:
com.example.sample.apk.zip

[PrimaryFeather]

Thanks a lot for the heads-up!

I just tried your sample with an ZTE Blade A910 running Android 6.0, where I could not reproduce it; however, on an 2012 Nexus 7, the app stops after just a handful of images (no more than 10). You are right, this is a critical problem, especially since the AssetManager now loads textures asynchronously per default. Maybe I need to make this optional instead — depending on what Adobe manages to do about it.

In any case, I voted for the issue! Please keep me updated if you find out anything new. Thanks in advance! 😄

[marpies]

Thanks for checking it out, Daniel. I'll keep you updated on the progress.

Just a quick question - what Android version is your 2012 Nexus running? Thanks!

[PrimaryFeather]

Ah, sorry, totally forgot to mention that. That one's still running Android 4.3!

[randalfien]

I couldn't reproduce the issue on Nexus 5X with Android 7.1.1.
I used the precompiled apk.

[marpies]

Thanks for testing it out @randalfien.

Here's a list of devices that have been tested so far:

Nexus 5X (7.1.1) – OK
Samsung SM-G550T (6.0.1) – OK
Samsung SM-N9005 (5.0) – OK
Samsung GT-I9300 (4.3) – OK
Samsung GT-P5100 (4.2.2) – OK
ZTE Blade A910 (6.0) - OK

Nexus 7 2012 (4.3) - FAIL
Nexus 7 2013 (6.0.1) - FAIL
Sony Xperia Z3 (6.0.1) - FAIL

[PrimaryFeather]

Have you recently tried this again, @marpies?

I just looked into it again, and I couldn't reproduce it with the latest AIR 27 version — however, I also failed to reproduce it with the old AIR 25 today, on the same Nexus device as in March. Which is really strange.

For reference: with the current Starling version, you have to add the following code so that Starling even attempts to load the texture asynchronously:

Texture.asyncBitmapUploadEnabled = true;

I did that, and the async methods are definitely called. Still, no luck in reproducing it today. However, in the "Adobe Tracker" report, there hasn't been much going on either, so I suppose nothing changed yet.

[marpies]

@PrimaryFeather
Yes, unfortunately I'm still able to reproduce it with the latest Starling and AIR 27. Sometimes it takes a while to occur, but seems to happen every time on the aforementioned devices. Adobe hasn't reported anything about it in a while, so who knows if this is ever going to get fixed.

I wouldn't recommend using the async upload in production for Android without some sort of detection in place. The good thing is you can still fallback to sync upload if you detect the async upload has failed (i.e. the callback hasn't been triggered for too long).

[PrimaryFeather]

Thanks for the update, Marcel! I'll ping Adobe again and ask if there has been any progress.

You're right, I could also implement a workaround on Starling's side, as a last resort. I'm considering that!

[PrimaryFeather]

Hey Marcel,
I just received a little more information about this from Adobe. They're saying:

We were not able to reproduce the “texture decoding failed ”issue as Nexus7 devices were not available with us, but we did observe the crash for the sample application attached by the user. We investigated the issue by creating the native application and observed that it is not the AIR runtime issue and was reproducible on the Android 6 devices available with us having Adreno 4xx GPUs.

As I understand this, it seems to be a driver bug Adobe can't do anything about. Which is a bummer, of course. 😞

So I'd like to see if we can add a workaround for this inside Starling. I'd like to avoid a timeout, though, and maybe react to the exception. If you try this on one of the affected devices, could you check where exactly the error occurs?

• Is the error caught by this try/catch block?
• Which is the exact error ID? (From your Adobe Tracker issue, I guess it's "3677"?)
• If you add that ID to the manual check I'm doing in this line, does the issue go away?

Thanks in advance, Marcel!

[marpies]

Hi Daniel,

Thanks for keeping an eye on this.

The crash issue mentioned by Adobe was caused by disposing a texture while it was still uploading asynchronously. I think sometimes the error 3677 was thrown instead of a crash and this is what I initially reported (it's been fixed by Adobe). However only later I found the bigger problem is the fact that the event TEXTURE_READY stops being dispatched by the runtime after some time, effectively keeping the uploaded texture in the "uploading" state forever. When this happens, there is no error thrown or dispatched, basically no feedback at all, which means you will likely need to use a timeout if you want to do something about it. I can't think of anything else to be honest.

We are currently experimenting with a class that handles all the texture uploads in the app and uses a timeout to detect any uploads that take too long. When the timeout is fired, the class fallbacks to using sync upload only. This way the app "recovers" after a small period of time when no new textures appear. We are also using a queue and uploading at most one texture at any given time, so it's fairly straightforward in implementation. As an example, imagine scrolling through a gallery of images:

1. The images are appearing just fine (async upload still working)
2. The issue kicks in, new images do not appear for a moment
3. The timeout fires, we fallback to sync upload
4. The images start appearing again

We haven't used this in production yet, so we don't have any data on how many devices could be affected.

I can reproduce the issue reliably, so I am happy to test any workarounds you might come up with.

[PrimaryFeather]

Thanks a lot for the additional information, Marcel!

Ah, I see, so the error and the timeout are two separate things. Indeed, that makes it harder to add a workaround. Because when using a timeout, it's difficult to find the sweet spot between "it just takes damn long" and "it's taken too long". 😉 But something needs to be done, otherwise this feature is rather useless on Android.

Perhaps, if you are using this in production, you can report your results here? This would be a huge help!

[marpies]

Yeah it could be tricky to get a workaround in place for this. I will definitely report any production data if we manage to collect any.

However it was just brought to my attention that the async upload has its issues on iOS as well. The textures simply fail to be rendered on the screen after some time and eventually a crash occurs with this stacktrace:

0   libGPUSupportMercury.dylib    	0x2be92742 gpus_ReturnUnexpectedKillClient + 2
1   libGPUSupportMercury.dylib    	0x2be93202 gpusSubmitDataBuffers + 118
2   libGPUSupportMercury.dylib    	0x2be93078 gldCreateContext + 204
3   GLEngine                      	0x2769ce06 gliCreateContextWithShared + 598
4   OpenGLES                      	0x27779a8c -[EAGLContext commonInitWithAPI:properties:] + 404
5   OpenGLES                      	0x277798c6 -[EAGLContext initWithAPI:sharegroup:] + 110
6   Async Upload Sample           	0x00029874 0xe000 + 112756
7   Async Upload Sample           	0x006d7e40 0xe000 + 7118400
8   Async Upload Sample           	0x004b1c48 0xe000 + 4865096
9   Async Upload Sample           	0x004b1d70 0xe000 + 4865392
10  Async Upload Sample           	0x004b1928 0xe000 + 4864296
11  libsystem_pthread.dylib       	0x33bcfddc _pthread_body + 136
12  libsystem_pthread.dylib       	0x33bcfd4e _pthread_start + 114
13  libsystem_pthread.dylib       	0x33bcdaf8 thread_start + 4

It can be reproduced with the sample project I originally posted at the top, it just takes much longer to occur in this sample (20+ minutes) than what it takes on Android. It looks like the more uploads are made the sooner it happens. There is no issue with sync upload. I can't help but think it is somewhat similar to this Android issue I reported in the past.

I'll try to work up a demo where it is much quicker to reproduce and create a bug report for Adobe.

[marpies]

I created a report for the iOS issue, please leave a vote, thanks!

[PrimaryFeather]

Awesome — thanks a lot for your efforts, Marcel!