Since we start recents before we take the snapshot, we need to add
a mechanism to inform recents about task snapshots changes.
We add a new method to TaskStackChangedListener,
onTaskSnapshotChanged, which gets called whenever a task snapshot
changes. Then, SystemUI registers such a listener and updates the
task thumbnail view for the specific task.
Test: Open app, press recents, make sure thumbnail is up-to-date
Bug: 31339431
Change-Id: I01e81b9cd11886da734da671c68d5732aa51009f
Also destroy snapshot when we remove the AppWindowToken.
Test: runtest frameworks-services -c
com.android.server.wm.SnapshotCacheTest
Test: Open app, go home, kill app, make sure snapshots are
destroyed.
Change-Id: I532c2d7499a86164175f9fcbc8b77c6eb6bfeae6
Introduce a parameter object to reduce the amount of method overloading
we need to do now and in the future.
Bug: 30876804
Test: manual
Change-Id: I4242140835d440d910a2e2e0ee79af2271e1c046
Currently, those features are available on single user devices only
(since they collect privacy sensitive data device wide). Now making
them available as long as all users are affiliated.
It'll take a certain amount of time between user creation and the DPC
of that new user setting the appropriate affiliation ids. The DO won't
be able to access the logs during that time (and won't get any "logs
ready" callback). Once the affiliation ids are set, if they match,
logs become available again - this includes logs collected while the
user was being setup. Some logs might be lost though if the amount of
data exceeds the internal limit.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts -a armeabi-v7a --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest
Bug: 32326223
Change-Id: Idfe881dd6497d3ad2bead10addfd37b98b8a6e2b
The GraphicsEnvironment class is given information during application
start, and makes it available to EGL/GLES/Vulkan loaders that don't
have easy access to the VM or to the application Context. Currently
only the driver path is handled, but the existing support for setting
library paths (for Vulkan extensions) and cache directory information
should move here.
Bug: 33531483
Test: various apps w/ and w/o driver package installed
Change-Id: I5820d3d1301d5461e10706f551b268c54d4f8926
Bug: 30972434
Change-Id: Iccdaa6253fd5a118893f2869bfb876b1d1e015c7
Test: No tests yet. Want to get a preliminary OK for the new API. Will add a test before submitting.
This CL allows a reason to be specified when installing a package. The
install reason is a sticky piece of metadata: When a package is e.g.
installed via enterprise policy and an update is then manually
installed or sideloaded, the install reason will remain "policy."
The install reason is tracked separately for each user.
With this CL, two install reasons exist: "policy" and "unknown." Other
install reasons will likely be supported in the future.
Bug: 32692748
Bug: 33415829
Test: Tested manually with "adb install" / "adb uninstall"
Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86
- Distinguish between task overlays that need to be resumed and
those that should not.
Bug: 34240533
Test: Open PiP, tap to show menu.
Change-Id: Ibdb54d544c501a492260f02cdc2de40c5c1a66d1
These tests if an app window token reports resize when device is
rotated from landscape to seascape.
There is also some additional plumbing to be able to perform a
rotation in unit test. Also dynamic stacks are now allowed to
influence the orientation of the device.
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Bug: 33607506
Change-Id: I7b23e2de48d56c9fe485eae6a165378dbbbd08bb
Upcoming platform features need to cluster apps together into broad
categories to help summarize information to users. (For example,
when presenting battery, network, and disk usage.)
We are tightly limiting the set of categories to keep them easily
presentable to users when summarizing information. This feature is
not designed to be a general-purpose taxonomy, nor should it be
allowed to become one.
Older apps may not have defined a category in their manifests, so
allow the installing app to define a category on their behalf.
Test: builds, boots
Bug: 33815939
Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7
On selection of a snooze context SnoozeCriterion.
Test: runtest systemui-notification & make cts-verifier
Change-Id: Iaca567100c29295fbbf1d327195a114106909652
Pass information about content insets of a snapshotted task to
SystemUI and use it there to correctly offset the snapshot
when drawing.
Test: Open app, go to recents, make sure app aligns before
and after the animation.
Bug: 31339431
Change-Id: I2ff9bd44534bd8f66b591385da1e1e3aec40b6c5
All this functionality is hidden behind a flag. If this flag is
active, we disable the regular screenshots.
Instead, we take a screenshot when an app transition for which a
task is disappearing is starting. The screenshot gets stored
into a gralloc buffer. SystemUI uses a new method to retrieve
a snapshot gralloc buffer and then draws it using GraphicBuffer.
createHardwareBitmap().
When starting an existing activity in an existing tasks, or when
bringing an existing tasks to front from recents, we add a new
snapshot starting window. For that, we reuse the existing
starting window, but when creating the window, we use a fake
window that draws the contents of the starting window.
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotControllerTest
Bug: 31339431
Change-Id: If72df07b3e56f30413db5029d0887b8c9665aaf4
ActionBar keyboard navigation logic is now implemented via clusters.
Old implementation using setTouchscreenBlocksFocus and Ctrl+Shift+<
shortcut is removed.
Looking at the code, I can’t rule out existence of all 3 categories
(1) action bars with a nested toolbar, (2) action bars without a
nested toolbar and (3) Toolbars outside of action bars.
Because of this, I set “cluster” attribute both on action bar and
toolbar, and have code to avoid nested clusters in case (1).
Support lib’s action/tool bars aren’t converted, however, they
didn’t regress since Ctrl+Shift+< never worked for them. Will be
done after feature freeze.
Bug: 32151632
Test: Manual checks.
Change-Id: Ieb93980088c0fb385a9bc8a5d218ffc269b94dc5
Bug 33849992
When popping and executing another transaction, the pop
transaction weren't properly tracking the fragments that were
added and removed.
This CL adds tracking the fragments during the pop execution.
It also fixes a small issue in when fragment state was executed
during pop.
Test: I89ed2386220deb21b417cd6674292c12accab18b
Change-Id: Ie693eef38b0136bf8ea76027dbc756b35ee9a366
Bug 33754255
Instead of making Views INVISIBLE immediately after adding them,
Views are set to transitionAlpha = 0.
Test: I966da3051912fff0f7ac42dec31626fd8248f7c2
Change-Id: Id032d363379ad07376e5ad8def6131820493e4a9
For linking TaskRecord in AMS to Task window container in WMS.
Bug: 30060889
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowContainerControllerTests
Test: bit FrameworksServicesTests:com.android.server.wm.TaskWindowContainerControllerTests
Test: Existing test pass and manual testing.
Change-Id: I16248f3e96e5087ba24198a48a3bd10a12ae76a6
This option takes a lightweight version of bugreport that only includes a few,
urgent sections used to report telephony bugs.
BUG: 32589463
BUG: 26849505
Test: manual
Change-Id: I6f90c02779a1e8aead690428626e3b9f06aa04df
By adding an onTaskProfileLocked(taskId, userId) RPC to
TaskStackListener and routing that through to a new WorkLockController.
Bug: 31001762
Test: //tests/PoApi/src/com/google/android/afwtest/poapi/WorkChallengeTest
Change-Id: I3fd28e6926c3f928e78b3c6ce0fe27413617695f
- Explicitly split View methods into Assist and AutoFill methods, rather
than use an overloaded method that takes flags.
- Simarly, renamed ASSIST_FLAG_SANITIZED_TEXT and
ASSIST_FLAG_NON_SANITIZED_TEXT flags to
AUTO_FILL_FLAG_TYPE_FILL and AUTO_FILL_FLAG_TYPE_SAVE respectively.
- Created a AutoFillUI class to host the auto-fill bar and other UI
affordances.
- Moved the temporary notifications to AutoFillUI (eventually that
class will host the real UI).
- Moved FillData to android.app.view.autofill package.
- Split IAutoFillCallback in 2 (IAutoFillAppCallback and
IAutoFillServerCallback, residing at the app and system_server
respectively), so service cannot fill the app directly (which lets
the framework control the UI).
- Moved assist's IResultReceiver to AutoFillServiceImpl so
system_server can act as a mediator between the AutoFillService
implementation and the app being auto-filled.
- Replaced FillData and FillableInputFields by a bunch of new objects:
- FillResponse contains a group of Datasets, each representing
different values
that can be used to auto-fill an activity (for example, different
user accounts), optional id of fields the service is interested
to save, and an optional bundle for service-side extras.
- Dataset contains a name, Fields, and an optional bundle for
service-side extras.
- Fields contain an AutoFillId (parcelable) and a value (Bundle)
- Changed the temporary notifications to emulate the new workflow:
- Initial notification requests the auto-fill data but do not
auto-fill.
- Once service calls back, a new notification is shown with the
results.
- Then if the user selects a dataset, the activity is auto-filled
with it.
- It also shows a notification to emulate what can be saved.
- Created an VirtualViewDelegate for views that uses a virtual
hierarchy for assist data.
- Added new methods on ViewStructure to add children with virtual ids.
- Added 2 methods on View to support auto-fill:
- autoFill(Bundle) to auto-fill the view.
- getAutoFillType() to return how the view can be auto-filled.
- AutoFillType defines the input fields that support auto-fill:
- Text fields (like EditText)
- Toggle fields (like CheckBox)
- Lists (like RadioGroup)
- AutoFillType can also have a sub-type representing its semantic (for
now only text fields have it, and it's the same as getInputType()).
- etc :-)
Bug: 31001899
Test: manual verification
Change-Id: I2dd2fdedcb3ecd1e4403f9c32fa644cb914e186f
Now that installd has the implementation details we need, we can wire
up the public APIs to use them.
Shuffle APIs around a bit so that StorageStats can be reused for both
UID and UserHandle results, and rename StorageSummary to
ExternalStorageStats. Provide getTotalBytes() and getFreeBytes() as
first-class methods so we can answer those questions quickly without
paying the cost of measuring external storage details.
Current costs on a typical device with a test account after flushing
dentry caches:
queryStatsForUid() manual: 6922ms
queryStatsForUid() quota: 525ms
queryStatsForUser() manual: 1686ms
queryStatsForUser() quota: 113ms
queryExternalStatsForUser() manual: 42ms
queryExternalStatsForUser() quota: 2ms
For verification purposes, a new "fw.verify_storage" system property
can be set to compute both manual and quota statistics, and log any
discrepancies.
Test: builds, boots
Bug: 27948817, 32206268
Change-Id: I4ea3df3372a7379aa8cf4c20c44120c8f0702c15
DeviceAdmins inside profiles may receive broadcasts referring either
to the parent profile or to themselves.
We need a way to differentiate that.
Same commit fixes a bug in DevicePolicyManagerTest where USER_SYSTEM
is returned twice in getProfiles() when called for a managed profile of
USER_SYSTEM. This does not happen in the real API.
Bug: 30185351
Bug: 31001762
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Change-Id: Iea2735357f4019b2b81b6784e7ea6aead63f2636
