- Addition of getTypeAllocationCode & getManufacturerCode to
android.telephony.TelephonyManager.
- The Type Allocation Code is the first eight characters of the IMEI.
The Type Allocation Code identifies a particular GSM device model.
- The Manufacturer Code is the first eight characters of the MEID.
The Manufacturer Code identifies the manufacturer of a CDMA device.
- The reasoning behind adding getTypeAllocationCode is to be
able to obtain the Type Allocation Code without requiring the
READ_PHONE_STATE permission. Currently in order to obtain the
Type Allocation Code a substring operation must be performed on
getImei which is protected by the READ_PHONE_STATE permission.
- The reasoning behind adding getManufacturerCode is to be
able to obtain the Manufacturer Code without requiring the
READ_PHONE_STATE permission. Currently in order to obtain the
Manufacturer Code a substring operation must be performed on
getMeid which is protected by the READ_PHONE_STATE permission.
- The reasoning that these additional methods do not require the
READ_PHONE_STATE permission is that neither the Type Allocation
Code nor the Manufacturer Code can identify a unique device.
The Type Allocation Code and the Manufacturer Code are analogous
to other device information such as device model or device
screen dimensions.
Test: run cts -m CtsTelephonyTestCases
Bug: 74613795
Change-Id: I5a586b5a362b39aae13357329efb19eb93f0434c
Signed-off-by: David Kelly <dkelly@afilias.info>
Allow send sms over ims to emergency number when the device is in
lte/limited lte mode without normal ims registration.
Modem will use emergency ims pdn to submit sms to network.
Change-Id: I5762102c695fe309a4a5b318abccded5c50154e0
Bug: 110462046
This is not really an API change because PatternSyntaxException
is unchecked (extends RuntimeException). The behavior has not
changed (PatternSyntaxException can still be thrown).
Bug: 109659282
Test: Treehugger
Change-Id: I5759eee10b27307b68f15fdd6f6f1a258ee01529
* 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
Marking some API's as deprecated, so users avoid getting confused.
Test: Test that build works.
Bug: 80099023
Change-Id: I4b3d4e4fa1ee3d706e49b8180aa4d0ad0e7d6eeb
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
A broad category of apps such as wearable companion apps and call blocking
apps rely on the ability to reject a ringing call.
Previously this was achieved using a broken TelephonyManager API which
lacked permission checks.
To support these applications, removing the @hide attribute on the existing
TelecomManager#endCall API so that apps with the existing
ANSWER_PHONE_CALLS permission can reject ringing calls and end ongoing
calls. Logically if an app has permission to answer a call, it should be
able to end it.
Test: Created test app to verify API permission checks.
Test: Added new CTS tests to cover this API.
Bug: 78290258
Merged-In: Ic6527969793ebe05eb9c5fa8205558ae788ea572
Change-Id: Ic6527969793ebe05eb9c5fa8205558ae788ea572
This doesn't make sense on things like watches and appliances,
so make this an optional feature that the device must enable.
If the feature is not set, then the system will ignore
the app's request.
Bug: 76213401
Test: atest CtsAppTestCases:ActivityManagerProcessStateTest
Change-Id: I91abf9d86ec14fa632e3bcc83c4a3febade5d2e4
A broad category of apps such as wearable companion apps and call blocking
apps rely on the ability to reject a ringing call.
Previously this was achieved using a broken TelephonyManager API which
lacked permission checks.
To support these applications, removing the @hide attribute on the existing
TelecomManager#endCall API so that apps with the existing
ANSWER_PHONE_CALLS permission can reject ringing calls and end ongoing
calls. Logically if an app has permission to answer a call, it should be
able to end it.
Test: Created test app to verify API permission checks.
Test: Added new CTS tests to cover this API.
Bug: 78290258
Change-Id: Ic6527969793ebe05eb9c5fa8205558ae788ea572
