This gives the ONE app installed on the system the permission to
authorize the sharing of incident and bug reports with an app.
Currently that app is PermissionController. Package Manager
enforces that there is only one installed, and refused to boot
if that isn't the case.
Bug: 123543706
Test: bit GooglePermissionControllerTest:*
Change-Id: I76a7fad0ea36359bbb0ff09669df46202d059dab
This is required for capturing playback audio for Tap2Captions. (Live
Captions).
Read the content capture service package name from the content capture
service name defined in the resources.
Change-Id: I6190e1eddf67a9f1d3d3718f61b22a0f235a05e9
Bug: 120408493
Test: manually that actions services has the permissions granted.
Also removes an extra s from a method whoooooops
Bug: 111236845
Test: atest NotificationManagerServiceTest
Change-Id: I1f77afd10b322088aa9cb39b65d70cbd84fb6dc4
When an app takes a long time to handle broadcasts, we start deferring
further broadcasts to it to make sure that other broadcast traffic in
the system can continue to make progress. Global delivery order is
technically rearranged, but delivery order from the point of view of any
given app remains consistent with issuance order.
When alarm broadcasts are issued, we prioritize delivery of deferred
alarms to the alarm recipients (i.e. we suspend the deferral policy and
catch up as promptly as possible) in order to minimize wake time spent
waiting for the alarm broadcast to be delivered. Once an app with a
deferred broadcast backlog is no longer the target of an in-flight
alarm, we re-impose deferral policy on it.
This policy intentionally trades off increased broadcast delivery
latency to apps that take a "long" time to handle broadcasts, in
exchange for lowering delivery latency to all other apps in the system
that would previously have had to wait behind the slow app.
In addition, broadcast dispatch policy parameters can now be overlaid
via the usual global Settings mechanism. In particular, configuring the
"bcast_slow_time" parameter to a value in milliseconds higher than the
queue's broadcast timeout period will disable the new slow-receiver
policies.
Bug: 111404343
Test: device boots & runs
Test: tests/ActivityTests
Change-Id: I76ac79bdf41ca3cfcc48515bca779ea0f5744c0b
Support to expose the apps accessing accessibility features in the
permission hub. Start logging each time any data goes to services.
Bug: 122615167
Test: a11y CTS & unit test
Change-Id: I21f92dad8b3ec2e59a8ad6d180dc466357347784
... on every boot.
These should never have been set, but we allow settings them via the
shell.
- Also previously a bug set per-pkg app-ops.
- Also set the app-op correctly when a fg/bg permission looses it's bg
permission.
Test: Set per-pkg app-opp. Rebooted and saw log message.
atest --test-mapping frameworks/base/services/core/java/com/android/server/pm/permission/:presubmit
Change-Id: If3b56fc08783ea99b4dba70c5fa275b94411ce94
Fixes: 123177944
Includes @SystemApi for Context.NETD_SERVICE so system apps (including
the network stack) can obtain the service.
Test: m
Bug: 112869080
Change-Id: Ida63747cd30abb7b3c19559803353eb0e42e6efa
To ensure future BP builder changes don't require a 1:1 addition to the
CC API, we're deprecating CC and moving the API to BP.
Since CDC is an activity, and BP can't receive onActivityResult from CDC,
we need to have BiometricService launch CDC. CDC will return auth/reject
results to BiometricService using a private protected aidl method, which
can then forward the reuslt to BP/app.
Bug: 111461540
Test: builds
Test: demo app, receives correct callbacks
Change-Id: I7111ca2842534a596302fe0eb7338fbfaca72eec
Creates a StatsManager API to register a pending intent that is invoked
whenever the active status of any of any config sent by that uid
changes.
ag/6112554 and further cls are needed to properly send back the pending
intent.
Bug: 123372077
Test: build success on blueline-eng. More thorough testing should be
done once ag/6112554 is submitted.
Change-Id: I36985c9820d4e7ac178064924190af88ea822254
Some system resources can only be accessed exclusively by a single
client at a time. Previously there was only one resumed activity in
the system at any point, so apps were usually trying to obtain such
access in onResume. With multi-resume this is no longer a good place
to do so, because:
- onResume may be called for activity that is not on top;
- top resumed status may be switched between different resumed
activities in multi-window mode by tapping on them.
This adds a separate callback to inform apps about top resumed state
gain and loss events. The following rules apply:
- both callbacks can only be delivered between onResume and onPause;
- top resumed state loss always follows top resumed state gain;
- the callbacks are optional, activity can go from onResume to
onPause without obtaining top position.
Bug: 117135575
Test: atest CtsActivityManagerDeviceTestCases:ActivityLifecyclePositionTests
Change-Id: I45797afe47b166b22cfb75b64132b22d3fb4ecc7
To help track down potential bugs add adb commands to enable detailed
stack trace logging of calls to noteOp
Test: Manual
Bug: 123351070
Change-Id: I7817eea95a8861b3979504d16b03076beef1ac13
This CL adds a display-level fallback for remoteanimation overrides
and a property to RemoteAnimationAdapter specifying whether it needs
a snapshot for change transitions or not.
During a mode-change, this check for an override and then asks it
whether it needs a snapshot before creating one.
Bug: 113252739
Test: Added AppChangeTransitionTests
Change-Id: I47c933bd08fe512dc6cf029607819e2c908ab4cd
