Add methods to get mcc/mnc as strings so that the leading-zero
ambiguity is resolved.
Test: manual (db update), unit tests
Bug: 35064313
Change-Id: I45c0bfefb7ffe98e3eab8e68d0e1170881ae9f4c
- 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>
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Enable API user to create their own URLSpan for Linkify operations.
Test: atest android.text.util.cts.LinkifyTest
Test: atest android.text.util.LinkifyTest
Bug: 28536972
Bug: 32613009
Bug: 29150779
Change-Id: Ia4495dc7e656044b91a79804d3b50a30cae98225
Combination of moving to existing public API, tagging things as
@TestApi, and bringing utility methods into tests.
Bug: 13282254
Test: atest cts/tests/tests/os/
Change-Id: Ifd24c0d048d200e8595e194890cc1dc53ddc2b3e
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're reading data from credential
protected storage.
When a user is locked, credential protected storage is unavailable,
and files stored in these locations appear to not exist, which can
result in subtle app bugs if they assume default behaviors or
empty states. Instead, apps should store data needed while a user
is locked under device protected storage areas.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: Ia390318efa6fefda8f10ac684d0206e67aa1d3dc
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
We're almost out of bits, and we don't really need to smash both
thread and VM policy into the same 32-bit value, so use the lower
16-bits for each policy type and the upper 16-bits for penalty.
ActivityManager is only consulting the penalty bits, so we can
remove getViolationBit() and switch CTS over to doing instanceof
checks.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: I760e6a28f56da66dc75b7df9daf2167ff5bdff50
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're implicitly relying on
PackageManager filtering behavior.
For example, if the current Launcher isn't Direct Boot aware, we
hide it until the user is unlocked, which could confuse other Direct
Boot aware apps into thinking it had been uninstalled, which could
cause data loss.
This change helps apps track down places where they're implicitly
relying on the automatic filtering; they should instead carefully
choose a combination of MATCH_DIRECT_BOOT flags to decide on the
explicit matching behavior they want.
To implement this, we partially migrate the updateFlags() methods
out into ApplicationPackageManager, since the checking needs to
happen on the client side to correctly report StrictMode
violations. We don't currently mutate the flags, but we retain
the naming to keep that door open in the future.
Test: manual
Bug: 110413274
Change-Id: Iff6feba19da81ea1b4eeb3af821c3bdfbd9bf17c
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
was invoked by a hardware button.
bug: 110378156
Test: lunch bat_land-userdbyg && m; deploy and use the input activity in kitchen sink to verify voice.
Change-Id: I0f3ac2783b2ea0ce6298123b67e75911d168d876
Some permissions are getting split into foreground and background
variants. If an app only has the foreground version it can only access
the protected resource while the user is using it. Once the background
permission is added to the foreground permission the app can always
access the resource protected by the permission.
- Only having the background permission does grant anything.
- Mutliple foreground permission can share a single background permission,
but a foreground permission can not have multiple background
permissions.
- As the implementation of background permissions is based on AppOps
only the system can declare such foreground/background permissions
- A CTS test enforce that the background is in the same group as the
matching foreground permission.
Bug: 78788390
Test: Checked declared permission after boot and found new attributes
Change-Id: Ica7ba77b24345607c7467c41c982a58c39199024
* 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)
First step in unifying the window hierarchy that is currently split
within AM and WM packages. We separate the interfaces and service dealing
with activities and their containers (tasks, stack, display) from the
rest of AM interfaces and services. This will allow us to move the new
interfaces and services to WM when the internal states are cleaned-up.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: Ide9b3f89123b768cdbd3e3878113c7a8021187f3
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
