Hi all,
I've found the main cause of this problem.
It's because of orientation change inconsistency. The layout of
keyguard is decided before the orientation is set.
There is a workaround written for the race condition. It describe as:
// TODO:
// This overloaded method was added to
Hi,
You could try taking a bugreport/dumpsys window, which dumps the
window manager service information.
The z-order listing should be useful to see if the window is actually
added.
Something like below (Where we see that DevelopmentSettings is at the
top).
You can also see the properties of the
Thanks for replying.
After I execute dumpsys, it seems that it works normally.
Since the keyguard is not a application at all, I can see the
information in the window information, like below:
Window #6 Window{43e09bd8 Keyguard paused=false}:
mSession=Session{43dd8500 uid 1000}
Hi all,
Reply for my post. For now I don't think it would be caused by any
problem about layout.
I find a workaround, that is to delay the keyguard execution (addview
in windowmanager).
I think it may be like race condition. What I've changed is just to
delay the execution for one second, and
Hi,
It is good that you have a workaround in place!
It is does seem unlikely to be a problem in layout, since it shows up
correctly sometimes.
It could be related to the timing of the layout as you say.
How about using invalidate() on the view after adding?
In
