It is a little bit limited right now, but it contains
the lifecycle of a tile getting added/removed, and
listening/not listening and clicks.
SysUI side will need some cleanup later on.
Change-Id: I4db803c8a271f8bf44f2ef710517969a84a95cf0
The ephemeral provider is a service that simply determines whether or
not an ephemeral application is available. The ephemeral installer
does the heavy lifting of installing the ephemeral application.
Bug: 25119046
Change-Id: I591f4c2c3f2b149d299fa8b4f359f2582d9199cb
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
unhide ActivityOptions APIs for setting launch bounds for
an activitiy so apps can use it. Only works on devices that
support PackageManager#FEATURE_FREEFORM_WINDOW_MANAGEMENT.
Bug: 25499677
Change-Id: I75424681f25cbb9fe92f2ed73e6afbab765dab29
View.cancelDrag cancels a drag operation initiated by
View.startDrag.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 24415683
Change-Id: Iae5ff3534b6c747ae174f170fdd01ff4d3b1c312
Also separates magnification state and touch event handling. Moves
callbacks for window manager changes and display state changes into
the magnification controller.
Bug: 22718911
Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
Reduces the amount of time that a lock is held and reduces the scope of
the lock to only manage the temporary TypedValue. Also ensures that the
typed value is consistently returned to the (single item) pool.
Additionally, performs some refactoring:
- removes unused variables and constants
- moves the NotFoundException cause into the constructor for consistency
with other Exceptions
- inlines sPreloadedDensity which was not used anywhere
- fixes line wrapping and indentation in nearby code
Aside from improvements to locking, there are no functional changes in
this CL.
Change-Id: I8c3059261e3cc2288a086e6637ab946e0b7d3741
Clean up usage of temporary TypedValue in Resources
Reduces the amount of time that a lock is held and reduces the scope of
the lock to only manage the temporary TypedValue. Also ensures that the
typed value is consistently returned to the (single item) pool.
Additionally, performs some refactoring:
- removes unused variables and constants
- moves the NotFoundException cause into the constructor for consistency
with other Exceptions
- inlines sPreloadedDensity which was not used anywhere
- fixes line wrapping and indentation in nearby code
Aside from improvements to locking, there are no functional changes in
this CL.
Change-Id: I8c3059261e3cc2288a086e6637ab946e0b7d3741
Add granular StorageManager APIs for key creation/destruction and
unlocking/locking. Start passing through an opaque token as part
of the unlock command, but leave it empty for now. We now have a
separate "prepare" method that sanity checks that user directories
are correctly setup.
Define a handful of system properties used for marking devices that
should be operating in FBE mode, and if they're emulating FBE. Wire
a command to "sm", but persisting will come later.
Start using new "encryptionAware" flag on apps previously marked with
coreApp flag, which were apps running in the legacy CryptKeeper
model. Small tweaks to handle non-encryptionAware voice interaction
services. Switch PackageManager to consult StorageManager about the
unlocked state of a user.
Bug: 22358539
Change-Id: Ic2865f9b81c10ea39369c441422f7427a3c3c3d6
This information, if set, will be shown in the lock screen instead
of the user owner information and the settings tile will be made readonly
(implementation in following CLs).
Bug: 22547309
Change-Id: Ic826d8049bc67f5e8fcfa6a91aa2017247c93b11
While one party calls oneTouchPlay() to initiate the action and
put it in progress, the other parties making the same call gets
an error 'operation in progress'. This is not really an error,
but there was no other choice for them but just to wait till
the action is completed and the service is ready to accept
the API call again.
This CL resolves the inconvenice by allowing multiple callbacks
rather than returning IN_PROGRESS for those joining later. Same
was applied to queryDisplayStatus().
Change-Id: I5fc9aba4aa73e76a25f8fdec37e11cd961a3d35f
(cherry picked from commit 98a25f1ee27c1b4362a23981edc17fc92199a876)
Apps can mark manifest components as being encryption-aware, which
means they can safely be run before the credential encrypted storage
is available.
Start adding filtering logic so that we only return these components
when a user is running "with amnesia." That is to say, only device
encrypted storage is available, so the user is running but with only
partial knowledge of its data.
To avoid calling into ActivityManager with the PackageManager lock
held, we quickly determine user state and splice the state into the
flags for later per-component evaluation.
Bug: 22358539
Change-Id: Idc56ec29f1ef04da8963e004314d7f5e47400997
Define two explicit directories where device-encrypted and
credential-encrypted data will be stored. Third-party apps only
need access to the device-encrypted directory, so that's the only
API exposed for now.
General cleanup in how ApplicationInfo details are derived.
Bug: 22358539
Change-Id: If0a0108721a4aa1c3052b4912e08604bbf24e1ae
1. Add clock to metadata - If the CAR does not have a clock (no network
or bad clock) then Radio RDS could be used as a proxy.
2. Add support for emergency announcement - If the CAR wants to make an
emergency announcement.
2.1 Add support for callbacks.
Bug: b/24807501
Bug: b/22701655
Change-Id: Ib3131de03a022181559fd31da6701d9d3fa8698d
(cherry picked from commit 659688a129189f2a9aa353ddf9e107d5f293c4ca)
The DPC can use it to tell if provisioning a managed profile or for
device owner would work or not.
BUG:25338478
Change-Id: I09ea6a9f23a8e88e4ed37c048170b2a68213086e
These simple utility classes (used internally since Property was first introduced
way back in Jellybean) are the best way to avoid autoboxing when using the Property
approach to ObjectAnimator. But since their hidden, developers have to use the
autoboxing version (Property, the superclass) or know to come up with their own
primitive-optimized property subclasses.
This CL simply un-hides these two classes to make them usable outside of the framework.
Issue #21722783 Make [Int|Float]Property public
Change-Id: I7f3a456d108bf48587d711255d3577cce3ac5e24
The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time. The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered. If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped. This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.
The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method. There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.
An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler. If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
