This API will primarily be used by GmsCore to send updated configs.
Also, sending a config will implicitly notify the StatsD that this
client wants to know when it should request data for this config.
We send a broadcast so that all interested subscribers can know if
data needs to be pulled.
Test: Manually tested that sending broadcast works via new adb
command added in StatsService.
Change-Id: I23cdd1df706036e14b32c3d01af30c3d4af819fa
- isRestrictedProfile - whether the caller is running
as restricted profile.
- hasRestrictedProfiles - whether the calling user has at least one
restricted profile associated with it.
Bug: 64122169
Test: UserManagerTest
Change-Id: I178b02a48abc32e126613e0320c4950f455364df
ContentProviderClient has a nice setDetectNotResponding() method
that detects hanging calls to remote providers, and it can trigger
an ANR to kill the app and release the blocked thread.
We typically don't want to perform blocking calls from the system
server, but we're okay allowing them on CPCs that are using
setDetectNotResponding() to watch for hung clients.
Test: builds, boots
Bug: 69128093
Change-Id: I223aaf1d0cef0f8dee28f800d9e3c101d7449952
AID_SHARED_GID is a GID shared by a specific app across all users on
the same device. Bring the UserHandle and multiuser.c implementations
into agreement, and copy/paste the unit tests that verify that both
behave identically.
Since we might now return "-1" when a GID is invalid, have
ActivityManager handle these cases by quickly swapping in the
always-valid getUserGid().
Test: bit FrameworksCoreTests:android.os.UserHandleTest
Bug: 34151068, 64548938
Change-Id: I0463aba923ae5ce1942666359a394ae6cdb7c1f8
Symptom:
Global reference table overflow happens on system_server.
Root cause:
If a process repeatedly create a context and get AutofillManager
from the context, each BinderProxy of AutofillManagerClient are
registered to AutofillManagerServiceImpl. They aren't removed until
the process is died. BinderProxy consumes global reference and finally
causes crash on system_server.
Solution:
Remove AutofillManagerClient from AutofillManagerServiceImpl after
AutofillManager is finalized.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAutoFillServiceTestCases
Bug: 68747744
Change-Id: I8b76c5368b54317b8696cac470cc390b36e910e7
The current JobInfo.NETWORK_TYPE values offer basic network selection
ability, but more precise requirements continue to come up. Instead
of creating more NETWORK_TYPE constants, add support for the existing
NetworkRequest object, which is the idiomatic way for an app to
express the type of network they'd like to use.
Move the implementation details of NETWORK_TYPE constants to use this
new NetworkRequest functionality. Deprecate NETWORK_TYPE_METERED,
since the lack of the NOT_METERED capability doesn't imply that the
connection is metered. (Apps using this API to get to a cellular
network should use TRANSPORT_CELLULAR instead.)
Add new SystemClock APIs that return java.time.Clock instances for
various Android-specific clocks. This gives us a clean interface
(with negligible overhead) for swapping in artificial clocks for
testing purposes.
Improve JobStoreTest to validate new NetworkRequest features, and
add one last sanity check to assertTasksEqual() to compare raw
bits-on-wire, to catch people who forget to check new fields. Watch
for IoThread to go idle to run tests faster.
Test: bit FrameworksServicesTests:com.android.server.job.
Bug: 67040695
Change-Id: I189e7602132a0ec26d2f0cc6dadc188664961a47
- Flags for force app standby for jobs and alarms, and sensors.
- Don't disable GPS when the screen is off.
Bug: 68769804
Test: manual
Change-Id: I13661498dbc25051f2be0423cb50a55e4e592dc4
/android/system/update_engine/common/error_code.h
Test: Exposed new constant and manually added the change to
api/system-current.txt due to b/68874686
Bug: 68380039
Change-Id: I01a8befe07d37dfa74d3544b80bde2c2cc48acdb
A typical storage device finishes the benchmark in under 10 seconds,
but some extremely slow devices can take minutes, resulting in a
confusing UX that looks like we've frozen. Even worse, we keep
churning through all that I/O even though we know the device will
blow past our user-warning threshold.
So periodically check if we've timed out, and also use that to report
progress up into the Settings UI.
Test: manual
Bug: 62201209, 65639764, 67055204
Change-Id: Id28e63a7ea1476d83184abab5aea737a1d193f3a
For multi-user session implementation, we want to block the user from
going back to user 0. Therefore, we block the user switcher in the
secondary user, as well as swtiching via user section in Settings app.
Bug: 64382189
Test: Manually verify user switcher is not displayed in QuickSettings
Test: Manulaly verify not able to remove or switcher user in user
section in Setting app
Change-Id: I84bc9e67e3fe7fccb75edf0fc49b775b902f5290
Factor out the logic that calls into ActivityManager, since we have
some evidence of violations being triggering before AM has been
published.
Test: manual
Bug: 68940916
Change-Id: Ie64b1eea42393089a657a9b5ae0c4585a0c83bfa
Until now, userdebug and eng builds have tracked StrictMode
violations on all system apps, including prebuilts that we have no
control over, which results in a lot of unactionable noise.
This CL narrows the set of enabled apps to only "bundled" system
apps, which gives us a much higher chance of burning these violations
down to 0 and keeping them there. We don't have a good proxy for an
app being "bundled", so we detect it based on being in the "android."
or "com.android." package namespace.
Clean up the entire flow of applying StrictMode defaults to make it
much more human-readable. This resulted in us fixing a bug where
StrictMode was never actually enabled for jank-sensitive threads in
system_server!
Relax I/O checks in a few places where we know we're interacting with
procfs or sysfs. Add internal "allow" methods that avoid object
allocation by returning raw mask.
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest
Bug: 68662870
Change-Id: I536e8934fbcdec14915fcb10995fc9704ea98b29
