NullPointerException in the MainRender.getSurfaceTexture method
Describe the bug The app crashes when starting a stream due to a NullPointerException in the MainRender.getSurfaceTexture method.
To Reproduce Steps to reproduce the behavior:
Open the app. Navigate to the stream setup screen. Start a new screen broadcast stream session. Observe the app crash.
Expected behavior The stream should start successfully without crashing.
Screenshots
Smartphone (please complete the following information):
Library version: 2.5.4 Device: Motorola Malta OS: Android 10 (SDK 29) Media server: [e.g. SRS, version 5.0] Class used: [e.g. RtmpCamera1] Additional context Crash logs from Play Console:
Exception java.lang.RuntimeException:
at android.app.ActivityThread.deliverResults (ActivityThread.java:4873)
at android.app.ActivityThread.handleSendResult (ActivityThread.java:4914)
at android.app.servertransaction.ActivityResultItem.execute (ActivityResultItem.java:51)
at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:135)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:95)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2041)
at android.os.Handler.dispatchMessage (Handler.java:107)
at android.os.Looper.loop (Looper.java:214)
at android.app.ActivityThread.main (ActivityThread.java:7386)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:980)
Caused by java.lang.NullPointerException:
at com.pedro.encoder.input.gl.render.MainRender.getSurfaceTexture (MainRender.kt:176)
at com.pedro.library.view.GlStreamInterface.getSurfaceTexture (GlStreamInterface.kt:118)
at com.pedro.library.base.StreamBase.startSources (StreamBase.kt:451)
at com.pedro.library.base.StreamBase.startStream (StreamBase.kt:156)
at com.atharvasystem.quickscreenrecorder.services.ShareScreenService.startStream (ShareScreenService.kt:168)
at com.atharvasystem.quickscreenrecorder.ui.streams.StreamSourceActivity.activityResultContract$lambda$0 (StreamSourceActivity.kt:102)
at com.atharvasystem.quickscreenrecorder.ui.streams.StreamSourceActivity.$r8$lambda$LtWeMkLkNKtetOKKVdlgnnLpK3s (Unknown Source)
at com.atharvasystem.quickscreenrecorder.ui.streams.StreamSourceActivity$$ExternalSyntheticLambda2.onActivityResult (D8$$SyntheticClass)
at androidx.activity.result.ActivityResultRegistry.doDispatch (ActivityResultRegistry.kt:371)
at androidx.activity.result.ActivityResultRegistry.dispatchResult (ActivityResultRegistry.kt:331)
at androidx.activity.ComponentActivity.onActivityResult (ComponentActivity.kt:786)
at androidx.fragment.app.FragmentActivity.onActivityResult (FragmentActivity.java:151)
at android.app.Activity.dispatchActivityResult (Activity.java:8110)
at android.app.ActivityThread.deliverResults (ActivityThread.java:4866)
Hello,
we are also getting same above crash when using genericCamera2 with OpenGlView.
Can you give me more info about it? Can you reproduce it using an older version? in which version is working fine? Are you checking that prepareVideo and prepareAudio return true before startStream?
Can you share me a code example to reproduce it?
Also, the library version 2.5.5 is not the version which crash in the image because the crash line is not correct. Line 451 is this: https://github.com/pedroSG94/RootEncoder/blob/2.5.5/library/src/main/java/com/pedro/library/base/StreamBase.kt#L451
Which no correspond to the logcat. I need know the exact compilation used
Thank you for your response!
Validating URL and Key: We are checking and validating the URL and stream key before starting the stream and also validating during the stream when using screen broadcast.
Reproducing Issue in Older Versions: Apologies for the confusion earlier. The crash occurred in version 2.5.4, not 2.5.5.
Checking prepareVideo and prepareAudio: Yes, we are ensuring that prepareVideo() and prepareAudio() return true before starting the stream.
Code Example:
Here’s a snippet of the code we are using to reproduce the issue:
Let me know if further details are required!
Crash Line and Library Version: I’ve double-checked, and you’re right—2.5.5 doesn’t align with the crash log. The crash occurred with 2.5.4, and I’ll ensure the exact compilation details are provided. I'll update this thread with those details soon.
Thank you for your help in resolving this!
Hello,
Can you show me code of prepareStream method?
Yes @pedroSG94
fun prepareStream(resultCode: Int, data: Intent): Boolean {
keepAliveTrick()
stopStream()
val mediaProjection = mediaProjectionManager.getMediaProjection(resultCode, data)
if (mediaProjection == null) {
Log.e(TAG, "MediaProjection is null")
return false
}
val screenSource = ScreenSource(applicationContext, mediaProjection)
return try {
//ScreenSource need use always setCameraOrientation(0) because the MediaProjection handle orientation.
//You also need remove autoHandleOrientation if you are using it.
//You need to call it after prepareVideo to override the default value.
genericStream.getGlInterface().setCameraOrientation(0)
genericStream.changeVideoSource(screenSource)
genericStream.getStreamClient().setReTries(5)
prepareVideoAudio()
} catch (ignored: IllegalArgumentException) {
false
}
}
```
Hello,
Sorry for late response. I'm on holidays
I will create multiple checks for this case in a commit.
Do you know if this crash is frequent?
This only should happens when glInterface start is not fully completed because the SurfaceTexture is ceated in that method but reading the code that nerver should happens. If you are using multithreading make sure use the library always with the same thread to avoid thread problems
Hi @pedroSG94
No problem at all, I hope you're enjoying your holidays!
Regarding your question about the crash frequency, I don't have exact data on how often it occurs, but it seems to happen intermittently in the app. I’ve noticed it a couple of times, but it’s not consistent, so I’m not sure if it’s a recurring issue or just a rare occurrence.
I’m using the library on the main thread as recommended, so I don’t believe threading is the issue here. It seems like the crash might be linked to the glInterface start not completing fully, as you mentioned. I’ll keep an eye on it and provide more details if it happens again.
Looking forward to your commit with the checks, and I’ll test it once it’s ready!
Thanks for your help, and enjoy the rest of your holidays!