Adobe-Runtime-Support icon indicating copy to clipboard operation
Adobe-Runtime-Support copied to clipboard

NullPointerException in AndroidIdleState on SCREEN_OFF broadcast after AIR SDK update

Open Tuning3DT opened this issue 5 months ago • 9 comments

Hello, After updating to AIR SDK [your version number] and the latest ANEs, we started seeing increased crashes on Android devices. Crash occurs when handling the android.intent.action.SCREEN_OFF broadcast:

Caused by java.lang.NullPointerException
Attempt to invoke virtual method 'void com.adobe.air.AndroidActivityWrapper.onScreenStateChanged(boolean)'
on a null object reference
at com.adobe.air.AndroidIdleState$1.onReceive(AndroidIdleState.java:59)

This issue did not occur in the previous AIR SDK version we were using 51.1.1.2. Crash log attached.

AIR SDK: 51.1.3.8

air.com.A3dtuning.Tuning3D_issue_2badf97748163251ee82588ce470c212_crash_session_689EB3EA00C800017F846216DC64D05C_DNE_0_v2_stacktrace.txt

Tuning3DT avatar Aug 15 '25 07:08 Tuning3DT

There is also a significant increase in this type of crash.

AppEntry.onStop
java.lang.NullPointerException - Attempt to invoke virtual method 'com.google.firebase.perf.util.Optional com.google.firebase.perf.application.FrameMetricsRecorder.stop()' on a null object reference

air.com.A3dtuning.Tuning3D_issue_61e1ac9a91999c4bc27dbca4de7b15e9_crash_session_689F0BA601F60001253875F5A81427B2_DNE_0_v2_stacktrace.txt

xxxVBxxx avatar Aug 15 '25 10:08 xxxVBxxx

Thanks for the details.

Are you using the 'runtime in background thread' setting? We do sometimes see synchronisation issues which we're having to capture/work around...

So the first one, we can add some protection into our class here, which will mean the asynchronous listener just turns into a no-op.

For the second one, I've just checked the Firebase source code and I'm not sure how we end up with the 'onStop' method seemingly called after 'onDestroy' (in order to make that null reference...) - best we could do here is catch the exception within our own activity's call to the base class (Activity.onStop in the call stack) but ideally the Firebase code should be checking they have a reference before they call 'stop' on it... even if we catch the error, it's likely to leave Firebase in an odd state.

Is that something that you're able to reproduce at will, or is this just happening on some phones in the field?

thanks

ajwfrost avatar Aug 15 '25 11:08 ajwfrost

Thanks for the reply @ajwfrost I’ve checked and I don’t have <runtimeOnBackgroundThread> set in my descriptor. So the runtime should be on the main thread.

I haven’t been able to reproduce either issue on my own device, but they’re definitely occurring in the field across multiple devices — so they’re not device-specific.

Image Image

Tuning3DT avatar Aug 15 '25 12:08 Tuning3DT

Hello @ajwfrost, After updating to AIR SDK 51.2.2.3, this crash is no longer occurring. Thanks a lot to the Harman team for fixing it!

Tuning3DT avatar Aug 26 '25 13:08 Tuning3DT

@ajwfrost though the second crash still exists with AIR SDK 51.2.2.3.

air.com.A3dtuning.Tuning3D_issue_61e1ac9a91999c4bc27dbca4de7b15e9_crash_session_68AF99D700790001636F28CE3C163AB0_DNE_0_v2_stacktrace.txt

AppEntry.onStop
java.lang.NullPointerException - Attempt to invoke virtual method 
'com.google.firebase.perf.util.Optional com.google.firebase.perf.application.FrameMetricsRecorder.stop()' 
on a null object reference

We’re also seeing an increase in this type of crash since the update:

air.com.A3dtuning.Tuning3D_issue_71b485170a459df0071288794a1c0a20_crash_session_68B0030503910001419B313814B9671E_DNE_0_v2_stacktrace.txt

xxxVBxxx avatar Aug 28 '25 07:08 xxxVBxxx

@xxxVBxxx that second crash is one we have seen in reports a number of times but no one has ever managed to get a reproduction of it .. do you have any possibility of capturing logcat traces from devices on which this is happening?

Also can I check:

  • do you have the <fullScreen> directive in your application descriptor?
  • do you change the Stage.displayState at all?
  • do you have StageVideo support (via the app descriptor <containsVideo> flag)?

thanks

ajwfrost avatar Aug 28 '25 12:08 ajwfrost

@xxxVBxxx that second crash is one we have seen in reports a number of times but no one has ever managed to get a reproduction of it .. do you have any possibility of capturing logcat traces from devices on which this is happening?

Also can I check:

  • do you have the <fullScreen> directive in your application descriptor?
  • do you change the Stage.displayState at all?
  • do you have StageVideo support (via the app descriptor <containsVideo> flag)?

thanks

  1. Yes, We have <fullScreen>true</fullScreen>
  2. NO, We never change the Stage.displayState
  3. Yes, We have <containsVideo>true</containsVideo>

xxxVBxxx avatar Aug 28 '25 13:08 xxxVBxxx

@ajwfrost unfortunately I was unable to reproduce any of those crashes
I tried capturing logcat traces but no crash occurred

xxxVBxxx avatar Aug 29 '25 06:08 xxxVBxxx

Hello @ajwfrost, Both of the earlier Android crashes are completely gone after updating the SDK to 51.2.2.4 — thank you very much for that fix.

However, on the latest build we’re now seeing a new type of crash, which has become the most frequent crash in this version of the app.

Image Image Image

air.com.A3dtuning.Tuning3D_issue_65ad8d383e43be3af241b194b1950ae3_crash_session_68C8E35102900001449543D9B70AFA8E_DNE_0_v2_stacktrace.txt

Tuning3DT avatar Sep 16 '25 06:09 Tuning3DT