* changes:
Disable the AppOp Restriction for IpSec Tunnels
Rework Exception Handling for IpSecManager
Update IpSecManager to use InetAddress and prefixLen
Add AppOps Checks for MANAGE_IPSEC_TUNNELS
Add MANAGE_IPSEC_TUNNELS Permission
LinkAddress constructors are currently @hide; this change updates
IpSecManager to use InetAddress and prefixLen, and then construct a
LinkAddress internally. LinkAddress is used over the binder interface to
IpSecService to ensure validity.
Bug: 77528639
Test: CTS, Java unit tests ran on walleye
Merged-In: I19e124adef6d9f4992d8293db3190bcf74c95848
Change-Id: I19e124adef6d9f4992d8293db3190bcf74c95848
(cherry picked from commit 3f2c54b782)
Add a new MANAGE_IPSEC_TUNNELS permission and
protect all IPsec Tunnel mode APIs with it.
This permission is only granted to the system or
through an AppOp.
Bug: 66955045
Test: compilation
Merged-In: I0f618373b500c493ef2211bece681f74652a1833
Change-Id: I0f618373b500c493ef2211bece681f74652a1833
(cherry picked from commit 159788455c)
There are a few small classes that never got properly
exposed as @SystemApi. These classes were not caught
because vendors currently build against the source
directly and have access to hidden APIs. We can not
change the vendor code at this point (different vendor
code for each year for all supported devices), but
we can start pulling back the API for new devices.
1) Keep all public mutable fields @hide and put
todo (and file bug b/74402619) to make fields
private or final.
2) Add public constructor that populates all fields
so that @hide public mutable fields can be set to
private/final in the future.
3) Provide getters for fields that will not be
public in the future.
In this way, we can make minimal API changes for P,
support new vendor/3rd party ImsServices, and phase
out old ImsService implementations that still build
against the source instead of using the correct
@SystemApi.
Bug: 77278031
Bug: 74402619
Test: Manual
Merged-In: Idbf2a71018f1bd06f8445b07fc52bc65cb6776f6
Change-Id: Ifa3b6d0cbdb12e92efc699b760ca874768a89a7c
This gives them a way to collect all included values without
resorting to manual probing of each newly added value.
Cherry-pick of ag/4052941 with minor conflicts in the imports.
Bug: 16207332
Test: atest com.android.cts.net.HostsideVpnTests
Change-Id: Ia764b3412bf834890612378e0c3846913f4e0a06
Merged-In: Ie5cd22cfa2b6a60510fd1e31d7ebcd8f6cc890a0
Merged-In: If07e77c92046807235229a4f67ee087bdd7bccf1
If you put values into the Builder, you should be able to observe
those values on the built object.
Clean cherry-pick of ag/3813257
Test: atest android.net.cts.NetworkRequestTest
Bug: 74945408
Change-Id: Ib28de279efb8b33ab46aa64f580e10fe5f8720e3
Merged-In: I0d090ebb7d57689a061badcf593ae9a37d88f7ce
Merged-In: I539184f7385c1f288cfb77be8307e4463e07e9e6
Some system apps should be able to request OEM_PAID networks. This
makes a lot of sense when Android is used as in-vehicle infotainment
systems.
Clean cherry-pick of ag/3782591
Bug: 68762530
Test: runtest -x frameworks/base/tests/net/ -c android.net.NetworkCapabilitiesTest
Change-Id: I306f060c5a386ff4b82cd99a03dc037ce60ded6a
Merged-In: Ic164c4a29cd449a31b2f1c12c8c345bcc5dc77fa
Merged-In: I6e9c4130db23a4f1c89ce7e9071ae519a2b0b7ec
Adding an API in MmTelFeature to allow IMS
Service to report the reasons for implicit
call rejections by lower layers. Corresponding
ImsReasonInfo codes are also being added.
The call rejections are not related to any
call session or a call that Framework is aware
of.
Change-Id: Ie47a239856db21e84d199a7620edf7b6ceeb81bc
There's an escape clause that passes the cross user permissions
if the caller UID is identical to the target user ID [eg. we're not
operating across users]. However, the method getInstalledPackagesList()
uses android.permission.INTERACT_ACROSS_USERS to filter the results and
a calling UID check is not sufficient. Ensuure the permission is
actually held, regardless of the calling UID or target user.
Change-Id: Iebf88668766d387a15246d6eea6420610665105a
Fixes: 80435086
Test: atest CtsAppSecurityHostTestCases:ApplicationVisibilityTest
Android Matcher.start(int) declared "throws IllegalStateException",
which is correct but redundant. Upstream OpenJDK8u121-b13 does not
have this declaration. Another CL in this topic drops the declaration,
without changing behavior.
Bug: 35910877
Test: Treehugger
Change-Id: I59778f13f0df8bd4112af4edc25ee5a93084ae35
This would be use to determine the right activity state during CTS
test for products that have windowSwipeToDismiss set.
Also, dump ActivityRecord.fullscreen to proto for the same reason.
Bug: 76207986
Bug: 79167358
Test: atest CtsActivityManagerDeviceTestCases:ActivityLifecycleTests
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerAssistantStackTests
Change-Id: Iadc088e9129be088b8a083ebbafd8d20fe26b673
Currently, KeyEvent.keyCodeFromString(String name) requires the string
to either start with "KEYCODE_", or be directly convertible to an int.
However, the string representation of every keycode starts with
"KEYCODE_", so this requirement is redundant. Relax this requirement to
alllow both of the following usages:
1) keyCodeFromString("KEYCODE_BUTTON_A")
2) keyCodeFromString("BUTTON_A")
Currently, only 1) is supported.
The other usage,
3) keyCodeFromString("29")
is unchanged.
The input is no longer case-sensitive.
Improved the example of usage in the documentation: the input
"1001" suggests that the string must contain binary representation for
usage 3), while in fact it is supposed to be a base 10 number.
Test: atest cts.KeyEventTest#testKeyCodeFromString
Bug: 36069459
Change-Id: I54d7f9d1270748854143cc9d1e8af48c9ec0cd0f
Marking some API's as deprecated, so users avoid getting confused.
Test: Test that build works.
Bug: 80099023
Change-Id: I4b3d4e4fa1ee3d706e49b8180aa4d0ad0e7d6eeb
You can post messages with an int or int+Object, query if they're posted, and cancel them. With a Runnable, however, prior to this change you could only post and cancel them.
Bug: 37015636
Test: existing
Change-Id: Icb9ba40ebb32fb962cec8a88e2222f68fe629057
DataService and NetworkService are System level classes. We shouldn't
hide their constructors otherwise their System level sub-class
can't be instantiated properly.
Test: gts
Bug: 77531655
Change-Id: I1a58b4857dbcf939ac124e20eb0a801ad5a9b597
Merged-In: I1a58b4857dbcf939ac124e20eb0a801ad5a9b597
This gives them a way to collect all included values without
resorting to manual probing of each newly added value.
Bug: 16207332
Test: atest com.android.cts.net.HostsideVpnTests
Change-Id: I35ca412512dc8515b44d5518e1ca4caa5bdc678f