You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I enter Telegram and open someone's story, the area of the media (photo - video; Telegram stories goes as video even if you upload photo) become black in the screenshot and screen record. If I pause the story/video, then I can see the full screen without black areas. Sound of the story/video is there. Incognito mode in the Chrome doesn't have such issues so far.
At first I thought it might be Widevine issue. But even I lowered my L1 status to L3 via liboemcryptodisabler module, it didn't make any difference. Logcat also doesn't say something about the Widevine - DRM.
Investigating via logcat and with ChatGPT, it made some conclusions which I believe those makes sense.
Since its not an Widevine - DRM issue and can't solved by disabling secure flag layer, and also very importantly I believe, that the problem occurs when a video playing; I and GPT think its because another layer in the device which controls video playing principles.
This issue doesn't occur in the Ayugram (modded Telegram with ToS breaking features such as disabling saving - recording restrictions)
I disabled HW overlays via developer settings and in Termux but it made no difference. Via logs and tests, here is the ChatGPT's conclusion:
ChatGPT's conclusionDiagnosis:
Core conclusion
The captured behavior is caused by native-level protected graphic buffers / secure surface layers, not by the Activity/window FLAG_SECURE or Widevine/CDM. While the UI-level blocking can be removed, the video frames themselves are allocated or marked such that SurfaceFlinger / gralloc / the vendor HWC path exclude them from readback. That is why screenshots or screen recordings show a black rectangle over the playing media but capture the same area normally once playback is paused.
Key evidence that points to surface/buffer protection (not DRM or window flag)
The media area becomes black only while the video is playing; pausing the video immediately allows full capture. This is the classic symptom of protected GraphicBuffer behavior: protected buffers exist only during active playback.
Disabling FLAG_SECURE (Xposed / Java-level) and disabling hardware overlays (settings put global disable_hw_overlays 1) do not change the outcome. Those actions affect window-level flags and composition type (HWC vs GPU) but do not alter protected-buffer allocation or readback policy.
Forcing Widevine to L3 (liboemcryptodisabler) also had no effect and logcat showed no Widevine/CDM-related blocks; codec logs did not indicate FLAG_PROTECTED frames. This indicates the restriction is applied by the graphics stack (gralloc/SurfaceFlinger/HWC), not by CDM enforcement.
SurfaceFlinger logs and dumps include layer creation entries and messages that match protected/secure layer semantics (for example, createSurf entries with secure flags, and explicit “failed to take screenshot with contains secure layers” / “Screenshot bitmap was null” style messages). Those entries show the layer is marked secure/protected at the native compositor level.
Technical explanation (how and where the block is applied)
At playback the pipeline typically does: media decoder → ANativeWindow / SurfaceView → GraphicBuffer allocation (gralloc) → SurfaceFlinger → HWC / display.
If the buffer is allocated with protected usage (e.g. GRALLOC_USAGE_PROTECTED / vendor private protected bits), the vendor gralloc/HAL places that buffer onto a protected display path. Protected buffers are intentionally excluded from any readback or capture: they are not exposed to CPU or normal framebuffer read paths and SurfaceFlinger will not return them during screenshots or MediaProjection.
The protected path can be backed by hardware features (secure display path, TrustZone-assisted protection, or hardware encryption of the frame memory). Even if composition is forced to GPU instead of HWC, the buffer’s protected/readback-denied property persists. Thus forcing overlays off or removing window flags does not remove the protection.
Why the previous mitigation attempts fail (summary)
Removing FLAG_SECURE (Java/Xposed): only affects window-level policy; does not change how the video buffer was allocated at native level.
disable_hw_overlays=1: changes composition type but not buffer protection; protected buffers remain non-readable even if composited differently.
liboemcryptodisabler (L1→L3): affects CDM/OEMCrypto and Widevine behavior, but the problem here is the graphic-buffer allocation/hardware protection, not CDM-enforced protected crypto buffers.
Any Java-level or framework-only patch is therefore insufficient because the block is enforced by the gralloc/HAL/SurfaceFlinger and the SoC/vendor display path.
Practical diagnostic artifacts to show this to a maintainer or vendor (commands and expected signs)
Capture runtime logs and layer dumps while reproducing the issue:
createSurf / BLAST / SurfaceView entries with flags that include secure/protected or similar; layer entries showing the app’s SurfaceView marked as secure/protected.
Log lines like “Failed to take screenshot with contains secure layers” or “Screenshot bitmap was null”.
Codec logs showing FLAG_PROTECTED absent (or 0) while the layer is still marked secure — this separates codec/CDM protection from surface-level protection.
Security / bypass implications
This protection is implemented in the native graphics stack and may rely on SoC vendor features (secure display pipeline, gralloc implementation, or TrustZone-assisted protection). It is therefore not something that can be reliably or safely bypassed from Java/framework level.
Effective bypass attempts require native-level intervention (gralloc/GraphicBuffer/ANativeWindow allocation hooks or SurfaceFlinger/libgui patches), device-specific reverse engineering, or privileged kernel/exploit work; those approaches are risky, often break DRM apps, and are typically vendor/SoC-specific. In practice this means a generic “FLAG_SECURE disabler” cannot solve this class of cases.
Short practical conclusion to include after the symptom description
The behavior is caused by protected/native buffer-level enforcement in the graphics stack. Removing FLAG_SECURE or changing composition mode does not remove that protection. For this reason, the module’s current Java-level approach cannot capture Telegram story video while it is playing; addressing that specific case would require native/HAL-level handling (or explicit vendor support).
LSPosed version
1.10.2
Android version
16
Custom OS version
A73 Samsung One UI 8.0 - UN1CA Rom 3.0.0
Version requirement
Behavior
When I enter Telegram and open someone's story, the area of the media (photo - video; Telegram stories goes as video even if you upload photo) become black in the screenshot and screen record. If I pause the story/video, then I can see the full screen without black areas. Sound of the story/video is there. Incognito mode in the Chrome doesn't have such issues so far.
At first I thought it might be Widevine issue. But even I lowered my L1 status to L3 via liboemcryptodisabler module, it didn't make any difference. Logcat also doesn't say something about the Widevine - DRM.
Investigating via logcat and with ChatGPT, it made some conclusions which I believe those makes sense.
Since its not an Widevine - DRM issue and can't solved by disabling secure flag layer, and also very importantly I believe, that the problem occurs when a video playing; I and GPT think its because another layer in the device which controls video playing principles.
This issue doesn't occur in the Ayugram (modded Telegram with ToS breaking features such as disabling saving - recording restrictions)
I disabled HW overlays via developer settings and in Termux but it made no difference. Via logs and tests, here is the ChatGPT's conclusion:
ChatGPT's conclusion
Diagnosis:Core conclusion
The captured behavior is caused by native-level protected graphic buffers / secure surface layers, not by the Activity/window FLAG_SECURE or Widevine/CDM. While the UI-level blocking can be removed, the video frames themselves are allocated or marked such that SurfaceFlinger / gralloc / the vendor HWC path exclude them from readback. That is why screenshots or screen recordings show a black rectangle over the playing media but capture the same area normally once playback is paused.
Key evidence that points to surface/buffer protection (not DRM or window flag)
The media area becomes black only while the video is playing; pausing the video immediately allows full capture. This is the classic symptom of protected GraphicBuffer behavior: protected buffers exist only during active playback.
Disabling FLAG_SECURE (Xposed / Java-level) and disabling hardware overlays (settings put global disable_hw_overlays 1) do not change the outcome. Those actions affect window-level flags and composition type (HWC vs GPU) but do not alter protected-buffer allocation or readback policy.
Forcing Widevine to L3 (liboemcryptodisabler) also had no effect and logcat showed no Widevine/CDM-related blocks; codec logs did not indicate FLAG_PROTECTED frames. This indicates the restriction is applied by the graphics stack (gralloc/SurfaceFlinger/HWC), not by CDM enforcement.
SurfaceFlinger logs and dumps include layer creation entries and messages that match protected/secure layer semantics (for example, createSurf entries with secure flags, and explicit “failed to take screenshot with contains secure layers” / “Screenshot bitmap was null” style messages). Those entries show the layer is marked secure/protected at the native compositor level.
At playback the pipeline typically does: media decoder → ANativeWindow / SurfaceView → GraphicBuffer allocation (gralloc) → SurfaceFlinger → HWC / display.
If the buffer is allocated with protected usage (e.g. GRALLOC_USAGE_PROTECTED / vendor private protected bits), the vendor gralloc/HAL places that buffer onto a protected display path. Protected buffers are intentionally excluded from any readback or capture: they are not exposed to CPU or normal framebuffer read paths and SurfaceFlinger will not return them during screenshots or MediaProjection.
The protected path can be backed by hardware features (secure display path, TrustZone-assisted protection, or hardware encryption of the frame memory). Even if composition is forced to GPU instead of HWC, the buffer’s protected/readback-denied property persists. Thus forcing overlays off or removing window flags does not remove the protection.
Removing FLAG_SECURE (Java/Xposed): only affects window-level policy; does not change how the video buffer was allocated at native level.
disable_hw_overlays=1: changes composition type but not buffer protection; protected buffers remain non-readable even if composited differently.
liboemcryptodisabler (L1→L3): affects CDM/OEMCrypto and Widevine behavior, but the problem here is the graphic-buffer allocation/hardware protection, not CDM-enforced protected crypto buffers.
Any Java-level or framework-only patch is therefore insufficient because the block is enforced by the gralloc/HAL/SurfaceFlinger and the SoC/vendor display path.
Capture runtime logs and layer dumps while reproducing the issue:
adb logcat -c
adb logcat | grep -iE "SurfaceFlinger|createSurf|secure|protected|SKIP_SCREENSHOT|Screenshot|gralloc|BufferQueueProducer|dequeueBuffer"
adb shell dumpsys SurfaceFlinger --layers > /sdcard/sf_layers.txt && adb pull /sdcard/sf_layers.txt
adb shell dumpsys window windows > /sdcard/win.txt && adb pull /sdcard/win.txt
Signs to look for in the outputs:
createSurf / BLAST / SurfaceView entries with flags that include secure/protected or similar; layer entries showing the app’s SurfaceView marked as secure/protected.
Log lines like “Failed to take screenshot with contains secure layers” or “Screenshot bitmap was null”.
Codec logs showing FLAG_PROTECTED absent (or 0) while the layer is still marked secure — this separates codec/CDM protection from surface-level protection.
This protection is implemented in the native graphics stack and may rely on SoC vendor features (secure display pipeline, gralloc implementation, or TrustZone-assisted protection). It is therefore not something that can be reliably or safely bypassed from Java/framework level.
Effective bypass attempts require native-level intervention (gralloc/GraphicBuffer/ANativeWindow allocation hooks or SurfaceFlinger/libgui patches), device-specific reverse engineering, or privileged kernel/exploit work; those approaches are risky, often break DRM apps, and are typically vendor/SoC-specific. In practice this means a generic “FLAG_SECURE disabler” cannot solve this class of cases.
The behavior is caused by protected/native buffer-level enforcement in the graphics stack. Removing FLAG_SECURE or changing composition mode does not remove that protection. For this reason, the module’s current Java-level approach cannot capture Telegram story video while it is playing; addressing that specific case would require native/HAL-level handling (or explicit vendor support).
Screen_Recording_20251219_015127_Telegram.mp4
Logs
LSPosed_2025-12-19T02_13_44.455135.zip
logcat.txt
Framework, Services, and Screenshot App
Framework and Services
https://files.catbox.moe/xdm1ia.zip
Screenshot app - SystemUI
https://files.catbox.moe/gtihj7.zip