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
