libstagefright.so SIGSEGV on various Android 7/7.1 devices after upgrading to 2.5.1

[dbrain]

Issue description

After upgrading ExoPlayer to 2.5.1 (from 2.4.4) we are seeing a lot of user reports of a libstagefright.so SIGSEGV. Playback starts, but a crash occurs when the player is released. This may be specific to Widevine+DASH, as the demo app will not crash using the Youtube DASH demos, while it crashes the same as our application on Widevine+DASH demos.

I have a feeling this may be related to the recent CENC support added:
#1989
But I also don't know what I'm talking about, so who knows ;)

I had a quick play at making DefaultDrmSessionManager return false for canAquireSession if the type was cenc etc. (that whole conditional), but ExoPlayer never seemed to call that method at all. Will fiddle a bit more, but thought I'd raise this ASAP.

A remote colleague has a device that can reproduce the crash (Motorola G5 Plus), but there's a bit of a lag getting debug information. Sorry if this contains limited information.

Reproduction steps

1. Launch the demo app on an effected device
2. Start a Widevine+DASH demo (WV: Secure SD & HD (cenc,MP4,H264) definitely reproduces this)
3. Let playback begin
4. Press back leaving playback, releasing the player
5. Crash should occur

Link to test content

Reproducible in the demo WV: Secure SD & HD (cenc,MP4,H264), so not required.

Version of ExoPlayer being used

2.5.1

Device(s) and version(s) of Android being used

Seems to be 7.0/7.1 specific, but multiple devices. Easily reproducible, as it occurs from what I can tell any time when releasing the player after playback has begun.

Here are the play store device/version graphics:

A full bug report captured from the device

Here's a zipped adb bugreport > libstagefright-widevine-dash-crash.log from our application (iflix.play.dbg).
libstagefright-widevine-dash-crash.zip

[ojw28]

How are you setting the Surface on the player, and is it possible that the Surface is being cleared before the player is released? Note that if you're passing the SurfaceView, TextureView or SurfaceHolder to the player, this may be happening internally.

If so then I'd suggest DummySurface is the most likely cause. To verify this suggestion, could you please try locally modifying DummySurface.isSecureSupported to return false, and then see if that makes the issue go away on an affected device? Thanks!

[dbrain]

@ojw28 The app is using SimpleExoPlayerView and SimpleExoPlayer and leaving it up to SimpleExoPlayerView to handle the Surface side of things. There's nothing specific in our codebase touching the Surface, and SimpleExoPlayer.release() is called onStop().

Which is pretty much exactly how the demo app is set up looking at it, and is also crashing at the same point.

I'll get a build of the demo app with the DummySurface change to my colleague with a device that can reproduce the issue and let you know. Thanks for the quick response!

[dbrain]

@ojw28 Looks like that change resolved the crash. How do we go about getting a fix in for a future release?
Happy to create a PR myself if you can give me some guidance on the best solution.

Seems there's a deviceNeedsSecureDummySurfaceWorkaround method that returns true for specific devices, but there's over 20 affected devices that I know about in this scenario.

For now we'll be dropping the application back to 2.4.4.

[ojw28]

That's unfortunate. I think we'll need to restrict the feature and roll it out more cautiously, due to the number of devices that are affected. I suspect all (or nearly all) of the affected devices return false from packageManager.hasSystemFeature(PackageManager.FEATURE_VR_MODE_HIGH_PERFORMANCE);, so we could try requiring that to be true if SDK_INT < 26 for use of secure DummySurface to be enabled.

[dbrain]

Does (Util.SDK_INT >= 24 && Util.SDK_INT < 26 && !hasVrModeHighPerformanceSystemFeatureV24(context.getPackageManager())); look sane enough?

I brought back the hasVrModeHighPerformanceSystemFeatureV24 method which seems to have been removed in dev-v2. So I'm checking that device is >= 24 i.e. has FEATURE_VR_MODE_HIGH_PERFORMANCE at all, < 26 because presumably the issue is fixed after 25 and that it does not have the FEATURE_VR_MODE_HIGH_PERFORMANCE system feature.

Just verifying it's happy on the one effected device I have "available" to me.

[dbrain]

The above solved the issue on the Moto G5 Plus at least.