The parseInclude method had some deep nesting that could be improved by
rearranging things a little.
Test: atest android.view.cts.LayoutInflaterTest
Change-Id: I2ee13c2ee80bcb220371d39a5a6da6044cfa245c
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
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: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
No change to logic, only docs change.
The bar/pipe symbols have no meaning in javadoc. We should mark this
with {@code} instead.
Bug: 122046530
Test: None
Change-Id: I594480ea3bf4fec9c87a48275364c7c616a0e3ea
The app is not started yet, and does not contain any service for now.
Test: built, booted
Bug: b/112869080
Change-Id: Id5a0fd02c891100e85d86b1040e53beec3581950
extras == null is documented to result in all extras being
erased, and the implementation handles it correctly. The
@NonNull annotation on Bundle extras is therefore wrong.
This CL replaces it with the correct annotation, @Nullable.
The incorrect annotation was introduced in April 2017
(commit 30e06bb668). I've
looked through the other changes to Intent.java in that
commit but have found no further nullability annotation
errors.
Bug: 121438778
Test: Treehugger
Test: Looked through the other nullability annotations on
Intent.java introduced by the same commit
30e06bb668 (Apr 2017)
but found no further errors.
Change-Id: Iebbe17abc5c97146533e82114fbaf1d7036fd03a
* changes:
DO NOT MERGE Set ContainerLayer for buffer-less surface
DO NOT MERGE: WM: Restrict SC Builder to set a single surface type
Implement construction of container layers
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 121237128
Bug: 120783643
Test: m appcompat
Change-Id: Ib7a8bdf3151290aa8a5ca85dc8650612432f0d59
Currently NetworkInfo is used by Apps to get information of
network. However, to get such information, Apps need to poll
NetworkInfo frequently from ConnectivityService.
In order to increase the stability and reduce the maintain
effort, all functionalities provided by NetworkInfo are targeted
to be replaced or removed entirely.
Apps should use ConnectivityManager.NetworkCallback instead, to
get faster and more detailed updates from connectivity changes.
Or, apps could use getNetworkCapabilities or getLinkProperties
to get information synchronously, but should not mix the
callbacks and synchronous methods together.
Bug: 113629330
Test: atest FrameworksNetTests
Change-Id: Ie8faf620958c3fa0a4a2f233b35b825de0e99ffc
These methods are marked to @UnsupportedAppUsage APIs since
Android Q. But some system apps still need them to set/get
necessary network or request information. Hence, make them to be
public or system APIs.
Bug: 120448492
Test: atest FrameworksNetTests
Change-Id: I95a44daef5615e290b40d0796ca183b88ad8a63f
Don't use Os.dup(), as it creates file handles which leak across exec()
boundaries. Instead, use fcntl(F_DUPFD_CLOEXEC);
O_CLOEXEC is essential for ensuring that file descriptors do not leak
across an exec() boundary. Setting O_CLOEXEC ensures that file
descriptors can't linger around unnecessarily in an exec()ed process
which doesn't use them, making more efficient use of resources.
Additionally, O_CLOEXEC is important in ensuring that untrusted
exec()ed code cannot take advantage of leaked file descriptors.
Test: Android compiles and boots
Bug: 120983106
Change-Id: I99a66834cc6b9bb25e1b4daf75384ec6a91ae9e2
