This change adds a feature flag that specifies the date associated
with the Vulkan dEQP tests that a device claims to pass.
Bug: 136573508
Change-Id: I0cec29fe5f69f228faaa2298b7f5b65bcf988dba
I've added this to ContentProvider since it's where all of the existing
hidden logic where userinfo = userid lives.
Bug: 136249261
Test: atest CtsProviderTestCases:android.provider.cts.DocumentsContractTest
Change-Id: I3a815f2c8dd738140aec6937ce0d3b763bf49fba
When the admin unsets cross-profile packages, reset the
INTERACT_ACROSS_PROFILES app-op back to the default if it is no longer
configurable by the user.
Other minor changes:
- Remove the explicit app-op permission check from
setInteractAcrossProfilesAppOp, since AppOpManager performs that check
when required.
- Fix the broadcasting logic in CrossProfileAppsServiceImpl to correctly
set the component and flags.
Bug: 136249261
Bug: 148010178
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.ManagedProfileCrossProfileTest
Change-Id: Ib8b5f331fb92fc475bc95ad039adf93fac04da37
Feedback advised renaming getBackgroundPermissionButtonLabel to
getBackgroundPermissionOptionLabel. Also update javadoc for this
method.
Fixes: 147907758
Test: Compile
Change-Id: Iaafef7c6e70538fe878db82c900d87ac668591bf
ConnectivityDiagnosticsManager should be accessed through
Context#getService. In order for this to be possible, it needs to be
defined as a service inside SystemServiceRegistry.
Bug: 146444622
Test: compiles.
Test: CTS testing in aosp/1211164
Change-Id: I6fe29441ecc9967a04ceb394b3bbe54830bef079
This adds a new ApexContext class as a system API. Methods are included to
obtain paths to the APEX data directories.
In future the aim is for this ApexContext to be provided to code running
within an APEX automatically, so that data directory paths are available
only to the APEX that should access them. For R it is not feasible to
implement this, so for now a factory method is included to create an
ApexContext from the apex (module) name.
See go/apex-context-r for more information.
Bug: 141148175
Bug: 142484007
Test: ApexContextTest added
Change-Id: Iaf90e12383aa219a73a7818dab6cde6a850597ba
Changed APIs in PermissionChecker to check if the permission is an appop
permission or a runtime permission and treat it accordingly.
BUG: 140728653
BUG: 136249261
Test: atest PermissionCheckerTest
Change-Id: I742dad5b0e1e9cd65920f0366f1887ab33959f5b
It's unnecessary as it will be done on commit anyway.
This allows to make transfer simple and blocking.
Test: atest PackageManagerShellCommandTest
Bug: b/136132412
Change-Id: Ib017c6dc8a845a7d72898b0c0032c17932375c96
* Changed ApnSetting to use constants instead of hardcoded strings for clarity.
* Made isDataCapable a public api.
* Removed feature flag android.hardware.telephony.data and opted for a resource
config setting instead.
Bug: 146206136
Test: FrameworkBaseTests, FrameworkOptTests
Change-Id: I19ac83f5865e8763cd9414c41d4609f79d0db164
This adds the apex name (a.k.a. apex module name) to ModuleInfo, and adds a
flag to allow the apex name to be used when calling getModuleInfo.
The existing ModuleInfoFlags was only used for getInstalledModules, so it
has been renamed accordingly.
See go/apex-package-info-discovery
Bug: 141149569
Test: added apex name checks to ModuleInfoProviderTest
Change-Id: I5bcfaa0ef227f3b4eca963e57de4d25c08676c9c
To be used to configure foreground service camera/microphone
while-in-use permission.
For apps with targetSdkVersion R and above, a foreground service
will not be able to access camera/microphone if the foreground service
type is not specified in the manifest and in
android.app.Service#startForeground().
Bug: 136219221
Test: atest android.app.cts.ActivityManagerProcessStateTest
Change-Id: I75c62efca5f07ba1239e21d9a6f6673f822eabba
Add new manifest tags for declaring processes that an app
will use. While declaring these processes, one can specify
specific permissions that will be denied to that process.
Doing so will result in any gids associated with that permission
from being given to that process, and any permission checks
that include a pid (which is not all of them) will fail when
checking a permission for that process.
For now, we limit these declarations to only the internet
permission, since we really need to do a lot of auditing to
determine how many other permissions can be denied (based on
how many permission checks for it are including the pid).
That said, this is explicitly not a security guarantee, so it
isn't a problem if there are ways around it (the process could
always IPC to another of the app's processes to do the same
thing).
One thing to be done is have the parser enforce that once an
app declares processes, it can only run things in those processes
and no others.
At this point the code is not yet tested at all. That will be
coming in later. This gets the APIs and various infrastructure
in place.
Bug: 143085640
Test: not yet tested
Change-Id: I27e8d0c811a5004fe251883f243517bb00d32d67
This allows apps to specify the minimum versions they need
of extension sdks, and fails install if they aren't met.
There is additional work required to prevent local rollbacks
from triggering a downgrade of SDK versions after an install.
Bug: 137191822
Test: atest PackageParserTest
Exempt-From-Owner-Approval: PS4 was approved
Change-Id: If61ae6c67ceb752bec6876006a29e52b996901e7
