Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
- When the window for the activity enters PIP, update the outline provider
to override the alpha of the shadow (to be opaque) to ensure that is is
visible. Only applies to the task root activity.
Bug: 36741700
Test: Launch YT, ensure that there is a shadow when after it enters PIP
Test: go/wm-smoke
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If089dae84e4916d3d0e7bbeb316215b46e522e05
- This can happen either if an app creates an ActivityOptions without a
thumbnail, or if the call to create a hardware bitmap fails for any
reason. Just ignore the thumbnail for the transition in this case.
Bug: 62296016
Test: Have not been able to reproduce, but this is just a logical change
Change-Id: I30776b651df1f42118fe1d317fa4817261a6e977
- It is possible for the session to be requested to be hidden before it
gets the message to be shown and completes showing. This leads to an
inconsistency where the voice interaction service implementation will be
in a different state than the system for the session. Instead, we can
cancel any pending show messages, and also clean up the pending show
callback list immediately when the session is hidden.
- Also fixing up some error message codes when starting the assistant
activity.
Bug: 38379130
Test: android.server.cts.ActivityManagerAssistantStackTests
Test: CtsVoiceInteractionTestCases
Test: CtsAlarmClockTestCases
Change-Id: I0d0e9c024367a47bda82d6a29ca89e18b7d69527
With my TimePickerDialog change to support keyboard based input I
accidentally broke TimePickerDialog#onClick as it was no longer being
called, instead it was calling TimeSetListener directly. This CL changes
the logic back to use onClick again.
Bug: 36042834
Test: Locally tested FitBit app.
Change-Id: I47d5563c99cc46eaaf2b1d4a96483d6825fc5805
On watches, multi-window is used to present essential system UI, and thus it
must be supported regardless of device memory characteristics.
Bug: 37482466
Test: Manually, on a watch
Change-Id: I7929a090b7fd46de019d237ce771c82a6d7fd3f3
- This reduces the copy of the hardware bitmap when it is
parceled/unparceled.
Bug: 38507414
Bug: 62021436
Test: Launch Overview to/from app, ensure that the header bar shows
Test: go/wm-smoke
Change-Id: I85a9a59a0a3699d1642158061d10fddef34393c3
Signed-off-by: Winson Chung <winsonc@google.com>
When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
This will change behavior so it could break tests but
if it does it is because they relied on broken behavior.
Someone on the frameworks team will need to verify the
correctness of these changes and fix any knock on effects.
See the following for a description of the bugs:
* http://errorprone.info/bugpattern/ArrayEquals
* http://errorprone.info/bugpattern/ArrayHashCode
Fixed automatically by Error Prone apart from manual
changes to fix up the formatting (Error Prone expects
google-java-format) and to change Object.deepEquals to
Arrays.equals for consistency with Arrays.hashCode.
Test: make checkbuild
Change-Id: I1528b795b77a4f1e0c4e7e66ad4f924b7a7606f6
- Happens at a channel level, and system services have to opt in
Bug: 38428796
Test: runtest systemui-notification, manual
Change-Id: I5592b4e32c177844583aee25379390199eef0a58
An invalid, 'null' resource ID is defined as 0. Apps often use -1.
Add a helper method that makes checking valid IDs easy and more
centralized.
Eventually make it public API.
Bug: 38393777
Test: manual
Change-Id: I969ec4a45e86bdab3d7f57d357d475b77c7f8a78
