As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Merged-In: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
@SuppressLint("Doclava125") is a legacy way of suppressing
RequiresPermission check. Updating to the new style of suppression
so metalava no longer has to support the legacy mode.
sed -i "s/@SuppressLint(\"Doclava125/@SuppressLint(\"RequiresPermission/" \
core/java/android/app/admin/DevicePolicyManager.java \
core/java/android/hardware/hdmi/HdmiControlManager.java \
core/java/android/hardware/location/ContextHubManager.java \
core/java/android/hardware/usb/UsbDeviceConnection.java \
core/java/android/net/TrafficStats.java \
core/java/android/os/RecoverySystem.java \
core/java/android/os/storage/StorageManager.java \
core/java/android/service/persistentdata/PersistentDataBlockManager.java \
location/java/android/location/LocationManager.java \
media/java/android/media/AudioManager.java \
telecomm/java/android/telecom/TelecomManager.java \
telephony/java/android/telephony/CarrierConfigManager.java \
telephony/java/android/telephony/TelephonyManager.java \
wifi/java/android/net/wifi/RttManager.java \
wifi/java/android/net/wifi/WifiScanner.java
Test: make
Exempt-From-Owner-Approval: No-op change
Merged-In: I6d5df95cfca2950ea86872d2f0afc1ba828841dc
Change-Id: I6d5df95cfca2950ea86872d2f0afc1ba828841dc
- CarrierMessagingServiceWrapper is now a final class with only
APIs of direct actions on messaging.
- The original abstract parts of the class are now interfaces:
interface CarrierMessagingServiceConnectionCallback
and Runnable callback.
- CarrierMessagingCallbackWrapper is renamed to
CarrierMessagingCallback
Bug: 172087216
Test: build and manual
Change-Id: I1760623543b929a51ce26dc7dcc5f8ebe7fd9732
Merged-In: I1760623543b929a51ce26dc7dcc5f8ebe7fd9732
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
The Ranking object of a notification update has lastAudiblylertedMs of
-1 if the notification did not buzz because a buzz happened within the
last 5s. This causes the bell icon to disappear on a conversation
where a person posted twice within 5s. This is resolved by copying the
lastAudiblyAlertedMs from the NotificationEntry's existing Ranking when
setting a new one, if the new Ranking's value is -1.
Bug: 156887617
Test: Update an alerting notification within 5s of update which caused an alert; bell should stay even though buzz is skipped.
Change-Id: Ibb72ab27c88cfa57add781e2746fff0eee5de6be
* For the case where the pinned inline suggestion triggers an
pending intent through the auth flow, and it returns a dataset
to be autofilled, previously we would replace the existing
dataset with the returned dataset. However, this is causing
several potential issues:
1. if the returned dataset doesn't contain inline presentation
the the pinned icon will not show again
2. if the returned dataset contains inline presentation but not
the pending intent, then the pinned icon will show up again
but tapping on it will not launch the pending intent
3. if the returned dataset contains the inline presentaion and
the pending intent, then when we "autofill" it, it'll fire
the pending intent directly as opposed to filling in the
value
* We fix the issue by not replacing the old dataset if the dataset
is a pinned inline suggestion.
* One caveat of the approach is that: a dataset can potentially
have multiple fields, and it's possible that some of the fields'
has inline presentation and some don't. It's also possible that
some of the fields' inline presentation is pinned and some isn't.
So the concept of whether a Dataset is pinned or not is
ill-defined. Here we say a dataset is pinned if any of the field
has a pinned inline presentation in the dataset. It's not ideal
but hopefully it is sufficient for most of the cases.
* An alternative approach is to have the autofill provider telling
whether they want to replace the old dataset or not, through
a new field in the returned Bundle. But that requres an API change
so is infeasible at this time.
Test: atest android.autofillservice.cts.inline
Test: atest android.autofillservice.cts.augmented
Test: atest android.autofillservice.cts.LoginActivityTest
Test: atest android.autofillservice.cts.AuthenticationTest
Bug: 159367101
Change-Id: I6d162aeb88a4655989c1aa315df8304c0980ac60
* Attach to each inline suggestion remote view the user id
and session id, which together identify a session. Then when
the session is destroyed, we release all the remote views
associated with the it.
* Worst scenario is that the IME is still showing the UI when
the remote view is released due to session destroy, in which
case the suggestion will disappear from the IME window. But
we also make sure we send an empty response to IME before
releasing the views, so it should be bad. Plus when a session
is destroyed, interacting with the suggestion UI doesn't do
anything, so it's not very helpful to show them.
* Also add a dump method to the InlineSuggestionRenderService
to help with debugging
Test: atest android.autofillservice.cts.inline
Bug: 154683107
Change-Id: I488fd9d9af08d0df3ffd3c851f96c567d07eed5a
Add possible conditions under which SystemUI may not prompt the user to
add a control.
Test: no test
Fixes: 159728016
Change-Id: I143e50cc15397d85b4212d9fb29d64df7c2de80c
