We don't differentiate between null conifguration and
Configuration.EMPTY, but if ResourceKey uses both, it will produce
different hashes and won't be equal. This CL makes ResourceKey always
hold a non null reference to the Configuration object.
We started delivering the configuration overrides in
Ib2c7be0b427f5ce05e7a362bcdd496ddbc9164f0, which changed behavior from
using always null, to using both null and Conifguration.EMPTY for empty
confgiuration. Now we will switch to using only one value, which is
Configuration.EMPTY.
Bug: 22620824
Change-Id: I090fd90ac21a6b3ebc7f2974a91dd7c861af10d7
Currently update() bails out early if it is called
too soon after mStartTime has been set. In this case
mCurrentPosition remains holding an obsolete value
from a previous animation. This causes some strange
behavior (see the referenced bug).
This patch makes sure that mCurrentPosition is
updated every time that mStart is updated.
Bug: 22950559
Change-Id: I07b92f30ebe29856f4e04dc19a4820123713fd7e
When missed calls are restored by CalllogBackupAgent using the addCall
API of CallLog provider, we were setting the IS_READ flag to 0 which
resulted in user getting a missed call notifications for all missed
calls after restore.
Adding a new addCall API signature which can specify the value to be put in the
IS_READ field when a call is added to the calllog provider. This will be
used by the CallLogBackupAgent to mark all restored missed calls as
read.
BUG: 22908952
Change-Id: Iee3bea09fbdefef09c7eb6c6c61728cb4d94d9e7
As discussed in b/21429947 (commit
674019065b), MTP must always be
enabled, even if access to the underlying MTP data is disabled.
Otherwise, Android will not enumerate on the USB bus, and won't
receive notifications from the kernel about USB state changes. This
effectively prevents using MTP functionality on user builds, or
on userdebug/eng builds with adb turned off.
Always ensure that MTP is the default driver mode.
Move the DISALLOW_USB_FILE_TRANSFER filtering of mUsbDataUnlocked from
setting time to the time we post the sticky broadcast.
Remove isUsbDataUnlocked(). It essentially duplicates data in the sticky
broadcast.
Bug: 22447614
Bug: 21429947
Change-Id: I9d0d94cadbf6db6281ebd77bfb7162f9d06520c2
With this change:
1. NOT_RESTRICTED should be removed from NetworkRequests that bring up
special restricted carrier networks (e.g. IMS, FOTA).
2. NetworkRequests without NOT_RESTRICTED require CONNECTIVITY_INTERNAL
permission to register
3. Binding sockets to networks without NOT_RESTRICTED requires
CONNECTIVITY_INTERNAL permission
Bug:21637535
Change-Id: I5991d39facaa6b690e969fe15dcbeec52e918321
BUG: 22287469
1) Fix SyncManager waking up every 2 hrs if there is nothing
to do.
2) Fix sync wake-up alarm not being properly updated if the new
alarm was in the future.
2a) Due to staus bar sync signal that were removed post-K
one of the wake-ups was for 30s in the future, removed this
@hide intent completely.
3) The SyncManager will still set a timeout alarm for 5mins after
the start of a sync. Leaving this in as to post to a handler is
less expensive but more complex, and the alarm update is
correctly working now.
Change-Id: If51c9dd68391ccaeb480a17eb5a1364c4afe4c2a
Add new Activity.isVoiceInteractionRoot() API that an activity can use
to determine whether it is the root activity of a voice interaction
session started by the user's designated voice interaction service.
This is a special new API that apps must explicitly check, because as
with visual activities the model behind an activity should usually be
that it accomplishes its task by interacting with the user (implicitly
getting their approval) rather than trusting that whoever invoked it
is telling it to do what the user once. In the voice world, however,
there are some cases where quick interactions want to allow for immediate
execution without further user involvement, so this API allows for that
without opening up security holes from other applications.
Change-Id: Ie02d2458f16cb0b12af825641bcf8beaf086931b
Doing this so we don't break current apps. In the future we should
properly position the activity in the stack (i.e. behind all current
user activity/task) and not change the positioning of stacks.
Bug: 21801163
Bug: 13507605
Bug: 22929608
Change-Id: I979b6288e66f5b2ec2a6f22cb8d416e5c68109bd
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
- Add vendor keys to getKeys() calls for CameraCharacteristics,
CaptureRequest, and CaptureResult.
- Vendors can specify whether custom keys show up by listing
visible keys in the REQUEST_AVAILABLE_RESULT_KEYS field.
- Vendor key types are always treated as a primitive (or Rational)
array type corresponding to one of the valid types for
a camera metadata entry.
Bug: 22067625
Change-Id: I6e7dd3db7a8bf533c2ec15ff69ca38824134e971
LinearLayout relied on multiple measurement passes to hide a
discrepancy between EXACTLY and non-EXACTLY measurements.
This reverts commit 9cefbda11e.
Bug: 22810327
Change-Id: I515a80749420d00efc5002fa68221b7c236f03df
"Include non-zero dimension views in excess space calculation" and
"Always distribute excess space in LinearLayout measurement" changed
LinearLayout behavior significantly in a way that wasn't covered by
CTS tests.
This reverts commits da2f304409 and
4fabc02158.
Bug: 22862047
Change-Id: I8d37a525ccf295445d3239b80e5cacb10bf3c947
