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 workaround a race condition in the framework between // notification for orientation changed, layout() and switching resources. This code attempts // to avoid drawing the incorrect layout while things are in transition. The method can just // be removed once the race condition is fixed. See bugs 2262578 and 2292713 It has the view not to draw, when the view resource and layout is inconsistent with current setting. But however, it doesn't work in my platform(don't know why). I add some code to order it recreate the view for re-collecting resource and it works now. However, I've found another problem here. When I rotate the window (ctrl + f11 in emulator), the keyguard disappear... After dumping the debug message in the WindowManagerService for orientation (DEBUG_ORIENTATION), I found the keyguard is skipped for the orientation change redrawing because the app freezing is set. (I have no idea what it is@@) I think this may be solved in the bug referred in the above comment. Can someone tell me how to see the bug progress for a number? Thanks, Alonso On 12月21日, 下午1時29分, Hemanth <hemanth....@gmail.com> wrote: > 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 services/java/com/android/server/WindowManagerService.java; > You can enable: > DEBUG_LAYOUT and DEBUG_REORDER to get lots (insane amounts) of prints > related to the layout calculations. > It would be useful for debugging. > > (Maybe the guys over at android-developers might be able to help you > in more detail..) > > On Dec 21, 12:43 pm, Alonso Hu <chuanshen...@gmail.com> wrote: > > > > > 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 get the normal result as I > > want. > > > Is there any dependency about drawing? I'm using emulator now so it > > could not be hardware accelerator. > > The cause may be that some of my customized service is running so that > > some depended service is not ready for drawing which Android assumes > > it will execute in time. > > > Any idea? If you come up any hint, please provide me. Thanks!! > > > Alonso > > > On 12月21日, 上午8時53分, Alonso Hu <chuanshen...@gmail.com> wrote: > > > > 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} mClient=android.view.ViewRoot > > > $...@43d2ba00 > > > mAttrs=WM.LayoutParams{(0,0)(fillxfill) sim=#20 ty=2004 > > > fl=#10120800 fmt=-3 wanim=0x103006c or=5} > > > mBaseLayer=141000 mSubLayer=0 mAnimLayer=141000+0=141000 > > > mLastLayer=141000 > > > mSurface=Surface(native-token=3482880) > > > mToken=WindowToken{43d9f950 token=null} > > > mRootToken=WindowToken{43d9f950 token=null} > > > mViewVisibility=0x0 mLastHidden=false mHaveFrame=true > > > mObscured=false > > > Requested w=480 h=272 > > > mGivenContentInsets=[0,0][0,0] mGivenVisibleInsets=[0,0][0,0] > > > mShownFrame=[0,23][480,272] last=[0,23][480,272] > > > mFrame=[0,23][480,272] last=[0,23][480,272] > > > mContainingFrame=[0,23][480,272] mDisplayFrame=[0,23][480,272] > > > mContentFrame=[0,23][480,272] mVisibleFrame=[0,23][480,272] > > > mContentInsets=[0,0][0,0] last=[0,0][0,0] mVisibleInsets=[0,0] > > > [0,0] last=[0,0][0,0] > > > mDrawPending=false mCommitDrawPending=false mReadyToShow=false > > > mHasDrawn=true > > > > On the other hand, in fact I can see keyguard working normally, when I > > > click power button in app execution. > > > The disappearing problem only exists when booting. Therefore I > > > compared the window information of the keyguard at booting and at app > > > execution. The diff is as follows: (The left is at booting(abnormal), > > > the right is the other(normal) ) > > > > 1,2c1,2 > > > < Window #6 Window{43e09bd8 Keyguard paused=false}: > > > < mSession=Session{43dd8500 uid 1000} mClient=android.view.ViewRoot > > > $...@43d2ba00 > > > ---> Window #6 Window{43e067c8 Keyguard paused=false}: > > > > mSession=Session{43e9e1b0 uid 1000} > > > > mclient=android.view.viewroo...@43e7bff0 > > > > 5,7c5,7 > > > < mSurface=Surface(native-token=3482880) > > > < mToken=WindowToken{43d9f950 token=null} > > > < mRootToken=WindowToken{43d9f950 token=null} > > > ---> mSurface=Surface(native-token=2993848) > > > > mToken=WindowToken{43deea08 token=null} > > > > mRootToken=WindowToken{43deea08 token=null} > > > > 9c9 > > > < Requested w=480 h=272 > > > ---> Requested w=480 h=249 > > > > 17d16 > > > < > > > (our resolution is 480x272) > > > The only difference besides the id difference is the requested width > > > and height. Undoubtedly, the correct one with height 249 is right, > > > where the height of 23 is the status bar. > > > > Do you know how these values come from? In fact I found that the > > > computed layout parameters are all the same, but why the requested > > > size is differ from the computed one (from layout)? > > > > Please Help, thanks. > > > > Alonso > > > > On 12月20日, 下午10時52分, Hemanth <hemanth....@gmail.com> wrote: > > > > > 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 window token that you are > > > > interested in, in the same output (To see if it is really hidden). > > > > > <snip> > > > > : > > > > Application tokens in Z order: > > > > App #4: AppWindowToken{44bd6e30 token=HistoryRecord{44ae2d88 > > > > com.android.settings/.DevelopmentSettings}} > > > > App #3: AppWindowToken{44becb90 token=HistoryRecord{44a9bb18 > > > > com.android.settings/.ApplicationSettings}} > > > > App #2: AppWindowToken{44becd60 token=HistoryRecord{44beca80 > > > > com.android.settings/.Settings}} > > > > App #1: AppWindowToken{44b8c8a8 token=HistoryRecord{44b27e28 > > > > com.android.launcher/com.android.launcher2.Launcher}} > > > > App #0: AppWindowToken{44afc5a8 token=HistoryRecord{44afab70 > > > > com.android.setupwizard/.SetupWizardActivity}} > > > > : > > > > </snip> > > > > > I am not too sure about the details of the window drawing though, but > > > > I am sure someone else will be along. > > > > > On Dec 20, 5:24 pm, Alonso Hu <chuanshen...@gmail.com> wrote: > > > > > > Dear all, > > > > > I've just met a problem these days. When keyguard is started after > > > > > booting, I can't see anything at all. However, incredibly, when I drag > > > > > the unlock button upward (imaging where the position is), I can unlock > > > > > the screen. > > > > > > I have used the hierarchy viewer to see the view hierarchy, and see > > > > > the correct hierarchy of views of my keyguard view. According to this > > > > > and the correct behavior above, I believe the whole view is running > > > > > but invisible. > > > > > Of course I've checked the properties of the ought-to-be-visible > > > > > objects in the hierarchy viewer and I'm sure they're visible. > > > > > > I just wonder that how could this be?? Is there any hint that you > > > > > could provide me, please? > > > > > > On the other side, I'd like to discuss the drawing procedure in > > > > > Android. > > > > > > I'm tracing the code in windowManagerService and the policy of > > > > > PhoneWindowManager but confused about how it managed the drawing. > > > > > > 1. How does a view hierarchy draw? > > > > > Is that one view root has a individual surface and each one take the > > > > > responsibility to draw the whole view? > > > > > If it's true. Is that mean the cause of my problem is only a problem > > > > > inside the keyGuardViewManager? > > > > > > 2. What is the role of windowManagerService in drawing? > > > > > > Thanks for reading above all. Please provide me any possible hint if > > > > > you have. > > > > > > Alonso -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting