Seriously, don't look at this. It is so dumb.
Brought up by issue #17307700: retarget a relinquished
task is not working
Change-Id: I947438d3502f75510e2974211bb78d31008eaa90
- Don't run the local address allocation in the case of TV and the removed event.
- Let isTvDevice() return the value based on mLocalDevices, since tv() is
unstable during the intialization period.
Bug: 17601460
Change-Id: Ic5701f1f86f51171960033bd97e169270a0021bf
There exists a lifecycle regression where launching an
app from the lockscreen (camera, etc.) causes a series
of onResume, onPause, onRestart, onStart, onResume.
This CL reverts the behavior to what it was in KK, which
is to say that the Launcher is first resumed/paused, then
the Activity being launched has a simple onRestart,onStart, onResume
lifecycle.
Bug:17459745
Change-Id: I04091d2f86a929ee972c8d6debc1beb033c135a8
Decouple events from alarms in the zen interception function,
and default the new allowEvents to true.
Bug:17580878
Change-Id: Iff10df385206ad73c3423ff118c79e94a10918d9
There was some code here locking on the lock object instead of
the main activity manager lock...!!!
Change-Id: Ic85151fbef915f6fb8fd5ce3c1a7e9b810412cb6
Try to catch any cases where we remove a ProcessRecord from the LRU
list when it may still have a process associated with it, report
that this happened, and try to make sure the process is killed.
Change-Id: Icd74439caba5e1c283c01a49a46dae926a00ba71
After device bootup, the signal strength triangle is empty although there is
both voice and data connection. This is due to when TelephonyRegistry doing call
back listen register, some APP use mDefaultSubID. However, when the reigister
happen, the mDefaultSubId does not exist. Althouhgh it can be update later, if
the update event comes too late (especially after the steady state), no
ServiceStatechange event can be received anymore. Thus the service is always not
available and the signal stength trangle has no chance to be updated anymore.
This is a risk condition.
Bug:17472622
Change-Id: I772d29e6dd9da212b78fd0d4438b8273e3318dba
This turns out to happen a lot in normal usage, but we're logging
copiously about it each time. It's reporting "oh hey we're already
in this state" -- and so the log is not useful anyway.
Logspam is spam.
Bug 15169507
Change-Id: Ie2d01ff1b0b3600dd9c15ccf83d60875558f1dc2
...due to dying renderer process
Don't kill processes if they are bound to a service but not impacting
oom adjustment.
Change-Id: I1cc44e633feaeaad6e996b79a6cfd7b386c04095
Since we're reusing the cast tile for screen sharing we need to make sure there's only ever one
mirroring presentation going on at a time.
Bug: 9905068
Change-Id: I249932d0f8853880dd453eb57c2a258e6ae952b0
This allows us to ensure windows are fully drawn before unblocking
screen on while dozing.
Bug: 17516245
Change-Id: Ibe63c212b8db855ce26a34a8169f33764b266ee6
The screen on blocker is used to keep the screen blank while the
system is drawing new content to prevent the user from seeing a
flash of stale content while the screen is being turned on.
This patch ensures that the screen on blocker functionality
is also applied while dozing.
Bug: 17516245
Change-Id: I77c2d0f2b99476a59ad212099f44c63aa2ef9c34
Very useful for testing persisting/restoring, to make sure
that all pending changes have been written.
Change-Id: I0e3b7cd3af8afb0b6e751e086081566ab00b76c9
The PacManager would clear the pac url by setting it to null, however
everywhere else, pac url is cleared to Uri.EMPTY. This sometimes leads
to an NPE when PAC is set and cleared rapidly and take down the whole
framework.
Bug: 17581527
Change-Id: I84ce215f4f6a8a7e804372fc0a1e20ac609a21f1
Recently we started letting system apps always take precedence over
third-party apps when defining permissions. This change fixes that
logic to claim the permission immediately, instead of delaying until
after the next reboot. (Permissions are always reevaluated after
each install.)
We also tighten the constraints slightly to prevent two system
apps from fighting over a permission definition; the first system
app to claim the permission wins.
Bug: 17526617
Change-Id: I49686407f5e99322bc511795c653c5d702becd9d
Recently we relaxed revokeUriPermission() to allow apps to revoke
Uri permissions that had been granted to them, but this uncovered
bugs in apps that had been relying on the previous no-op behavior.
To mitigate this, only revoke ownerless Uri permissions when in the
unprivileged state; an active owner indicates that another component
of the calling app still needs the permission.
Bug: 17554268
Change-Id: Icc412933b29041ffb699d20136a623440ecc71ec
When services call Service.stopForeground(), remove
FLAG_FOREGROUND_SERVICE from the notification that was supplied
to Service.startForeground().
This enables services to post notifications that become user
dismissable when they switch to being a background service.
Restrict this to targetSdk=L apps to reduce the risk of breaking
existing apps.
Bug: 17551106
Change-Id: Iff8541e5bb2a23ad1fbc9ad80df5fd6eb683148b
...to the primary user, even if it was not whitelisted to be forwarded.
The path where getActivityInfo is called for the ResolverActivity
would not correctly apply the requested user ID to the result, so
it wouldn't run under the correct user.
Change-Id: I1da47c54bbed26091832a28236d0b06762c92437
