The value is read from /proc/PID/status or memory.max_usage_in_bytes (for devices with per-app memcg enabled).
Reading the value takes about 2ms per process.
Full snapshot taken by statsd is around 300ms.
Results: https://docs.google.com/spreadsheets/d/1vG9ku8Uu8104CmKbO4cNeEKVeeByvHY--p0_dK1GAdA/edit?usp=sharing
Bug: 115477992
Test: atest FrameworksServicesTests
Change-Id: I87995cbd85085375ade685f29e986ba173f9693e
Added PendingIntentController and centralize pending intent handling
in that class. Pending intents are used by activities and other components
like services and broadcasts. Since, activity handling is going to be moving
to the wm package, we need a way to access pending intents from both am and
wm packages. The PendingIntentController allows this to by not holding any
service level locks.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I52f6f233b24e62839a85067556f3560dec27f0c7
The Permission Controller app (a mainline module) needs to be able to
read the SPLIT_PERMISSIONS. Hence this array needs to be exposed at
least as system-api. We need to make sure that the PackageParser,
PackageManager and Permission Controller app agree on which permissions
are split, hence it is best to define them at a single location.
I think exposing the split permissions to developers is useless and
potentially confusing. The app should never request a permission that
was split. The app should just behave as if split permissions do not
exist. The Permission Controller / Package Manager deal with the
split permissions and add them when needed. Hence I don't think we
should expose this data to 3rd parties.
Bug: 110953302
Test: requested permissions
Change-Id: I6951c52979c89ee5c13a4a14da125e1a01f2e234
As its JavaDoc says, in most of cases PooledLambda.obtainMessage() is
a better choice than PooledLambda.obtainRunnable().
If PooledLambda.obtainRunnable() is really necessary, let's make sure
to call recycleOnUse() whenever possible.
Test: presubmit
Change-Id: I3dbe500f49c0df187f2ffefd11c71836696dfd4e
Introduced the process config and adjusted mergedconfiguration
related calls. Such that we can override configuration for a process
when need to.
The potential use cases include:
1. Maintain process window bounds for the latest activity to override
the display info for legacy apps;
2. Override the display info for IME process to make sure the IME can be
shown with the correct display metrics.
ActivityManagerService:
- Use process configuration instead of the global configuration when
it's for app.
ActivityStackSupervisor:
- Use process configuration when start activity.
WindowProcessController:
- Make it a ConfigurationContainer.
ActivityTaskManagerService:
- Add interface to get configuration for a process. If the process is a
system process or non-existing process, return the global
configuration.
- Return device configuration related to the process.
- Propagate configuration updates from Global to Process.
ActivityTaskManagerInternal:
- API to update configuration for IME process.
WindowManagerService/WindowManagerInternal:
- Propagate the process configuration change to wm.
WindowState:
- Use process configuration instead of global.
Test: go/wm-smoke
Test: servicestests will remain the same result as without this patch.
Bug: 113253755
Change-Id: I3660723352d2e8779d40528ae92d71f59ddbf1f1
All future biometrics share the same USE_BIOMETRIC permission.
Bug: 116340012
Test: BiometricPromptDemo works
Change-Id: I6e5af4d6dc1b467e67957c0aec90f6c0a67028a7
Fixes: 112570477
Test: BiometricPromptDemo works
Test: Able to get/use BiometricManager
Test: Tested with enrolled and non-enrolled biometrics
Change-Id: I26231894eccc87c42b5b3007aa0b7c6f09830452
Synced with alanv@ that doc weren't federated against AndroidX yet, use
this v7 reference until they migrate the docs to AndroidX.
Test: m -j offline-sdk-docs
Bug: b/116163454
Change-Id: Ib5167c4815708d159945ce6db239f8debdf8f865
With this CL, no one in the Framework is using
InputMethodManager#getInstance() directly or indirectly. It is time
to mark this method deprecated.
For applications that still call InputMethodManager#getInstance()
directly or indirectly via reflection, they will start seeing warnings
with stacktrace in logcat.
Except for that explict warnings in logcat, there is no behavior
change in this CL. Added a new test to make sure that
InputMethodManager#getInstance() and InputMethodManager#peekInstance()
are still working in a way we expected for such applications.
Fix: 115891476
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ib393086d921f91993395b5f0007b725a5db7bf22
- Moved CompatModePackages to ActivityTaskManagerService since it is mostly used for activity stuff.
- Moved mHeavyWeightProcess to ActivityTaskManagerService since it is set for activities.
- Set AMS.mBooting and AMS.mBooted as volatile to allow setting from both AM and WM side with hold locks.
- Allow updating of cpu stats, usage stats, and foreground time from WM side.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I48ab55bdd5aacc864cb6a82d19d1a24b7605a5b0
The AccessibilityManager is a singleton, so we need to update it everytime
an activity is resumed.
Test: manual verification with Chrome (CTS test is an overkill here)
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Fixes: 112690889
Change-Id: If011db203dee96ec511da80f4e49395c0340f482
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
