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
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
