Issue #1275

Feature #1539: Graphics acceleration

Screen content (shortly) visible before unlocking

Added by My Self almost 4 years ago. Updated 25 days ago.

Target version:
Start date:
Due date:
% Done:




This bug-report is an result of of the forum-issue:, where some more details could be found.

  • Issue:
    The device automatically locks after the configured countdown-time (over settings).
    If the device will be activated again (by the buttons for example), the last screen content is shown for a short time (~ one second) before asking for the password (or PIN).
  • Suggestions:
    - Android screenshots functionality in context of the missing proprietary accelerated graphics drivers.
    - The framebuffer, which is only updated moments after the backlight goes up again.

Because this "is a bug that is worth fixing", I opened that ticket.


#1 Updated by Denis 'GNUtoo' Carikli over 3 years ago

  • Category changed from 51 to Framework
  • Device set to Not device specific

#2 Updated by Denis 'GNUtoo' Carikli over 3 years ago

  • Parent task set to #1539

#3 Updated by Paul Kocialkowski over 3 years ago

  • Category changed from Framework to Security
  • Device deleted (Not device specific)

#4 Updated by Wolfgang Wiedmeyer about 2 years ago

  • Assignee deleted (Paul Kocialkowski)
  • Target version changed from Any version to Replicant 6.0

#5 Updated by Jeremy Rand almost 2 years ago

Contrary to the note in , this bug also appears to affect Replicant 6.0 0001 when llvmpipe is in use.

#6 Updated by Jeremy Rand over 1 year ago

Paul said in :

Oh, I thought this was because the framebuffer is only updated moments after the backlight goes up again.

I'm pretty sure we have fully disabled the animations, so I'm not entirely sure it has to do with screenshots. I quick way to find out would be to write a black image to the framebuffer when the backlight is off and see if the previous screen still shows up or not.

Results: if I tap the power button on the i9300 to turn off the screen, and then tap it again to turn on the screen, I see the previous screen for a couple seconds before the lock screen. If I run the following over adb (as root) between turning off the screen and turning on the screen:

cat /dev/zero > /dev/graphics/fb0

Then the issue goes away; the screen stays black for slightly longer and then goes directly to the lock screen without showing the previously open screen.

#7 Updated by Kurtis Hanna 9 months ago

  • Target version changed from Replicant 6.0 to Replicant 6.0 0005

#8 Updated by Kurtis Hanna 9 months ago

Jeremy, can you think of a way to have this fixed for the 0005 release? It seems like you are on the right track.

#9 Updated by Fil Bergamo 9 months ago

My naive approach would be to find the exact point in the screenlock app where the screen is turned off, and just run

cat /dev/zero > /dev/graphics/fb0

right before turning it off.

But that would be a very hackish solution, and far from being an elegant one.

Another approach (more refined but still not perfect) could be to change the aforementioned code to display a black screen image before locking the screen...

#10 Updated by Kurtis Hanna 9 months ago

I compared stock Android with Replicant and noticed that on stock there's some sort of screen effect going on when you unlock the screen slowly gets brighter instead of going to full brightness right away. I then made the assumption that this effect seems to be broken in Replicant and instead of showing it, it shows the previous image for some reason.

It looks like is the program that I was noticing.

"Animates a screen transition from on to off or off to on by applying some GL transformations to a screenshot."

Here's the code that tries to do the screenshot:

private boolean captureScreenshotTextureAndSetViewport() {
if (!attachEglContext()) {
return false;

The code seems to not fail gracefully.

The reason why the screenshot image is kept by ColorFade after the screen fades to black is explained in the comments here: "To prevent stray photons from leaking out after the color fade has been turned off, it is a good idea to defer dismissing the animation until the color fade has been turned back on fully."

My logs show that gralloc complains that it registers "a buffer in the process that created it. This may cause memory ordering problems."

I think that this buffer is the screenshot. seems to be the code that controls the settings for ColorFade.

I could be wrong, but it looks like this code lets you choose to turn the screen off without doing any colorfade:

Since ColorFade doesn't work in Replicant anyways, maybe we should modify to tell it to not use ColorFade at all. The other option is to modify the ColorFade code so that it never takes the screenshot and puts it in the buffer.

Lastly, it should be noted that Joonas reported in the IRC that he got swiftshader to work with Replicant 6 and that it looks like this issue is resolved when using it.

#11 Updated by Kurtis Hanna 9 months ago

I found upstream patches for ColorFade that I think might fix this.

ColorFade: fix EGL crash on exynos4 mali blobs
Git Mail version:

This LineageOS patch may have used some of the code from this AOSP patch...

Remove ColorFade resouces when screen off

#12 Updated by Kurtis Hanna 8 months ago

The LineageOS patch named "ColorFade: fix EGL crash on exynos4 mali blobs" that I had found didn't fix this bug. Fil Bergamo told me in a conversation we had that he believes the fix should be a simple one now that we know what code needs to be altered.

Joonas confirmed that using Swiftshader with Replicant 6 not only fixes this bug, but it also makes it so screenshots work. He said that Swiftshader is quite slow though, so I'm still trying to fix this bug for people that use llvmpipe or the Android software renderer.

#13 Updated by Kurtis Hanna 8 months ago

If you go to this link:!search/%220001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch%22

Then if you click on the "Re: Android mesa-10.6 branch is ready for testing" text, you will get linked to an email where someone on the Android-x86 google group said, "To solve ColorFade problem (in fact a GLSL fragment shader which Mesa doesn't like that much) I have commented most of cmds used, keeping just gl_FragColor variable set in order to make it black".

They posted a patch named "0001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch" which, if we ported the patch to Replicant 6, would modify this portion of code:

#14 Updated by Fil Bergamo 5 months ago

Thank you for committing to this, Kurtis.

They posted a patch named "0001-Avoid-crashes-with-Suspendon-Lollipop-ColorFade.patch" which, if we ported the patch to Replicant 6, would modify this portion of code:

I've checked.. that patch is already applied in replicant.

git log -- core/res/res/raw/color_fade_frag.frag

inside frameworks/base, yields:

commit 24abb423c30dd3fa815154664bd59eb011f7c0e9
Author: Paulo Sergio Travaglia <>
Date:   Sun Jun 21 05:11:13 2015 -0300

    Avoid crashes with Suspendon Lollipop (ColorFade)

Indeed, the portions of code that the patch comments out, are commented in the replicant tree too..
My latest build still has the bug, so the patch doesn't solve the issue, unfortunately.

#15 Updated by Kurtis Hanna 5 months ago

I found this code which I think controls how many milliseconds colorfade appears on the screen:


I was thinking that maybe we could change the values to zero to see if it fixes the bug by not letting colorfade show anything on the screen at all.

I'm going to try to build Replicant from source again on a fresh install of Stretch, so maybe I will be able to test this and other patches out. Please feel free to test this patch idea out though if you are reading this as I can't promise that I'll be able to get Replicant to build.

#16 Updated by Denis 'GNUtoo' Carikli 2 months ago

  • Target version changed from Replicant 6.0 0005 to Replicant 6.0 0004

#17 Updated by Denis 'GNUtoo' Carikli 25 days ago

  • Target version changed from Replicant 6.0 0004 to Replicant 6.0 0005

Also available in: Atom PDF