January 13, 2011
Oh, the first trouble is that Samsung drastically (?) restructured their
interceptKeyTq(). So a lot of what I thought I knew was wrong.
In particular, I missed the fact that it was branching around my
Log.d() in the !screenIsOn case! So maybe it does get called even when
the proximity sense is true.
One of the reasons this restructuring looks drastic is something
unusual the compiler does (either javac or the class->dex converter) for
if statements. For "if (x) { y } else { z } ..." most compilers I've
worked with much would generate:
if-eqz x, goto elselab
y
goto donelab
:elselab
z
:donelab
...
But I am seeing:
if-eqz x, goto elselab
y
:donelab
...
:elselab
z
goto donelab
Which is fine, but did you notice the "..." moved?! The
entire rest of the function has now been inserted in between y and z. So
the smali code occurs in a radically different order than the java code.
This is the sort of thing you may not notice if you are just reading the
smali code, but if you ever hold it side-by-side with the java code, you
start to get seriously spooked after a bit.
This seems sort of like a rational thing to do if you want to optimize
for the true condition. The "traditional" approach has 1 branch for true
and 1 branch for false, but this novel approach has 0 branches for true
and 2 branches for false. But that's a hell of an assumption.
Especially because in every other way this code shows no signs of even
reasonable peepholing. There is a ton of unnecessary copying that goes
on. And it's not just because most of the instructions can only access
the first 16 regs. Sometimes they copy from v4 to v0 for no reason, even
if the value is never used again (v4 is not live). So why this radical
assumption about if() statements?
Almost definitely this is the side effect of some innocent convenience
in a tree walk in the compiler, and is not "intentional"
at all, just provably correct and thus dismissably boring.
Anyways, it wouldn't sleep in the case where I wanted it to.
goToSleep() was being called and it was definitely getting into the meat
of goToSleepLocked(), but it wasn't sleeping. I found these in the log
that might be relevant:
D/PhoneApp( 1991): setScreenTimeout(MEDIUM)...
D/PhoneApp( 1991): PhoneAPP :: Update Wake Call : true
D/PhoneApp( 1991): requestWakeState(FULL)...
...
D/KeyguardViewMediator( 1928): doKeyguard: not showing because externally disabl
ed
...
D/CallNotifier( 1991): - still showing in-call screen; not releasing wake locks.
But it was sleeping when I didn't want it to -- it was setting
mShouldTurnOff... even when I was pressing the button to wake it from
sleep. Anyways, some bug fixing (change it to mShouldTurnOff=false if
keyguardActive), and PhoneWindowManager now works ideally. It even calls
endCall() and goToSleep() if I press the end while the phone is against
my cheek!
Of course, endCall() and goToSleep() both don't work in the
interesting cases.
The clue to why endCall isn't working is:
01-13 19:39:30.721 D/interceptKeyTq( 1929): calling endCall()
01-13 19:39:30.726 D/PhoneInterfaceManager( 2131): [PhoneIntfMgr] CMD_END_CALL: no call to hang up
Which is emitted whenever keyguardActive and screenIsOn are both false
(i.e., in a call with the screen off because of proximity) and I hit the
end call button.
PhoneInterfaceManager appears to work like in mainstream Android,
endCall() just calls sendRequest(CMD_END_CALL, null), which passes the
message to "MainThread", which I guess executes it in
PhoneInterfaceManager$MainThreadHandler.handleMessage(CMD_END_CALL).
However, that is where they diverge. It appears, in fact, that the only
change is they wrapped the meat of case CMD_END_CALL in a:
if (mApp.isScreenOn()) {
...
}
Leaving just the log() call that I am seeing that outputs
"CMD_END_CALL: no call to hang up" whenever I call endCall() while the
thing is close to my cheek.
Seems like an easy fix!
And it seems to work!
Now why does goToSleep() fail? It looks like this code is responsible:
boolean showingDisconnectedConnection =
PhoneUtils.hasDisconnectedConnections(phone) && isShowingCallScreen;
boolean keepScreenOn = isRinging || isDialing || showingDisconnectedConnection;
...
requestWakeState(keepScreenOn ? WakeState.FULL : WakeState.SLEEP);
Which seems pretty dumb to me. I explicitly hate the
disconnected-connection screen, as if my attention is needed to let me
know that my call has just ended but giving me the knowledge on that
screen isn't worth leaving the screen up for more than a couple seconds
(far fewer than 10).
But I'm not sure that tells me why the keyguard doesn't activate? I
think that requestWakeState() call is only responsible for cancelling the
screen power down that was in process. Maybe if the screen is allowed to
reach fully powered down, the keyguard will activate on its own? From
looking at PowerManagerService.java, it looks like that may be the
case. It sets mStillNeedSleepNotification in goToSleepLocked(), and then
tests it in setPowerState() to determine if it should alert the
locker.
Of course it looks like they made a few changes in updateWakeState().
But it looks like mostly how it implements keepScreenOn, not how it
calculates it. So I will just change it to require more than just
showingDisconnectedConnection to keepScreenOn.
Well, it seems to fail to activate the keyguard, symptom being that
the next time it turns on, it turns off immediately because
mShouldTurnOff is set to true because keyguardActive is false in
interceptKeyTq(). You know, this shows up in the log after the hang-up
that turns off the screen:
01-14 02:44:37.139 D/KeyguardViewMediator( 1927): doKeyguard: not showing because externally disabled
And it's a race case of some sort -- if I hold down the hang up button
for slightly longer (or something) then it "works", except that it takes
it a moment to visually get rid of the "showing disconnected connection"
screen. But it goes straight from there to keyguard.
PhoneApp.disableKeyguard()/reenableKeyguard() seems to be involved.
It looks like reenableKeyguard() is called from InCallScreen.onStop(),
which doesn't happen until after some lame stupid delay that is maximum
dumb. However, I observe that updateWakeState seems to always be called
in this condition, and seems to be called relatively early...at any rate,
it is called well before that "doKeyguard: not showing ..." message. So
if it is called and showingDisconnectedConnection is true then we can
probably just call reenableKeyguard() from there!
Indeed, that seems to work. Yay!
Mission accomplished! I can now hang up my phone and slip it into my
pocket with a single button push.
Okay, here is an infelicity. The call end button doesn't turn off the
screen when the keyguard is active, but really it should only refrain
from turning off the screen if the keyguard is displayed AND the screen
is off. If the screen is already on, it should still turn off the screen
regardless of keyguard. So instead of checking for keyguardActive to
disable mShouldTurnOff, it now checks for keyguardActive && !screenIsOn.
That way it will still mShouldTurnOff if the keyguard is inactive and the
screen is off (i.e., in a call touching my cheek).
Hmmm, but now it doesn't seem to sleep if I hang up while it is
against my cheek. It looks like it is getting into goToSleep() fine and
it has no reason it wouldn't go all the way through the meat of
goToSleepLocked(). Perhaps that meat winds up being a no-op if the
screen is already off? I think so long as I am in the process of pulling
the phone away from my head as I hit hangup, it should be fine.
*sigh* Something to chew on.
