Disable accessibility focus on the layout itself and expose the class
name as ScrollView so that we can get auto-scroll working until we have
first-class support for specifying automatic scrolling behavior.
Bug: 22667764
Change-Id: I9b97e40f16038046898e5b56b935a61db9073ac6
The app ops mananger service maintains a mapping from UID to
a list of packages where each package is mapped to a list of
non-default app op states (default states are inferred and
not stored). Hence, specifying the app op state for a UID
requires setting the app op for each package in the shared
UID.
This is problematic when installing new packages if there
is a non-default app op policy set for another already
installed package in the same UID as the app op for the new
package has to be updated to be in sync. The package installer
cannot do this as it is in another process and the app op
update will not be atomic. Therefore, the app ops manager
service has to support specifying app op policy on a per
UID basis.
We now have a UID state object that contains the per package
non-default app op states as well as the per uid non-default
app op states. If there is a UID policy specified then it
takes precedence over the per package one. Even further,
changing the uid policy updates the package policies in this
UID if the state is non-default. Changing a package app op
state also updates the app op state for the whole UID if
the per UID policy for this op is non-default. Clearing the
app op state for a package, clears the policy for the UID
as well.
bug:22802981
Change-Id: I78044906d9fcc6066abf07e706c2c88f3397d293
With this patch, when the user requested shutdown,
PowerManagerService sets sys.powerctl is set to
"shutdown,userrequested", and init runs fsck on shutdown.
When shutdown is triggered due to a low power state etc.,
the service sets the property to "shutdown,", and init
immediately shuts down the system without running the
command.
This is a follow-up CL for http://r.android.com/158525.
Bug: 21853106
Change-Id: Iae72990130fe9aa479c802f77301438190dbbfb3
- remove the content description in Keyguard
- only show virtual views when pattern is in progress
- add a content description when the pattern is not in progress
Bug: 22646748
Change-Id: Id32a37c4c74c82b547cee8861b2856fa0a08c41c
We check for the presence of energy data when determining whether to use
the WiFiPowerCalculator or WiFiPowerEstimator. Since we can receive this data
later, we need to switch to the WiFiPowerCalculator if we weren't using it before.
We can't ask the hardware if it supports energy data because that would involve a call into
WiFiManagerService, which can cause a deadlock if we are holding the BatteryStatsService lock
while using this class.
Bug:22776010
Change-Id: Id685d487c56595eab1d382f49da9417a423bb517
- Add callback to inform SysUI when the screen has been unblocked
and turned on.
- Cleanup inconsistent messaging about device interactive/screen on
and off.
- Add callbacks to inform SysUI about screen states
- Implement a quick fade for the scrim after touch, wake, and unlock.
First, start with a black scrim on top of everything, and then fade
it out.
- Make sure we play the normal unlock animation when device is pulsing
- Override navigation bar animations for touch, wake and unlock: Fade
in the same manner as the scrim.
Bug: 22571198
Bug: 21855614
Change-Id: I8ff08d72cced1e0f03c78d71ff710d8a4f6b848c
The main change here is to not allow the dialog to go in to its "focus
on the last app the user selected" when running in voice interaction mode,
instead just always giving a simple list.
This also fixes some problems with cleaning up active commands when
an activity finishes and not forcing the current session to go away
when the screen is turned off.
Also added some debug help, having activity print the state of the
voice interactor.
Change-Id: Ifebee9c74d78398a730a280bb4970f47789dadf5
Running status was being parsed incorrectly.
This could cause stuck notes or exceptions when sending running
status messages to a Bluetooth MIDI device.
Bug: 22689606
Change-Id: I9f7abce9758927be587eead9614617d5b0076353
Signed-off-by: Phil Burk <philburk@google.com>
There was a mistake in the code that was supposed to recover from the
initial time on a new device being bad until the real time ultimately
gets set, which was causing us to update the start clock time every time
there was a time change (instead of just when the original start time
appears bad).
Rework all of this, so we now count the start time as bad if it is more
than one year before the current time, only modifying it in that case.
Also when modifying it, adjust the time we set it to take in to account
how much realtime has actually elapsed so far in the battery stats.
Change-Id: If74bd711d9b7618c8f6148a9935c452aaaa7e257
