CVE-2024-34736 AI-generated analysis
platform/frameworks/av, media/libmediaplayerservice (StagefrightRecorder, MediaRecorder video encoder setup)
StagefrightRecorder::setupVideoEncoder now forces zero B-layers (bLayers = 0) in the temporal-layering "ts-schema" when the audio source is AUDIO_SOURCE_MIC and the video source is VIDEO_SOURCE_SURFACE, which disables B-frame layering for the screen-recorder-with-microphone use case.
Root cause
In media/libmediaplayerservice/StagefrightRecorder.cpp, setupVideoEncoder() works out the number of temporal layers (tsLayers) from the expected playback frame rate. When tsLayers > 1 it always requests up to two B-layers (bLayers = min(2, tsLayers - 1)) through the "ts-schema" format key "android.generic.<pLayers>+<bLayers>", and it sets "android._prefer-b-frames". The commit message says that screen recording (VIDEO_SOURCE_SURFACE) with microphone audio (AUDIO_SOURCE_MIC) does not play with audio and video in sync when B-frames are enabled. The material does not show how this maps to the bulletin's "ID" (information disclosure) classification.
How the fix works
- media/libmediaplayerservice/StagefrightRecorder.cpp:StagefrightRecorder::setupVideoEncoder(): the fix adds `if (mAudioSource == AUDIO_SOURCE_MIC && mVideoSource == VIDEO_SOURCE_SURFACE) { bLayers = 0; }` inside the existing `if (tsLayers > 1)` block, right after `bLayers = std::min(2u, tsLayers - 1)`. For that use case pLayers becomes tsLayers and the ts-schema string becomes `android.generic.<tsLayers>+0`.
- The change carries a TODO (b/341121900) that describes it as a temporary workaround, to be removed once B frames are handled correctly in the screen recorder mic-only case.
- Single-commit fix: five added lines, no other files touched.
Completeness
- Only the exact combination mAudioSource == AUDIO_SOURCE_MIC && mVideoSource == VIDEO_SOURCE_SURFACE is affected. The commit message says INTERNAL (device) or MIC_AND_INTERNAL audio with screen recording keeps B-frame support on purpose.
- The `android._prefer-b-frames` key is still set from preferBFrames as before. Only the B-layer count in ts-schema is zeroed for the targeted case.
- Other combinations of audio and video source are unchanged and still get up to two B-layers when tsLayers > 1.
- The commit is explicitly a workaround (TODO to remove). It does not fix the underlying B-frame handling in the screen-recorder path.
Behavior changes
- For recordings with audio source MIC and video source SURFACE, the encoder is configured with ts-schema android.generic.N+0 (no B-layers) instead of android.generic.(N-b)+b.
- No new error codes or API behavior changes are visible in the diff. This is purely an encoder configuration change.
Per major
- Android 14: same fix: cherry-picked as 6cfd048292b2 into android-security-14.0.0_r11 (bug 288549440). All 5 patched lines are present at android-security-14.0.0_r29.
- Android 15: not affected (not listed by the bulletin). The patched lines are present at android-security-15.0.0_r17.
- Android 16: not affected (not listed by the bulletin). The patched lines are present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). The patched lines are present at android-security-17.0.0_r1.
Unknowns
- How the A/V desync with B-frames amounts to the bulletin's High-severity information disclosure. The diff and commit message describe only a sync problem.
- Whether the underlying B-frame issue referenced by TODO b/341121900 was later fixed and this workaround removed on any branch. The patched lines are still present through android-security-17.0.0_r1.
- Whether matching changes were made on the encoder or MediaCodecSource side. Only this one commit is provided.
- Whether the encoder emits no B-frames at all given that android._prefer-b-frames is still set.
- Whether the patch applies cleanly to Android 12, 12L and 13 trees.