When APIs are refactored mid-release, they can often be left marked
as @Deprecated with the intention of eventually removing them before
the SDK is finalized.
Well, the time has come to finalize the SDK, so let's clean them up.
Bug: 189325658
Test: manual
Change-Id: I48e3e1c1306fbaf071e4acfd9e8107e6ad564ffe
SipDelegateImsConfiguration should not be included in the final
API.
Bug: 186118835
Test: atest CtsTelephonyTestCases
Change-Id: I6321ac6d0c9fbcc4258d1a068934d1116b1819cf
We introduced some APIs for initial demo but we dropped these APIs.
To avoid to break the client app, we keep the API until the client
moves to new APIs. It's ok to delete these API now.
Bug: 185448758
Test: manual
Test: atest android.translation.cts.UiTranslationManagerTest
Change-Id: I5ea71d4658246f52610e1f62412d60c6c58bb31e
Recent work has introduced a new "Nearby devices" runtime permission
which protects all existing Bluetooth APIs; we've done this by
defining a <split-permission> to convert the old BLUETOOTH and
BLUETOOTH_ADMIN permissions into one of three new permissions:
* BLUETOOTH_ADVERTISE: Required to be able to advertise to nearby
Bluetooth devices.
* BLUETOOTH_CONNECT: Allows applications to connect to paired
bluetooth devices.
* BLUETOOTH_SCAN: Required to be able to discover and pair
nearby Bluetooth devices.
At its core, this change begins updating the Bluetooth APIs to have
correct @RequiresPermission indicating which permission is actually
enforced internally. To ensure alignment across Binder, the newly
added "RequiresPermissionChecker" Error Prone checker was used to
discover any inconsistencies, ensuring correctness from server-side
enforcement up through to the public APIs.
In addition, since developers will continue building apps for both
modern and legacy platforms, this change introduces new auto-doc
annotations which will emit helpful consistent documentation
describing the behavior of older devices that are still using the
old permission model.
Bug: 183626724
Test: ./build/soong/soong_ui.bash --make-mode Bluetooth RUN_ERROR_PRONE=true
Change-Id: I02aa127e8e07f239561f4f2a3bbdfc6fccb82f7f
Keep the implementation and Add @Deprecated and @remove for the
deprecated APIs. Use this way can make sure the client doesn't
crash if not updated but when app recompiles would be forced to move
to the new APIs.
Bug: 177789967
Test: Use the app that uses old APIs doesn't crash. When app would
like to recompile cannot see the old APIs.
Change-Id: I700470eaca2df030e50de964be5be2173c89259f
This achieves two things:
- it's been noted that non-updatable-api is a confusing term as it has
to be updated every time the API changes
- the api-review logic trigers on txt files in subdirs named 'api',
which non-updatable-api does not trigger on
I will (less urgently) try to get rid of the term "non-updatable" from
other places too, perhaps going for "non-module" or "core" as a
replacement.
Bug: 171029603
Test: m checkapi
Change-Id: I843efb4880b6caaf3872e9b0918fd710fb93d979
This achieves two things:
- it's been noted that non-updatable-api is a confusing term as it has
to be updated every time the API changes
- the api-review logic trigers on txt files in subdirs named 'api',
which non-updatable-api does not trigger on
I will (less urgently) try to get rid of the term "non-updatable" from
other places too, perhaps going for "non-module" or "core" as a
replacement.
Bug: 171029603
Test: m checkapi
Change-Id: I843efb4880b6caaf3872e9b0918fd710fb93d979
Merged-In: I843efb4880b6caaf3872e9b0918fd710fb93d979
