Add the necessary APIs that will allow Camera2 clients to access
and work with existing CameraX extensions.
Bug: 170481080
Test: Camera CTS
Change-Id: Iaa22fea69ebe01599b3f2e66c1b46ca92015cdc5
These changes have to be in this CL together because:
- Code in service-permission depends on IRoleManager in
framework-permission, so the APIs in framework-permission and the code
in service-permission need to be moved together.
- The changes to service-permission build rules doesn't make sense
without the code moved in, so they have to be together as well.
Other details:
- framework-annotations: Several annotations are added into
framework-annoatations. Since the discussion with API council seems to
allow user IDs in system server in-process APIs, @UserIdInt and
@AppIdInt is added. @MainThread and @AnyThread is added since
@WorkerThread is already added. @CallSuper is added since @CheckResult
is also already added and they are similar in terms of category of
functionality.
- framework-permission-s-shared-srcs: 3 classes (and 2 AIDL files)
from framework is copied as shared source files and jarjared for
framework-permission, and an additional 3 is added for
service-permission as service-permission-shared-srcs. Similar to
framework-wifi and service-wifi, the 3 classes in framework-permission
is also available to service-permission by the stub library
framework-permission-pre-jarjar, and the other 3 classes used only for
service-permission is included separately to minimize our impact on
classes loaded into boot classpath. framework-permission and
service-permission shares the same jarjar rules to make sure the
classes remain available, and for the same reason framework-permission
cannot be shrank during any optimization.
- framework-permission-s-shared: A java_library target for
framework-permission-shared-srcs is created to make sure that the
public classes won't be counted as APIs, as it would be if directly
included as srcs for framework-permission
java_sdk_library. service-permission-shared is the same thing for
service-permission.
- framework-permission-s: A new java_sdk_library target created to be
loaded into bootclasspath by Android S+.
- Dumpsys Protobuf: The dumpsys protobuf
file (rolemanagerservice.proto) is moved into the module, and both the
platform (incident.proto) and the module uses protoc-gen-javastream to
generate the Java classes from it. This should be fine since it's a
"source level inclusion", and we jarjar the generated classes in our
module to avoid conflict with platform copies.
Bug: 158736025
Test: manual
Test: device boots, default apps can be changed successfully.
Change-Id: I1914774f631e51d0c587a7e527a1c9bc05ee1595
- Media module needs to extract the component that a PendingIntent will
be sent to.
Currently, the code is bundled, so they're using the hidden
PendingIntent.getIntent() API, but we really do not want to make it @SystemApi.
So instead, adding a way to obtain the resolve information instead.
- !!Media should make sure the resolved components are actually owned by the
same package that called the API!!
Bug: 161334442
Test: not available yet
Change-Id: I09fc2e0bb23434394caadc638f48c05548376548
Bug: 175370724
Test: Simulate call end reason from vendor code and check IMS call
end reason is correctly mapped.
Change-Id: I12e7a0401a4eb74b66ef53ce789410a9bf7b9770
Adding a new public system feature constant that must be expressed by
devices that support Android's security model as documented in
the CDD.
Test: Build
Bug: 173540259
Change-Id: Ib651ab31cba065fc9b2a28d8ac16eaa85357f252
- Add PackageManager system features (with versions) for the normal
and direct access store
- Deprecate IdentityCredentialStore.deleteCredentialByName() and add
IdentityCredential.delete() as a replacement.
- Add IdentityCredential.proveOwnership()
- Add IdentityCredential.update()
- Add docs for ProofOfBinding CBOR in X.509 extension of certificate
for AuthenticationKey
- Add IdentityCredential.setAllowUsingExpiredKeys()
- Add version of IdentityCredential.storeStaticAuthenticationData()
which takes a an expiration date. Deprecate the old variant of
this method.
Bug: 170146643
Test: atest android.security.identity.cts
Change-Id: I39a0ed65ed6efaa424ada7a9495e3b1da67cf452
Since IKE APIs to negotiate IPsec tunnel migration (MOBIKE) are
public, all IPsec tunnel APIs should also be public so that public
callers are able to create, manage and migrate IPsec tunnels
Bug: 174606949
Test: atest IpSecManagerTunnelTest
Change-Id: I86aec334cfc937953f9c2b411cc55862032aae4d
Introduce set/clearSignalStrengthUpdateRequest in TelephonyManager
and ITelephony to support customized signal request from applications.
Bug: 164432835
Test: atest android.telephony.cts.TelephonyManagerTest
Change-Id: I749376872915a91b9514884547140eaf969dba0e
This reverts commit 8ce575b256.
Bug: 176163590
Bug: 148500541
Test: manual smoke test on low-end device and aosp_crosshatch builds.
Reason for revert: Reapplying with a fix for the exceptions.
The exceptions were caused by an undocumented behavior difference in the APIs that just blindly catch runtime exceptions. The cause of the runtime exceptions is that people are calling isDataEnabled() before telephony is running; however, until a "better" fix is available, this API will apply the existing behavior of just catching the runtime exceptions (which is terrible, but it's the plan of record in the code today).
Change-Id: I9fbe7126ee7039dfb0b383f83017458a3525db66
If configuration_optional is present, the widget provides a default
configuration. The host may decide not to launch the provided
configuration activity.
Design doc: go/deferrable-widget-config
Test: Successfully built blueline-userdebug. Since this CL only adds
a new value for an existing field, no unit test will be added at this
point. Once we introduce unit tests for widget configurations xml, we
will add related unit tests.
Bug: 177977976
Change-Id: I507cba0b9b8900f9b9616d76c48eb0ed9c50ed72
Exported components that are not guarded by a signature permission
can receive Intents from any other app on a device. If an app unparcels
and launches an Intent from the Intent delivered to this unprotected
component then a malicious actor can potentially craft an Intent that
could launch hidden components, grant URI permissions, etc. This
commit adds a StrictMode check to report if a component launches an
Intent unparceled from the delivered Intent.
Bug: 160796858
Test: atest StrictModeTest
Change-Id: I763b8a965f91f5b433ce2f4b619e10ef12f5c296
