These are either already exposed on other specialized collection variants or are exposed as public API on the androidx versions, or both.
With these APIs exposed, all of the unsupported app usage can be done through public API. As a result, all unsupported app usage is now locked to apps targeting API 28 or earlier.
Bug: 116877302
Test: none, no implementation change
Change-Id: I548d71319bffb0a6b529e380ea936df674dbf515
An application can declare that it must be installed with at least
one split using the manifest attribute "android:isSplitRequired".
Setting the attribute to 'true' [default is 'false'], the application
can't be installed with a base-only. It must be accompanied by at
least one split [either feature or config].
Change-Id: I42804af34a4209ba5d6726d681ca705ca2c21a39
Fixes: 111391719
Test: atest CtsAppSecurityHostTestCases:SplitTests
Bug: 102591313
Test: Compared settings in light & dark UI modes with
force_dark set to true. Observed that force_dark fixes
were not present when UI mode was set to dark, indicating
force_dark was appropriately globally-disabled
Change-Id: I5882829bb5871829fc8fc9911682f52a6ba5f445
This reverts commit 8a8832fd81.
Reason: most of the users in this new API are not in pi-dev so this change does
not make sense in this branch.
Change-Id: I73b7834916b4f45017010c45e96ea2538e952443
This reverts commit 8a8832fd81.
Reason for revert: Causing failures on git_pi-dev-plus-aosp for docs and aosp_sailfish.
Change-Id: I1801188e66420a67244b3223e26334c4650d56be
Merged-In: Ic108c484905f80783982a22e8152609257d684b5
InputMethodService#getInputMethodWindowRecommendedHeight() was added
with an assumption that some IMEs may want to call this API in
InputMethodService#onCreate() to adjust its IME window height to be
the same as the previous IME's window height [1], but in reality for
IME developers this API is quite difficult to use because relying on
this API means user-visible behavior is no longer deterministic.
Basically "Recommended" is too vague to rely on.
Let's deprecate this API before we end up having to define what is the
"recommended" height for more complicated scenarios such as
multi-displays and multi-profiles.
With this CL, IMS##getInputMethodWindowRecommendedHeight() always
returns 0. Basically doing this would not likely to cause
compatibility issues because the possibility of returning 0 has been
clearly mentioned in the API document. In practice this must have
returned 0 when the previous IME did not show the software keyboard
(e.g. AOSP keyboard with a hardware keyboard). Therefore IMEs that
have correctly used this API should be able to fall back to a safe
default behavior even if this API returns 0.
[1]: I0e920ee79c526c3aea6872b063cf294e2ab081c8
658c7b896a
Fix: 116502957
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia2cde031a0e67d45a3631e54226f9b5a0698dd61
1. new System API for getPreferredNetworkType
2. new System API for preferred network mode
Bug: 115894190
Test: unit test
Change-Id: I34b060d3f915f2c74b2b9412d03f849e9d037c0b
Merged-in: Ic108c484905f80783982a22e8152609257d684b5
This CL includes:
- Fix typo
- Make SystemFonts final
- Storing readonly buffer in Font
Bug: 116224077
Bug: 116224515
Test: m update-api && m docs
Change-Id: Ib7442bac6d2d8efea4deff1fd309940794c20a88
1. new System API for getPreferredNetworkType
2. new System API for preferred network mode
Bug: 115894190
Test: unit test
Change-Id: Ic108c484905f80783982a22e8152609257d684b5
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
For each lifecycle event exposed in
ActivityLifecycleCallbacks, an additional pair of
methods have been added to give developers a reliable
callback before and after each lifecycle event.
The existing callbacks cannot be used for this as they
are called as part of the super implementation and
therefore can run at any point in relation to the
other code in the Activity.
Test: manual
BUG: 116118635
Change-Id: If91f3f3248f9d7cf14aac2fe24ce14d92b8d05d3
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
