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
This deprecates public-exposed constructors. These constructors were
exposed by accident. These classes shouldn't be instantiated by
applications, but should only be instantiated by WebView.
In some cases, the app should get a singleton instance using
a #getInstance method. In these cases, we document this explicitly in
the deprecation note.
Bug: 110807530
Test: make docs, manually verify docs look good.
Change-Id: Ibe73b3399c9ced0cf4fbb01e1df13564476df252
In addition to the legacy "apk-verity" Merkle tree that skips the
Signing Block, now the builder supports the regular Merkle tree.
The class and methods are made public because it will be used in
different package.
Test: atest PtsApkVerityTestCases
Test: With other changes, observe the hash matches what other tool
generates.
Bug: 112037636
Change-Id: I3d96932cd16f4f330170547d6a7689d2997e4b85
Historically ViewRootImpl#mContext has been just pointing to the
Context instance associated with whatever first View instance that is
being added to a Window. In other words, ViewRootImpl#mContext is not
owned by ViewRootImpl.
This can become a problem if ViewRootImpl is moved from a display to
another display with ViewRootImpl#updateInternalDisplay(), which was
added last year to support multiple displays [1], because there is no
guarantee that the target Contaxt that is pointed from
ViewRootImpl#mContext is also updated to have the new display ID.
In order to support multi-display we need to use the right Context at
least when interacting with InputMethodManager. Hence as a short term
solution this CL introduces ViewRootImpl#mDisplayContext so that the
right instance of InputMethodManager can receive callback from
ViewRootImpl. In this way, we can make sure that the behavior change
in ViewRootImple is limited to how InputMethodManager instance is
obtained.
Longer term solution will be discussed in Bug 116349163.
[1]: I9a9501cab788623ada15a31efb53e4b2378639fe
b047b8bd7e
Bug: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ifa0ca24e9cf764caf492ee065606680b6a06751a
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
The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.
This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths. Consider this example:
<path-permission android:pathPrefix="/private" ... />
uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);
content://com.example//private
The Uri above will pass the security check, since it's not
technically a prefix match. But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.
Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.
Bug: 112555574
Test: atest android.appsecurity.cts.AppSecurityTests
Test: atest FrameworksCoreTests:android.content.ContentProviderTest
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
The java counterpart of the JNI is now moved to external/libtextclassifier.
Test: atest android.view.textclassifier.TextClassificationManagerTest
Change-Id: Ide5e58d1c80d9a028cea4e9192a91aeac2843c71
The CL deprecates the old constructor for Magnifier instances in favor
of the usage of builder Magnifier#Builder.
Bug: 116116502
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I3daa9f066c77144e9d5c62bc666ecd37041f4bbb
This CL effectively reverts the following 3 CLs.
* Reduce window resizing during IME transition
I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
* Clear the inset of previous IME when necessary
Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
* Make IMS#clearInsetOfPreviousIme() reliable
Ib567daa009c1139858dccadcfc6a04465ebecf36
833bdcedce
The main idea behind the first CL is that the target application can
skil avoid layout resizing if the following two conditions are met.
A. WindowManagerService (WMS) can remember the last IME's inset until
the next IME's window is fully shown.
B. Both the last IME and the new IME have the same inset.
Basically the first CL implements the above A part with an assumption
that some IMEs would do the B part. However, in reality it is quite
unlikely that two random IMEs have the same inset size. At the same
time, maintaining this kind of special optimization is getting harder
and harder as more and more use cases and form factors need to be
supported.
Let's remove this optimization given that no one is benefited by it.
Fix: 116492038
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: do not see any noticeable visual difference
Change-Id: I8ffbf9bf7c3a8be54df0ca8eac1a1f041ef7d3c9
*1 -- not truncate(2) but "PRAGMA wal_checkpoint(TRUNCATE)"
Otherwise, depending on how an app operate on a DB, SQLite may not
have a chance to "shrink" the WAL file.
Fixes: 112777941
Bug: 111939259
Test: atest /android/master/frameworks/base/core/tests/coretests/src/android/database/sqlite/SQLiteCompatibilityWalFlagsTest.java
Test: Manual test with google dailer:
1. With normalized_spam.db-wal > 100MB and receive a phone call
-> WAL file gets truncated to 0 bytes.
2. Restart the dialer process and receive a phone call again
-> WAL file is already 0 bytes; won't be truncated.
3. Restart with the WAL file deleted
Same as #2. WAL file will be created before the added logic, but is 0 bytes,
so it won't be truncated.
4. Test with settings put global sqlite_compatibility_wal_flags truncate_size=1024
-> make sure the threshold is overridden
Merged-in: I2b193603e5dfa493ccccb8123db592f0e9c0e7ae
Change-Id: I2b193603e5dfa493ccccb8123db592f0e9c0e7ae
(cherry picked from commit 96e06002ed)
We're trying to reduce unnecessary direct dependencies on Conscrypt.
These two methods are simple and the implementations can't change, so
they're good candidates for inlining directly instead of depending on
the Conscrypt implementation.
Bug: 110404540
Test: atest NetworkSecurityConfigTests (same failures pre/post)
Change-Id: I303d955e3f49885326fe75f451c06a52af745053
