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
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
