| bf08af3323117e15a65b74e66b7499d31537f9e1 |
|
17-May-2012 |
Craig Mautner <cmautner@google.com> |
Eliminate deferred surface destruction.
Removing the code that delays a surface destruction when
WindowManager.FLAG_KEEP_SURFACE_WHILE_ANIMATING is set. The lock
screen that continued to animate after destroySurfaceLocked is no
longer used and this code was causing problems.
Also mDrawState was being set to NO_SURFACE in destroySurfaceLocked
even if the surface ended up not being destroyed. Later when it was
reused the false value of mDrawState was messing things up.
The screen lock bug referenced below no longer levaes the user stuck
with a black lockscreen. However it occasionally powers back up in the
launcher screen rather than the lock screen.
Fixes bug 6485955.
Change-Id: I684104c7e7c39c161a5118aa890889fbae92e635
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 354619c1cc1b4668c81c5368b2256335cc9e8538 |
|
28-Apr-2012 |
Jim Miller <jaggies@google.com> |
Fix 6397736: Swipe up to search layout fixes
This fixes several layout issues on phones and tablets with MultiWaveView.
It adds a new background scrim to be shown behind the MultiWaveView
on the navigation bar.
MultiWaveView is updated to handle gravity constraints which makes layouts
much more flexible across devices.
Change-Id: I64068f4eaa81ef6c464247049117d53432fcacbd
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| fbc46dc3c2be5f89041d9e4d3447bc65d303d43a |
|
02-Mar-2012 |
Jim Miller <jaggies@google.com> |
Fix 6028595: Fix reboot loop in AccountUnlock due to null callback
This fixes a bug where the device would get into a reboot loop due to having
a null callback. The problem was that a recent change caused the callback
to be used indirectly by the constructor before being set.
The solution is to pass the callback to the KeyguardViewBase constructor
which ensures it's ready by the time we call getCallback().
Change-Id: I2598fc5338be99977980e4dea41a096fb2a7ef7e
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| ee4d45f3052c8d339035c4bb8eca9b7a724e5074 |
|
13-Dec-2011 |
Dianne Hackborn <hackbod@google.com> |
am 0be53567: am 19a06fe9: Merge "Fix issue #5755172: Soft menu key disappears when menu is open" into ics-mr1
* commit '0be53567c1c2299c548d3204d2b9240108fbd53a':
Fix issue #5755172: Soft menu key disappears when menu is open
|
| 73ab6a49db2b834ce1d56c7a1164938b409ee6fc |
|
13-Dec-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5755172: Soft menu key disappears when menu is open
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 229574c7f5fad24a8240270db29fa6532256bb52 |
|
14-Nov-2011 |
Steven Ross <stross@google.com> |
Making KeyguardView slippery fixes 5501105
Setting the slippery flag keeps this window from processing
events occurring in places where another window is on top of it.
Specifically, if someone clicks above the pattern/FaceUnlock portion
of the window and then drags down onto FUL, this blocks the
underlying lockscreen from processing those touch events.
Change-Id: Ia7038841df0044f66220af8a00c7845b2293c2a4
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 305c78cce649056643641c51f12f2b6d2eb839f3 |
|
16-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5466678: use new setSystemUiVisibility() API to enable clock in statusbar
This fixes a bug where the clock wasn't being shown in the statusbar while
the music widget is showing.
Change-Id: Ic1c52c4ab7fa1490fe14ddafaf2c494bcf51866d
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| dba935659024a9ca83cb6bd3f1a9970e277f7658 |
|
06-Oct-2011 |
Daniel Sandler <dsandler@android.com> |
Break apart DISABLE_HOME and DISABLE_RECENT.
Additionally, start using setSystemUiVisibility() where
possible in the keyguard to allow activities and dialogs to
re-enable some of the navigation keys (notably: home but not
recents).
Finally, stop disabling MENU for activities atop the keyguard.
Bug: 5380495 // no home in driveabout, clock
Bug: 5396134 // able to show home/recent in keyguard
Change-Id: I04eb224554ee8cff79476b85148c4cda75bb0b62
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 4284e9d19a3f917b85e5eac4d6e304fc9b866139 |
|
28-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Pulled out part of onScreenTurnedOn() into show() function
The onScreenTurnedOn() function in LockPatternKeyguardView was
actually being called in two cases - when the screen was turned on,
AND when the show() function was called in KeyguardViewManager, which
actually happens just before the screen is turned off. Face Unlock
functionality was added to the onScreenTurnedOn() function, not
expecting that the function was also being called just before the
screen turns off. This causes Face Unlock to run when the screen is
turned off, preventing it from running when the screen is turned on.
This was not obvious during testing because it's not a problem when
testing from the lock screen. To reproduce the problem you must log
in successfully, then turn the screen off, wait, and turn it back on.
The solution was to pull the non-face unlock functionality from
onScreenTurnedOn() into its own function called show(), which is
called from the KeyguardViewManager show() function and also called
from onScreenTurnedOn(). In this way, the onScreenTurnedOn()
functionality is not changed, but the show() function can be used
for the onScreenTurnedOn() functionality minus the Face Unlock stuff.
One exception to note - I left setting mScreenOn inside of
onScreenTurnedOn() and didn't pull it into show()...that seems like
the correct thing to do.
Change-Id: I9dcc144c7842112c4d35eb3f8b4ab1cd42c05675
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 267cb2b284626f910cf64352bfc494d0f8d3dc42 |
|
26-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5323545 - FaceLock no longer appears when taking a call
Prior to this fix if the screen was off and a call was received, the
onScreenTurnedOn() callback would bring up the FaceLock service,
which would cover the phone interface. It now requires the call state
to be CALL_STATE_IDLE to start FaceLock. When the phone interface
closes, the user is left at the backup lock screen. Bringing FaceLock
up after a call ends does not seem like the correct thing to do.
While working near the FaceLock callback code, the sleepDevice()
callback was removed because it is no longer used (Fix 5327896).
Some cleanup was also done with regards to KeyguardViewManager.
FaceLock calls were being made from the KeyguardViewManager in
onScreenTurnedOn() and onScreenTurnedOff() via an interface to
LockPatternKeyguardView. This level of indirection was removed
because it can just be handled inside of the corresponding calls
in LockPatternKeyguardView. Likewise the FaceLock functionality
inside of hide() in KeyguardViewManager is now in
onDetachedFromWindow() in LockPatternKeyguardView. Overall this
is much cleaner, especially considering interfacing through
KeyguardViewBase was a bit of a hack.
Patch Set 2:
- Now using KeyguardUpdateMonitor to get phone state
- Removed unnecessary wrapper functions for hiding / viewing
FaceLock area
- These were really only there because at one point I was calling
them from KeyguardViewManager and the naming was confusing
- Removed if(DEBUG) from a couple of log messages that are actually
warnings that shouldn't show up and I want to know if they happen
even if I don't have DEBUG set to true
Change-Id: Id7befc47dd421156ff6cdb3aaf62fc76fe9cfad2
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 38e29a61d0c87fe3e391d24e2eb11dd1800d107d |
|
18-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5242779: Device not responding to touch on unlock screen
Rework how we decide when it is okay to turn on the screen by having
the policy call back to the power manager when it knows the lock screen
has been drawn.
Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 56bacd76b2e8caaad6be933ceb7168e046f7253e |
|
09-Sep-2011 |
Jim Miller <jaggies@google.com> |
Allow lockscreen orientation to be overridden with a system property.
There are cases where lockscreen changes orientation (when docked, etc.),
but it's not easy to test. This allows lockscreen's behavior to be
overridden by command-line.
Change-Id: I7ce1e2ca0ea03a9034a6f537e33650e99e3594d8
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 15ea55a6f1ae44ca63da158e3539903d77433988 |
|
09-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Moved FaceLock bind/unbind calls inside of null check
- I am not sure under what circumstances mKeyguardView can be null in
onScreenTurnedOn() and I never saw this behavior before the commit,
but it can happen and prevent the device from booting
- Patched to fix line length
Change-Id: I39efa5c1d68158af5c108430036fe7c715ef855b
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 6edf2637e96139735df83907c221cce16d4d7eaa |
|
06-Sep-2011 |
Jim Miller <jaggies@google.com> |
Fix 5185505: Add support for weak biometric sensors to lockscreen.
Added binder interfaces to the framework.
Change-Id: I7d55b45baa4d1600ebd2a3828e85c3357cfcfb58
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 5d927c2d8e832fcfcb0154c8741f896001141ef4 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5150899: Call activity takes 15MB we never get back.
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| b375632c9cf7b7be9309ff55f602499d59cfa597 |
|
12-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Don't use HW accel drawing in lock screen on lower-end devices.
This saves about 8MB in the system process because we don't need
to do HW accelerated drawing there anymore.
Change-Id: Ieaf72fe772536e12d10cf129d9338ca9fce6a6d4
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| f3447351f7571b5ab3c2a59832d9497bde4f6776 |
|
07-Aug-2011 |
Jim Miller <jaggies@google.com> |
Fix 5125978: remove lockscreen logspew
Change-Id: Iefa103e867e870dfe587271e0555404589d9e5b3
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 6b05d58018c2806459c121e507c005639b74aee9 |
|
18-Jul-2011 |
Jim Miller <jaggies@google.com> |
Fix 5044158: Initial pass: add music transport controls to LockScreen
Refactored all lockscreen notifications to go through new KeyguardStatusViewManager.
This is required to intercept messages originally intended for separate TextViews that
are now shown in a single view when showing the transport control view.
Refactor EmergencyCallButton to be handled by common code in KeyguardStatusViewManager.
First pass at LockScreenWidgetCallback for LockScreen "widgets" to send events back to LockScreen.
First pass at LockScreenWidgetInterface, which will be required of Views that want to be rendered on
LockScreen.
Added place-holder TransportControlView until the real one is ready and integrated it into GridLayouts.
Ensured emergencyCallButton is in all views, even if not shown since some devices may lock the user
out if certain criteria isn't met (missing SIM, etc).
Refactored layouts and removed keyguard_screen_status*.xml since layouts are all over the map and
no longer make good use of a shared layout for this.
Minor tweak to MultiWaveView to fix layout issues when placed in GridLayout where the measurement
was being calculated improperly.
Moved EmergencyCallButton to bottom of view where we can.
Removed unused Alpha keyboards from tablet password unlock layouts.
Removed unused views (status2, emergencyCallText screenLocked) from layouts and made common views have common names.
Fixed bug with MultiWave layout in landscape where array was shown in wrong orientation.
Separated clock colors for phones/tablets since they're now different.
Converted remaining phone layouts to use GridLayout.
Start routing audiomanager events to lockscreen views.
Move emergency call button handling to KeyguardStatusViewManager.
Change-Id: I480b0346cfe19aad316fea0c0aaabf8862693636
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 06cc78a4e3126703cae88dbc969974267b9f2c94 |
|
03-Jun-2011 |
Jim Miller <jaggies@google.com> |
Fix 4518876: Disable lock screen rotation on phones.
This reverts commit e28016c28620f070a6737c7fd536437e7b116f84
that enabled lockscreen rotation always and works around a
race condition caused by KeyguardViewManager not following
onConfigurationChanged events. It now checks
R.bool.config_enableLockScreenRotation each time it is shown.
There's still some work to be done, but this change makes the
phone usable. KeyguardViewManager needs to track config
changes and update the layout parameters to be correct.
Change-Id: I7c9f2402c960d5bd72a4b73118a66e27a05777cf
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 3fa8a454f61c772036f5f38661d1a077fd3d8388 |
|
10-Mar-2011 |
Jim Miller <jaggies@google.com> |
Fix 3201849: Enable hardware acceleration in LockScreen WaveView
Change-Id: Id64e82fe2e09ac231736d7867cd47b504d79b81b
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 56194ebec6212e229f4ccdaa4b187166d20013ef |
|
03-Mar-2011 |
Jeff Brown <jeffbrown@google.com> |
Wake screen from external HID peripherals.
Added some plumbing to enable the policy to intercept motion
events when the screen is off to handle wakeup if needed.
Added a basic concept of an external device to limit the scope
of the wakeup policy to external devices only. The wakeup policy
for internal devices should be based on explicit rules such as
policy flags in key layout files.
Moved isTouchEvent to native.
Ensure the dispatcher sends the right event type to userActivity
for non-touch pointer events like HOVER_MOVE and SCROLL.
Bug: 3193114
Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| b70d39fda198a2f6d37fec9bbdb67462df9de40c |
|
18-Jan-2011 |
Jim Miller <jaggies@google.com> |
am 6e3212a3: Merge "Fix 3329600: Always enable screen rotation in lockscreen." into honeycomb
* commit '6e3212a38b503e35563ec93c35a6851c99d95c77':
Fix 3329600: Always enable screen rotation in lockscreen.
|
| e28016c28620f070a6737c7fd536437e7b116f84 |
|
18-Jan-2011 |
Jim Miller <jaggies@google.com> |
Fix 3329600: Always enable screen rotation in lockscreen.
Sometimes we get the wrong value for the sensor resource we
use to configure lockscreen orientation. However, the current
UI design has LockScreen always respond to orientation (when
enabled in settings) so we don't need to rely on this for the time-being.
Change-Id: If37314befd25a7b3306500643155523ad4fe6657
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 3530ebe451fea39b159baa9b8c9f9cd851de42a3 |
|
17-Jan-2011 |
Jim Miller <jaggies@google.com> |
resolved conflicts for merge of 578e73da to honeycomb-plus-aosp
Change-Id: I334ae5382220a84881521885b6e3c3991fd8bbb0
|
| 8b886fab5496b0b1f5193f21855220176deddc37 |
|
14-Jan-2011 |
Jim Miller <jaggies@google.com> |
Fix 3106227: use WeakReferences for receivers in DigitalClock class
This works around a bug in the framework where LockScreen wouldn't
get GC'd under certain circumstances which would lead to an OOM
crash. It now uses WeakReferences for observers inside the
DigitalClock container class and unregisters them if the containing
DigitalClock goes away.
Also removed mLive variable which was unused and could potentially
leak the receivers.
Left mAttached for debugging so we can use it to determine if the
calls to onAttachToWindow() and onDetachFromWindow() are grossly
unbalanced which may be the root cause of the original problem.
Have cleanUp() explicitly clear unused references to make
tracing through hprof references easier.
Change-Id: I99a7e0c356001b05eab5aa729564553666febfea
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| 8171b5182f5f07d33c9dfdf2dd8f0f6ae9588039 |
|
05-Aug-2010 |
Jae Yong Sung <jysung@google.com> |
lock screen for xlarge
Change-Id: Iab9f53609bf24be774752a9960aaaa654d7a614f
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|
| be81f4f15dad6d690efcab1973d1e174ce3b001b |
|
15-Jun-2010 |
Brett Chabot <brettchabot@android.com> |
Move out all framework-tests classes.
Previously tests/framework-tests contained a quarantined set of test classes
that needed access to package-private framework api. Running these tests
normally would cause the dalvik verifier to throw errors.
runtest now has support for turning off the dalvik verifier for frameworks
tests, so move this tests into their recommended location, close to the source
being tested.
Also move policy source into a 'src' folder to accommodate the tests move.
Change-Id: I62f839da185a55bc553b653bf583fd99da438512
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewManager.java
|