User visible behavior is supposed to be identical with and
without this CL.
Previously, there is some corner cases where
InputMethodSubtypeSwitchingController#resetCircularListLocked is
not called but the list of enabled input method is updated.
Fortunately, this corner cases are not observable for a user
because we have not updated the the rotation order dynamically.
However we should fix this before implementing smarter rotation
algorithm that changes the rotation order dynamically.
BUG: 7043015
Change-Id: I145a514dc4cde369ba50431c408c916046ab0c6e
A profile owner should only have control over the profile. All of the
following device admin APIs that affect the device beyond the profile
that they are called from are now disallowed:
- Camera enable/disable
- Keyguard
- Wipe external storage
@bug 14434826
Change-Id: I69acfdf6f654f48b5db91aeb3ea86662d7857075
If <Request ARC Initiation> and <Request ARC Termination>
receive no <Initiate ARC> and <Termniate ARC> and
it should clean up itself, i.e call finish().
Change-Id: Id10fbe416cf5f5ab836935a1b560864b5cbd3b83
ARC channel is established by both TV and AV Reciever.
From TV, it sends <Request ARC Initiation> and AVR
responds with <Initiate ARC>.
From AVR, it can be initiated by sending <Initiate ARC> directly
to TV.
Once TV receives <Initiate ARC> it sets up ARC internally
and replies <Report ARC Initiated> to AVR.
Termination steps are almost same except for message name
(use Terminate instread of Initiation).
In order to implement the above steps, this change introduces
following classes.
RequestArcInitiation(Termination)Action:
handles <Request ARC Initiation> (<Request ARC Termination>)
RequestArcAction handles common logic of them.
SetArcTransmissionStateAction:
handles ARC set up, enabling/disabling ARC and
reports results to AVR.
<Initiate ARC> and <Terminate ARC> handles directly in
HdmiControlService
Along with this, this change has implmentation for
add&removeAction. To avoid synchronization issue
they are isolated to main thread.
Change-Id: I3c5cf7c777e6c1de50d63ce4643b191dfe15fe1f
The key improvement is that we need to keep track of
the package that's currently being scanned (this includes
new installs and upgrades of existing packages) and treat
it specially. If we didn't do that, In the case of upgrades
we would perform the shared UID calculation based on the ABI
of the old package, and not the current package.
This change also allows us to perform the CPU ABI calculation
before dexopt, which saves us from having to do it twice and
fixes a bug where we were using the wrong package path to
dexopt a package.
This also has the side effect of fixing 15081286.
bug: 15081286
(cherry-picked from commit b851c89d2252cf3d1dc504558ce1553527885316)
Change-Id: I20f8ad36941fc3df29007f0e83ce82f38f3585c8
Allow power button to be used to either go to sleep as usual,
which may doze, or skip that completely and really go to sleep.
May also really go to sleep and go home all at once.
Bug: 14406056
Change-Id: Ia19e2551b9c2a72271bb2eddd5c0d1749761e019
When the device enters a non-interactive state, we normally
cancel all active vibrations as a safety precaution. However if
the system is performing haptic feedback then we want to allow
it to run to completion.
Bug: 14319563
Change-Id: I673781bbf32562e45c1595689e6b423bd178ea73
Allow profile owners or administrators of restricted profiles
to restrict access to telephony features such as calling and
texting for a user.
Change-Id: I89f97608c07c647ad8a7b43fef9d1e6bc4a84e95
DMAgent currently needs to live in /system/priv-app in order to
(among other things) set and get blocked packages. These APIs will
get us closer to being able to move DMAgent out of priv-app.
Bug: 14945334
Change-Id: I108e2013c67409dca554acf78e3a710745900706
This launches voice search when headsethook is long pressed unless
you're in a call. The handling is done in MediaSessionService. This
CL also adds a switch to the new APIs to the fallback event handler
which was missed previously.
Change-Id: I1cbdff1d6e9f5293885dd8aaed8ba13cb15b36d4
Device owners can update Settings.Secure and Settings.Global settings.
Profile owners can update Settings.Secure settings.
DMAgent currently needs to live in /system/priv-app in order to
(among other things) update global and secure settings. This change will
get us closer to being able to move DMAgent out of priv-app.
Bug: 14965414
Change-Id: If2cc3a56de91bffde33b838ab8ecea2c32412803
When the screen is off, there are no guarantees about when
non-wakeup alarms will be dispatched. Historically they are
dispatched any time the device wakes up. With this change,
we will delay the dispatch until sometime later.
The amount of delay is determined by how long the screen has
been off. Currently there are three possible delays: up to
2 minutes if the screen has been off for less than 5 minutes;
up to 15 minutes if it has been off for less than 30 minutes;
and otherwise up to an hour.
When the screen is turned on or a wakeup alarm is dispatched,
all delayed alarms will also be dispatched.
Note that one of the things this delays is TIME_TICK, which
means the in many cases we won't deliver TIME_TICK until the
screen is in the process of waking up. The current
implementation causes this to be delayed until the SCREEN_ON
broadcast is sent; we probably want to improve this to have
the power manager tell the alarm manager about the screen
turning on before it sends that broadcast, to help make sure
things like the lock screen can update their current time
before the screen is actually turned on.
In addition, switch all of the alarm stats to use the new
PendingIntent "tag" identifier for its operations, instead
of the old code to try to construct a pseudo-identifier
by retrieving the raw Intent.
Also add a new package manager command to immediately write
packages.xml.
Change-Id: Id4b14757cccff9cb2c6b36de994de38163abf615
