This behavior existed since autofill was introduced on O and it won't be fixed
on P, so there's no point on warning. In fact, the warning is often a red
herring for other issues, not to mention a big logcat spammer.
Bug: 35708678
Test: manual verification looking at logcat
Change-Id: I40be4ce25abc5b097ea67e5cb34bb9c4237f0826
If the given precomputed text is not compatible with the TextView,
reject the text by throwing IllegalArgumentException.
Bug: 73091756
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: I4fbf89a5f1409e8eefdeb9f208f9a3758220fe1a
(cherry picked from commit 3a0787af5e)
com.android.internal.* is meant to be hidden from documentation,
but most of it is erroneously not hidden via @hide or -hidePackage
directives; why documentation is currently generated for Predicate
but not other classes from com.android.internal.util, and why some
but not all classes from that package show up in package-level
documentation (package-summary.html), is not currently understood.
There appears to be a behavior difference between OpenJDK 8 and
OpenJDK 9's javadoc that results in additional classes showing up
in package-summary.html. This CL fixes this by adding -hidePackage
directives for com.android.internal{.util}; other sub-packages of
com.android.internal do not currently show up in documentation and
are not touched by this CL.
Test: Patched this CL into the internal-master branch and ran:
USE_R8=true EXPERIMENTAL_USE_OPENJDK9=true make offline-sdk-docs
Checked that this removes all documentation for com.*
(com.android.internal.util was the only com.* package for which
documentation was previously generated).
In other words: Before this CL, [1] existed, but after
this CL, the entire directory subtree [2] does not exist.
Test: Checked that Predicate was already missing from stubs before this
CL. In other words, [3] already did not exist before this CL.
[1] out/target/common/docs/offline-sdk/reference/com/android/internal/util/Predicate.html
[2] out/target/common/docs/offline-sdk/reference/com
[3] out/target/common/obj/JAVA_LIBRARIES/android_system_stubs_current_intermediates/classes/com
Bug: 69736344
Bug: 69736236
(cherry picked from commit 97bb6cf371)
Merged-In: Ic9757f4966f54092aac0191896581fa4222cc634
Change-Id: Ic9757f4966f54092aac0191896581fa4222cc634
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Exempt-From-Owner-Approval: Global cleanup
Change-Id: I26458e41ecb84de91ac9a356a5d4bafb44f463c1
restriction is on.
Check calling uid in isSettingRestrictedForUser(which is called by settingsprovider),
and only allow system_uid when certain user restriction is on, so that user won't be
able to change these settings with adb:
Settings.Secure.LOCATION_MODE,
Settings.Secure.PROVIDERS_ALLOWED,
Settings.System.SCREEN_BRIGHTNESS,
Settings.System.SCREEN_BRIGHTNESS_MODE,
Settings.System.SCREEN_OFF_TIMEOUT,
Settings.Global.AUTO_TIME,
Settings.Global.AUTO_TIME_ZONE.
This check also prevents 3rd party apps from modifying system settings value
when corresponding user restriction is on.
In addition, any attempt to change AUTO_TIME will also go through the check
for dpm.getAutoTimeRequired().
Test: manually by running the adb command with restriction set and not set
Bug: 72549013
Bug: 72548203
Bug: 72548533
Bug: 72686466
Bug: 72687105
Bug: 72940551
Bug: 72940562
Change-Id: I1d1fd20d9fa0f76f27905d62873f6a6e9af0224e
MediaPlaylistAgent is the abstract class an application needs to
derive from to pass an object to a MediaSession2 that will override
default playlist handling behaviors. It contains a set of notify*
methods to signal MediaSession2 that playlist-related state has
changed.
Bug: 64098437
Test: make update-api
Change-Id: Icb3c57ddc14eba276f49d4ba85f11adbeb3e0917
Added callback for session to know the currently playing media item has
changed.
Note that the callback is called in response to the
MediaPlayerBase#PlayerEventCallback#onCurrentDataSourceChanged(mpb, dsd
is called. Session will translate dsd to the media item and calls
onCurrentMediaItemChanged().
Following changes are also included
- Removed MediaPlaylistController#getCurrentPlaylistItem(),
because currently playing item is managed by the MediaPlayerBase.
- Renamed ControllerCallback#onCurrentPlaylistItemChanged() to the
ControllerCallback#onCurrentMediaItemChanged(), to make it more
obvious that the event is from MediaPlayerBase, not
MediaPlaylistController.
- Added SessionCallback#onCurrentMediaItemChanged()
Bug: 64098437
Test: Run MediaComponents test
Change-Id: I78b124a7da0f968b097b2576507b9a73e36081ec
This allows a developer to create DataSourceDesc when the item is about
to be played. Typical example of the usages are,
1. For a playlist consists of FileDescriptors, its developer may not
want to open all files when MediaSession2.setPlaylist() is
called.
2. A controller has called setPlaylist(), addPlaylistItem(), or
replacePlaylistItem(). Controller cannot know the
DataSourceDesc, and only the session developer can know about
it.
Bug: 64098437
Test: Run MediaComponents test
Change-Id: I73f27ca0a799b1cddf5046b41f0ca01d08037103
Overlaying an album with wallpaper colors isn't optimal.
Using the album extracted color also isn't optimal, the color probably
won't meet accessibility guidelines and will have to be stretched
according to the current lock screen theme - which can be even worse.
Test: atest packages/SystemUI/tests/src/com/android/systemui/colorextraction/SysuiColorExtractorTests.java
Change-Id: I53d08713716bd76ee0975c2b4bba5b933201f999
It is possible to a display to be removed while we are in the ctor of
ActivityDisplay in AM, but before we can get the Display object in the
ctor of DisplayWindowController in WM. This causes us to throw an
exception becuase the caller is trying to add a display we can't find in
display manager. Unfortunately there isn't a good way to handle this race.
To work around it we will now pass the Display object from AM to WM to use
and depend on the fact that AM will remove the display shortly after.
Change-Id: Ie3f9d86bad67f5a023e3e7dfce5219b98c796864
Fixes: 72893961
Test: go/wm-smoke
