Fix a bug where a ChooserTargetService could supply a ChooserTarget
pointing at a non-exported activity outside of its own package and
have it launch.
Bug 28384423
Change-Id: I3f5854f91c5695ad9253d71055ef58224df47008
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
When long pressing on an empty Text field with the system language set
to RTL, the "paste" popup was not showing up.
The Floating Toolbar requires a content rect to determine where the
text is and place itself close to it. In the case of an empty field,
we create a "fake" content rect by taking the placement of the cursor
+1 pixel to the right. In RTL languages, this +1 causes the content
rect to be considered off the bounds of the view, as the cursor is
aligned to the right, and hence the Floating Toolbar is hidden.
After making the rect a 0 width rect, we ran into the issue that
it was considered out of bounds due to the calculation ignoring rects
that simply touch the edge of the view's bounds.
BUG: 22540083
Change-Id: I29c79b701f586970b2611178233eff082b802ec1
Removes overlap from the color views which resulted in subotimal looks
when both color views were translucent and the nav bar was on the right
edge.
Also fixes a bug introduced in I2df7092a91eceeb815367ef917dd7289f4f2b27e
where the navigation-bar-on-right-side case got forgotten and caused
flickering in landscape when IMMERSIVE_STICKY was set but the navigation bar
was visible.
Bug: 22876533
Change-Id: I449a82eb3dc3f7b5051f26b37b362a196b4ff63a
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
- 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
Previously we tried to read /d/wakeup_sources to gather kernel wakelock data. If that
fails we used the older sys file /proc/wakelocks.
N7 has both /proc/wakelocks and /d/wakeup_sources, but /proc/wakelocks
has the actual data we need. All other devices are using /d/wakeup_sources, so
only N7 experienced a loss of kernel wakelock data.
The original regression was introduced here: ag/659258
Bug:22556242
Change-Id: I51ec68e957f587bc1466e24f0a1dbc8cd7753ac6
- Add onFingerprintAcquired, so Keyguard can grab a wakelock to prevent
the device from sleeping.
- If we get a successful fingerprint, wake the device up, immediately
dismiss the keyguard and tell PWM that we kicked off our frame that
will represent the correct state.
- PWM then waits for this frame to be drawn, and then turns on the
screen, which results in unlocking directly to the previsouly
opened app.
Bug: 21855614
Change-Id: I5f43df17fa5e4e9c6a6392eef4a4590b07df4f96
...context and/or screenshot
Added new API to find out what contextual data has been globally disabled.
Also updated various documentation to make it clear what kind of contextual
data you will get (and when it will be null).
Also added a new Activity.showAssist() API because... well, I was already
in there, it was easy to do, it is safe, and maybe people will build cool
things with it.
Change-Id: Ia553d6bcdd098dc0fce4b9237fbfaca9652fc74b
