Show keyboard on retry with PIN or password
Show correct message on cooldown
On return from emergency call, don't override cooldown
Don't show keyboard on return from emergency call if in cooldown
Show back functionality on emergency call
Change-Id: I5cc93cb09ad758b72521bd43cfad1040be2e5f8d
To enable marquee'ing, you have to call setSelected on the relevant control.
Comment added to explain this. Also see defect 15327172 filed against
SDK documentation to properly explain this.
Change-Id: If8f70baa1b682070b312fa689b2edd77b50d2d6e
Use TelephonyManager instead of ITelephony for showCallScreen so that
the invocation routed to telecomm instead.
Bug: 15008165
Change-Id: Ib674e2e48efaa1cc97d1513dc2c2b27fdb343657
On power fail/reset, an encrypted device will sit at the enter password screen
indefinitely, chirping. This is designed to attract the attention of the user.
However, it also flattens the battery, and the user who's attention is not
drawn will discover a discharged phone the next morning. We have had many
complaints about this.
Keep current functionality, but power down after 10 minutes. It's a compromise,
but seems reasonable.
@bug 12582489
Change-Id: I895c0147bed978ecf6984af2c748f971dfa0d221
Messaging currently implies encryption only works with PIN or password
(K functionality). Now that in L we support encryption with PIN, pattern,
password or swipe/none, we need to update the strings accordingly.
@bug 14257692
@bug 13674657
Change-Id: I055db1289c2c2750d217b50b653a7f36ff304aca
We need to disable pattern control when in cooldown. We also need
to hide the back button completely in pattern mode.
Bug: 13329798
Change-Id: Idefea60d95db1810d340c69cc730a286011363db
Use plumbing provided by dependant change to bring up correct dialog
at boot time.
Needs matching framework changes from
https://googleplex-android-review.googlesource.com/#/c/412885/
Bug: 8769627
Change-Id: Ib04a2875e051a7cccca035fadb25978dfec22491
The fix in Change Ifbe4cdf40e3b76d2069ecace940f85fa58f31187 causes
keyguard to be more aggressive about showing itself.
CryptKeeper itself should explicitly dismiss keyguard.
Fixes bug 11680832
Change-Id: I87287762b73bdffc6f1800379f02f70f4bd873a8
Fix b/6531158 (Stop showing the keyboard)
Fix b/6532201 (Stop removing the text view, and prompt the user with a message)
Fix b/6155075 (Stop listening to MCC/MNC changes)
Change-Id: Ibf8414fe57bdd0acf6c20f3194c52b168b9292c6
1. Center the clock on Xoom and large tablets. Fix b/5579000
2. Correctly remove the emergency call button if the device (*cough*
Nakasi *cough*) does not have telephone capability.
Change-Id: Ib7552dc35392a1b9d6c0381c6167949e2b163ddc
Justification: Most users will not need prompting, so for them a
notification will be an annoyance. So we only notify if the no
password has been entered for 30 seconds.
Once a notification sound is made, we need to make it frequently so
the user can locate the device.
Change-Id: Ibf531aec89b5e3b3c72eaa36016bcc4cac1d6493
1. Disable back presses from physical keyboard during encryption: Fix b/6139810
2. Keep screen on when waiting for password. Fix b/6153213 and b/6149606
3. Alert the user with sound when waiting for password. Fix b/6149606
4. Add debugging feature to display the password screen without having to reboot the device.
Change-Id: I588aa7d96e1140f95a6fa91e0281117907f666f7
With the corresponding change for the activity manager to allow the home
activity to finish itself, this activity can now be a little less dirty
and just call finish() when it finds it is not needed.
Change-Id: I1a449c7bec9fba659e27a9e918f8a9b0c55b2098
Add a hack to relaunch whatever was supposed to be launched
(presumably home) when CryptKeeper discovers it shouldn't be
running.
Change-Id: I1406b8d6e8d484ed1c169fa4908a9e05e8c7c2ad
We were attempting to unconditionally validate the encryption state on
CryptKeeper bringup, which required MountService to talk to vold. For
some reason, during encryption, this cannot happen, and that call never
returns, so the CryptKeeper UI was never brought up.
Bug: 5276690
Change-Id: I6a146e25e24f4efd760b0afa1e1409bf9ea3e9c3
- use standard IME, but force it into ASCII if it's the default IME
- provide an IME switcher if there are multiple IME's, in case the
ASCII-capable one is a different one
- make the IME shown by default
Bug: 5004456
Bug: 4698473
Change-Id: Id40a164cfe599bfdb67b81f60d4ab8a52208de88
Also add in logging for certain events, as well as progress update to
help hunt down a stuck-in-progress bug
Bug: 5163155
Change-Id: I2e01a56b012f41f178beba0becfbe8173a1715ee
- prevents crash when trying to show error state
- makes progress screen not look horribly broken
Bug: 5174783
Bug: 4671153
Change-Id: Ia72830e2fdb72f174b3ed01b6fc14be7152d1932
This allows you to make an emergency call without needing to decrypt
your device first.
The exact appearance of the button, and the two possible icons shown to
the left of the text, are taken directly from the corresponding
framework resources (see keyguard_screen_*.xml, ic_emergency.png, and
stat_sys_phone_call.png.)
Also, the code in CryptKeeper.java for updating the state of, and
handling clicks from, the "Emergency call" button is mostly duplicated
from the corresponding code in LockPatternUtils and
LockPatternKeyguardView under frameworks/base.
Bug: 4494186
Change-Id: I36a713fdbc3281a7ba46762d47d5b61fb3cd194d
Move the decrypt attempt to a AsyncTask. This will
unblock the UI thread in order for the device to
still be "responsive". There is still the issue of
decrypt taking 3+ seconds before it returns to. The
delay is still there becfore the fade but the text
field is now cleared and you can tap on keys.
Bug: 3495575
Change-Id: Icec82e83d3a09b3c0f856aa77870925fc8469625
