The new format is described in tools/metalava/FORMAT.md.
Fixes: 116589402 Switch signature files over to the v2 format
Fixes: 112626813 Drop "synchronized" modifier from the signature format
Fixes: 122358225 Omit overriding methods that only differ in final [...]
Fixes: 73088715 API Review: Need doclava to output nullability
Fixes: 79739773 API Review: Metalava enforcing constants are constant
Exempt-From-Owner-Approval: Large-scale tooling change
Test: make sdk, make update-api, make checkapi
Change-Id: Ia248aece5250e84e47c815c601133b698bf644c2
The impl lib name of java_sdk_library is changed to {module_name}.jar
instead of {module_name}.impl.jar
android.test.mock.impl is removed from stubs_defaults.
RepetitiveTest class is added to public API in android.test.base
Bug: 110404779
Test: m -j
Change-Id: I5dd7f3a28bc22136b4e921de3eb5a3e77e5fc75f
android.test.mock, com.android.location.provider and
com.android.mediadrm.signer libraries are change to using metalava
instead of doclava.
Test: m -j
Bug: 117127012
Change-Id: I82e838ab60110698e1c0ea8e567467a1b32707ce
Entries from DownloadProvider are added to MediaStore Downloads
collection. COLUMN_MEDIASTORE_URI will be used to track corresponding
entries in MediaProvider. We can't re-use COLUMN_MEDIAPROVIDER_URI
for this purpose because it is updateable by apps.
Bug: 120876251
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifd252c54f4ee739a31be2866896efac6696a088e
This change adds RollbackManagerService as a new system service for
managing apk level rollbacks.
To work properly this requires additional selinux policy changes. Fails
gracefully in case of selinux denials, until we have a chance to sort
out the proper selinux policy.
Bug: 112431924
Bug: 116512606
Test: atest RollbackTest, with selinux enforcement off.
Test: atest CtsPermission2TestCases:PermissionPolicyTest
Change-Id: Id72aae9c4d8da9aaab3922ec9233ba335bc0198f
Existing APIs that accept a ContentResolver are too restrictive when
the caller has their own ContentProviderClient already bound and
configured, so we're in the market for a solution to open those
existing APIs to accept a wider range of inputs.
The solution we've come up with is to introduce a super-interface
which contains the common ContentProvider APIs, and then make
ContentProvider, ContentResolver, and ContentProviderClient all
implement that interface for consistency.
After this change lands, we can then safely relax existing APIs to
accept this new ContentInterface, offering a clean path to solving
the problem outlined above.
Bug: 117635768
Test: atest android.content.cts
Test: atest android.provider.cts
Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e
Exempted-From-Owner-Approval: keep tests working
This will allow apps to better manage many isolated processes,
telling the system how they are grouped together (so should be
managed as one related entity within the LRU cache) and fine-tune
the ordering within that group.
The API is not yet tested... though in theory it is implemented.
But the implementation done for that also fixes a *lot* of problems
with activity LRU management that, even without groups, should
make the ordering of processes in the LRU list much more consistently
match how recently the user has interacted with it.
Also clean up some of the new dumpsys output in the activity manager:
move the new sections to before the process output (so it is still
easy to see the process state at the end of the output), and add and
document the command line options for controlling them. And add a
new "lru" section that gives a clear view of what is going on with
the raw LRU list.
An upcoming change will add tests for the new grouping functionality,
and probably some fixes resulting from that.
Test: atest CtsAppTestCases:ServiceTest
Bug: 111434506
Change-Id: I1f6b6b9de66ccde1573e1a0e9615e8c5f8e6c0d7
This allows clients to run multiple instances of the same
manifest service declaration. It only works for isolated
services, to avoid too much abuse temptation. This is part
of the "Chrome site isolation" work, to allow chrome to have
many more render processes running and help it manage them.
Bug: 111434506
Test: atest CtsAppTestCases:ServiceTest
Change-Id: I22e65758678a07075ed32ed6463082ddf846d3a4
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
The new property is added for supporting metalava. But some sdk library
cannot use metalava. So "metalava_enabled: false" is added to these
modules.
Test: make -j
Test: checkapi
Bug: 117127012
Merged-In: Ib65f3cd73dac0ac6ed64afeca6546d99739e4424
Change-Id: Ib65f3cd73dac0ac6ed64afeca6546d99739e4424
(cherry picked from commit 558e702be0)
The new property is added for supporting metalava. But some sdk library
cannot use metalava. So "metalava_enabled: false" is added to these
modules.
Test: make -j
Test: checkapi
Bug: 117127012
Change-Id: Ib65f3cd73dac0ac6ed64afeca6546d99739e4424
The PermissonController is going to become a mainline module, hence it
has to compile against @SystemApi.
PackageManager#arePermissionsIndividuallyControlled controls how certain
permissions are presented in the UI, hence Permission controller needs
to read it. The value of this API comes from a config option.
Bug: 110953302
Test: Built
Change-Id: If78b1bb594af0c85e92abf70ae8315e7ba3f31fa
android.test.* are built with java_sdk_library and api files are added
by running "make update-api".
android.test.base_static is created for allowing to use
android.test.base as a static library.
Bug:77577799
Test: make -j
Test: make checkapi
Test: make checkapi fails with a random change in the txt file
Test: adb shell cmd package list libraries |\
grep android.test.*
And check the android.test.* libraries
Merged-In: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
Change-Id: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
android.test.* are built with java_sdk_library and api files are added
by running "make update-api".
android.test.base_static is created for allowing to use
android.test.base as a static library.
Bug:77577799
Test: make -j
Test: make checkapi
Test: make checkapi fails with a random change in the txt file
Test: adb shell cmd package list libraries |\
grep android.test.*
And check the android.test.* libraries
Change-Id: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
This splits the
- review permissions
- individually control permissions
- consent to manage wireleess (wifi + bluetooth)
properties.
Almost all code cares only for the first and it is now always true.
Hence a lot of code can be simplified.
Bug: 110431654
Test: atest PermissionsHostTest
started pre-M app
Change-Id: I733cd476ccd0bf5eaa59e9a9506db34f57c6baee
Adjust the build rules of android.test.*.stubs packages to also
produce a jar with dex files. This will be used by the `hiddenapi`
tool to categorize the boot class path equivalents as public API.
Bug: 79409988
Test: m android.test.base.stubs ; check javalib.jar contains dex
Merged-In: I1d0850b18044c559ea4b9893d929dc45884b32c3
Change-Id: Ief28cd5e6d0cdd58f22fab751e0173ccf8c69a0c
Adjust the build rules of android.test.*.stubs packages to also
produce a jar with dex files. This will be used by the `hiddenapi`
tool to categorize the boot class path equivalents as public API.
Bug: 79409988
Test: m android.test.base.stubs ; check javalib.jar contains dex
Change-Id: I1d0850b18044c559ea4b9893d929dc45884b32c3
Most jars don't need to be installed on the device. Instead of
using java_library and java_library_static to distinguish between
them make java_library and java_library_static identical and use
installable: true to identify the few jars that need to be dexed
and installed on the device.
Bug: 110885583
Test: m checkbuild
Change-Id: I579da7c1a712ec4fb49e288e7f3ab369cb75baf4
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
Stubs libraries android.test.mock.stubs and
android.test.mock.stubs-system are now built in Android.bp.
(Note that API check and update are still done in Android.mk)
As a good side effect, this allows android.test.runner[-minus-junit]
libraries (that are defined in Android.bp) to be built with the
android.test.mock.stubs instead of the runtime library
android.test.mock. This in turn allows us to prevent java:sdk ->
java:platform dependency also in Soong, because the runner libraries
were the only violators.
Bug: 73829976
Test: m -j android.test.mock.stubs android.test.mock.stubs-system
Test: m -j checkapi
Test: m -j update-api
Merged-In: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
Change-Id: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
(cherry picked from commit e649b8066c)
Unbundled builds use the prebuilt libs in /prebuilts/sdk/current and
system_current.
Bug: 73829976
Test: m -j ANDROID_BUILDSPEC=vendor/google/build/app_build_spec.mk
Merged-In: I61fe0d671778595f49be82d7c11caffc411f58a3
Change-Id: I61fe0d671778595f49be82d7c11caffc411f58a3
(cherry picked from commit ea93a9ebc2)
Stubs libraries android.test.mock.stubs and
android.test.mock.stubs-system are now built in Android.bp.
(Note that API check and update are still done in Android.mk)
As a good side effect, this allows android.test.runner[-minus-junit]
libraries (that are defined in Android.bp) to be built with the
android.test.mock.stubs instead of the runtime library
android.test.mock. This in turn allows us to prevent java:sdk ->
java:platform dependency also in Soong, because the runner libraries
were the only violators.
Bug: 73829976
Test: m -j android.test.mock.stubs android.test.mock.stubs-system
Test: m -j checkapi
Test: m -j update-api
Merged-In: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
Change-Id: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
(cherry picked from commit e649b8066c)
Unbundled builds use the prebuilt libs in /prebuilts/sdk/current and
system_current.
Bug: 73829976
Test: m -j ANDROID_BUILDSPEC=vendor/google/build/app_build_spec.mk
Change-Id: I61fe0d671778595f49be82d7c11caffc411f58a3
Stubs libraries android.test.mock.stubs and
android.test.mock.stubs-system are now built in Android.bp.
(Note that API check and update are still done in Android.mk)
As a good side effect, this allows android.test.runner[-minus-junit]
libraries (that are defined in Android.bp) to be built with the
android.test.mock.stubs instead of the runtime library
android.test.mock. This in turn allows us to prevent java:sdk ->
java:platform dependency also in Soong, because the runner libraries
were the only violators.
Bug: 73829976
Test: m -j android.test.mock.stubs android.test.mock.stubs-system
Test: m -j checkapi
Test: m -j update-api
Change-Id: I830a8eb13aa43b9aa4c8394f3c2fd91ee18b1f85
Changed the existing hidden api setPackagesSuspendedAsUser to a system
api setPackagesSuspended that can be called by apps with either
MANAGE_USERS or SUSPEND_APPS permission. Additionally, the suspending
app can now specify optional extra information meant to be used by the
suspended apps and the launcher to deal with this state.
The following other APIs are added:
- isPackageSuspended(): Apps can query whether they are in a suspended
state
- @SystemApi getPackageSuspendedAppExtras(String): Apps with permission
SUSPEND_APPS can get the appExtras passed to PM when suspending the
app.
- @SystemApi setPackageSuspendedAppExtras(String, PersistableBundle):
Apps with permission SUSPEND_APPS can update app extras for a
suspended package.
- getPackageSuspendedAppExtras(): Apps can call to get the appExtras
passed in to PM when they were suspended.
Test: Can be run via:
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.SuspendPackagesTest
Bug: 74336673
Change-Id: I3b9ed2c8478b34ee2e8986f5f5fddb2839d102e3
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
bedfae9801 removed the repackaged test
mock library but left the jarjar rule file used to build the lib.
Removing the leftover.
Test: m -j
Change-Id: I9e3d65ff2801af3fb363c1608c14734bca9d9434
The repackaged.android.test.mock uses internal APIs so cannot be built
against the SDK which means that anything that depends on it cannot
guarantee to run if those internal APIs change.
That library was built because the classes in
repackaged.android.test.runner depend on them. However, the
repackaged.android.test.runner library is only used by the
cts-api-signature-test target and it does not use any android.test.mock
classes directly, or indirectly. Therefore, this simply excludes any
classes from repackaged.android.test.runner that depend on
android.test.mock classes so that repackaged.android.test.mock can be
removed altogether.
Bug: 69899800
Bug: 30188076
Test: make checkbuild
Change-Id: If4528e6a4ec2b08faffd6d413672c5004d85e0a9
android.test.legacy is now build against SDK, thus available to apps
build with SDK.
In doing so, android.test.mock.stubs had to be built with SDK (because
it is used by android.test.legacy). However, this wasn't trivial.
The problem was that some classes in test-mock implemented abstract
methods of platform classes. Even though they are marked as @hide,
doclava automatically emit them to the stub file because otherwise the
class in the stub file does not implement some abstract methods from its
parent class, which in turn makes the stub file non-compilable.
This CL solves the problem by introducing an adapter class in between
the class in test-mock and the class in the framework. The adapter class
implements abstract methods which are @hide and having reference to
types that aren't available to SDK. The abstract methods are removed
from the original class. Then doclava does not emit the abstract
methods.
Also by @hide'ing the adapter classes, they are not compiled when
building the stub library.
Bug: 30188076
Bug: 73339598
Test: m -j android.test.base
Test: m -j android.test.legacy
Test: m -j android.test.mock.stubs
are successful and do not show link-check warning
Merged-In: I8e432950e693ee3c6f0240852e62da6133d31571
Change-Id: I8e432950e693ee3c6f0240852e62da6133d31571
- Add two shortcut related permissions as SystemAPI for the default
text classifier.
- The default text classifier package name still comes from the
system resource.
Bug: 73083596
Bug: 71555985
Test: atest CtsPermission2TestCases
Test: Manual test with a test package, with the following in config.xml
<string name="config_defaultTextClassifierPackage" translatable="false">com.example.android.pm.shortcutlauncherdemo</string>
Change-Id: I19081d9d6ba0b33eb25d19aa55b4fe2f26a75897
android.test.legacy is now build against SDK, thus available to apps
build with SDK.
In doing so, android.test.mock.stubs had to be built with SDK (because
it is used by android.test.legacy). However, this wasn't trivial.
The problem was that some classes in test-mock implemented abstract
methods of platform classes. Even though they are marked as @hide,
doclava automatically emit them to the stub file because otherwise the
class in the stub file does not implement some abstract methods from its
parent class, which in turn makes the stub file non-compilable.
This CL solves the problem by introducing an adapter class in between
the class in test-mock and the class in the framework. The adapter class
implements abstract methods which are @hide and having reference to
types that aren't available to SDK. The abstract methods are removed
from the original class. Then doclava does not emit the abstract
methods.
Also by @hide'ing the adapter classes, they are not compiled when
building the stub library.
Bug: 30188076
Bug: 73339598
Test: m -j android.test.base
Test: m -j android.test.legacy
Test: m -j android.test.mock.stubs
are successful and do not show link-check warning
Change-Id: I8e432950e693ee3c6f0240852e62da6133d31571
