In the past android:customTokens=true authenticators were required to handle
their own token caching. This is detrimental for battery when high traffic
authenticators are constantly spinning up processes to start services to do
file io to check their own caches. This change allows authenticator
implementers to optionally let the framework do some of the work for them by
providing the framework with a expiration time.
The AccountManagerService will make a best effort to re-use the cached
token if possible.
Bug: 21530782
Change-Id: I16a7edba36a220e3891e55cf61c725c2be863323
Currently we treat a lease time larger than 2**31-1 as a negative
value, which causes DhcpClient to attempt to renew its IP address
constantly. Fix this by properly handling large and infinite
lifetimes, and while we're at it, impose a minimum lease time of
60 seconds.
Bug: 21352084
Change-Id: If62c9efeffad6222e2fe0c110f77d0e4c70de96d
This is a 2nd trial of I20ae2749a which is reverted due to a regression.
The goals of this CL are two:
- Split setImeWindowStatus method into two: keeping IMS status and
updating system UI e.g. NavBar icon state.
- Hide software keyboard based on a realistic IMS status.
IMMS#mImeWindowVis has been used for two purpose, keeping IMS status and
updating the NavBar icons, e.g. keyboard icon.
However, to update NavBar icon, sometimes IMMS#mImeWindowVis value is
updated without any notification from IMS. As the result, the status
value becomes incosistent with the real IMS state.
This patch extracts NavBar update logic into separate method and keeps
IMMS#mImeWindowVis as notified status. Then, use it for hiding software
input correctly in IMMS#hideCurrentInputLocked.
This CL also removes refreshImeWindowVisibilityLocked method including
workaround for fixing Bug 11186297. That issue is no longer
reproducible with latest lock screen and almost no effect for existing
users and developers. So simply remove them in this CL.
BUG: 21446788
BUG: 20764441
BUG: 18722991
Change-Id: I33dc6278fd892f26e56352722bf9449b8b102030
The current message does not provide enough
information to figure out what is going on.
Bug: http://b/8076853
Change-Id: I741781ce6829eac44e4edddd0a545f3be743ceeb
It is possible lockTaskMode was started by the system process
because android:lockTaskMode is set to a locking value in the
application's manifest instead of the app calling
startLockTaskMode. In this case TaskRecord.mLockTaskUid will
be 0, so we compare the callingUid to the
TaskRecord.effectiveUid instead so the app can exit lockTaskMode.
Bug: 21464182
Change-Id: Ibca6de8e4b17051d5fcbb05cde9c8aefed7216f2
- Add explicit user setup signal to status bar icon policy.
- Include per-user next alarm clock info in service dump.
Bug: 21551365
Change-Id: Ib16636522bbe04d205a377567007145f146e9d39
If user sets a non-secure lock screen, launch an activity which
appends window flag FLAG_DISMISS_KEYGUARD, then insert a PIN lock
SIM card, activity window will become black screen.
This is because mDismissKeyguard keeps on DISMISS_KEYGUARD_CONTINUE
when keyguard secure changes from non-secure to secure like in the
insert PIN lock SIM card case. If mDismissKeyguard is
DISMISS_KEYGUARD_CONTINUE and keyguard is secure, there is no chance
to launch keyguard unlock window anymore.
This patch handles the use case that to reset mDismissKeyguard to a
new cycle from DISMISS_KEYGUARD_START to DISMISS_KEYGUARD_CONTINUE
again once keyguard secure state change suddenly to let keyguard
window has chance to be launched.
https://code.google.com/p/android/issues/detail?id=78806
Change-Id: I0d4fd0b9bdf7d0a39f35427bfd4e1b928d9bca6b
Signed-off-by: tingna_sung <tingna_sung@htc.com>
Conflicts:
policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
Just above the SecurityException is a check for r.record == null,
thus dereferencing r.record will cause a null pointer exception.
Found in Android 4.3 with the following steps:
1) Start the music app.
2) Switch to the restricted user.
3) Navigate to Settings->Apps->Running->Music.
4) Tap the stop button.
The security exception should be thrown which results in
a nice message to the user, but instead a null pointer
exception is thrown which results in the settings app
crashing.
Change-Id: I4a306c38650c9d366896e592767dde70adb71c57
WindowManagerService received X and Y offset steps but failed to pass
them off to the relavent wallpaperservice.
Live wallpapers expect a valid value for xOffsetStep and yOffsetStep
when the WallpaperService.Engine::onOffsetsChanged function is called
As specified here:
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine.html
onOffsetsChanged(float,float, float, float, int, int)
See bug report:
https://code.google.com/p/android/issues/detail?id=173607
Change-Id: I532dedf2db055e27d6eca813e30346e37f52dc65
(cherry picked from commit e03ea68d0a7f7d7c60663feae587225cca3a3a5b)
We now try to perform key/value backups only while charging, proceeding
off-charger only after we've waited a full day for the device to be
plugged in.
Bug 21076663
Change-Id: Ib32c9f8bfaf8a310f5f388907e38a28d3c54bd8e
Before, Keyguard was shown whenever PhoneWindowManager went to sleep.
However, this was too early on some devices, and too late on others.
Now, the callbacks are split up into two phases: startedGoingToSleep
and finishedGoingToSleep. In the first callback, we decide what to
do and play the lock sound if necessary. In the second callback, we
actually show the Keyguard, or reset its state necessary, so it
doesn't interfere with the screen off animation.
Bug: 17929748
Bug: 20782303
Change-Id: I4c4406595b07b7589d64f380cd3fa96bed3d20ee
Added some new callbacks that can be used to more precisely trigger
certain behaviors that need to happen around the time the device
is put to sleep and locked.
Fixed an issue where the going to sleep signal might be sent too
early on devices that don't support ambient mode due to the extra
wakefulness change between DOZING and ASLEEP. We are now track
the early / late interactive change work separately from the rest.
Bug: 21375811
Change-Id: I95387195e216ae92a6e45485bd1bd362e41aa45a
Previously, the logic for keeping occluded mode during transitions
would also trigger when transitioning from the lockscreen to a
SHOW_WHEN_LOCKED activity that was already on-screen, which would
then prematurely clear the occluded mode and break the launch
transition.
With the fix, the lockscreen must already be occluded before the
keep-occluded-during-transitions logic is triggered.
Bug: 21525170
Change-Id: I1d9ad95b2dd0728af7986f09adb67a617cc62cb2
b/21516868
This change makes AGpsStatus_v3 consistent and compatible with the behavior
of AGpsStatus_v2.
Change-Id: Ia4e729d8ed1d61b51ae22c7eaf9bbe33f31b7a45
Emit log whenever the mode changes, or periodically to catch devices that stay
in one mode for long stretches of time.
Bug: 20264417
Change-Id: I4efde180eef23c2afc34c6c2e78ef4d0b6c5b675
In the case of moves, we can use the existing ABIs from settings because
a move will not result in an ABI change. For new installs, we can just
use the ABI we deduced for compiling (dex2oat) the package.
bug: 21144503
Change-Id: I35e2e8abd47f547b6252271fc6b41d30719c4298
- Migrate the existing calendar attribute in the event condition
from a long calendar id to the calendar account name. More
portable across a backup/restore.
- Also skip restoring transient state (like the current condition
state) from restored automatic rules.
Bug: 17755700
Change-Id: I9bdb421d2209e3ce90873008665c254d67c788d2
The comparator used variable "when" in IncreasingTimeOrder class.
variable "when" means "elapsed time" or "real time"(RTC) and these types have different unit of time.
so, I recommend that you use a "whenElapsed" which has the equal unit of time as its default value.
Signed-off-by: Jinho Park <jinho.park@lge.com>
Cherry-pick from master
Change-Id: Ib95531bf235e8fc628a7eda1c24d187c12a9ab3b
