Symptom:
When the device language was set to Spanish, "A.M." label was not fully
displayed on the time picker widget. "M." was lacked.
Root cause:
There are unnecessary right paddings on the layout definition of time
picker. It uselessly consumes the room for ampm_layout.
Bug: 64498105
Change-Id: Ie52fafc0fb7d6d6ea5b0ca2eaeb53755d4aebc19
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
Greylist APIs from public requests which used to be off-limits because
the classes were not discovered by Doclava.
Bug: 79904498
Bug: 79902686
Test: N/A
Change-Id: If6678bed5c2da076f97e3de7ff0bc4e7ebaf1965
For packages:
android.widget
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Idf7ccc7a850fa984ea16f91cdd70159087274e5c
Merged-In: Ic61019b1df85448a158fc2ba55c326353222c6b9
Adding annotations to individual fields cannot be easily done when there
are two fields defined in a single statement. Put each definition in a
statement of its own.
See go/UnsupportedAppUsage for more context.
Bug: 110868826
Test: m
Change-Id: If3adee4136f3c406e9cebd9d2845b22b979b8353
Adding annotations to individual fields cannot be easily done when there
are two fields defined in a single statement. Put each definition in a
statement of its own.
See go/UnsupportedAppUsage for more context.
Bug: 110868826
Test: m
Change-Id: I7756185bdfdca15fa8f73ef4b76c4f70abcd8ea6
DateUtilsBridge is only used in one place in framework.
The usage is avoidable by sticking to java.util. This
decreases the number of non-public libcore classes in
use by framework.
Test: build
Bug: 111055375
Change-Id: Ifd6576b5b6df1e154f16ec201a4575d0b95de66d
We switched the package installer app to always abbreviate all labels
loaded from foreign packages. This is done so that a foreign app cannot
crorrupt the UI via super-long strings.
The default abbreviation is very aggressive and abbreviates to ~5 cm.
When an app with a targetSDK <= M gets installed, all permissions will
get auto-granted. Hence when a user side-loads such an app, we show the
permissions during install so that the user is aware of this.
Unfortunately most permission labels and restrictions do not fit into a
single line.
This change allows much longer strings for permissions names and
descriptions. It still abbreviates eventually and handles permission
descriptions with weird characters (such as back-space) correctly.
Fixes: 110209410
Test: Side-loaded old app and verified that permission labels and
descriptions are not abbreviated.
Change-Id: Ie1db240883c9f5cb9c1b74ca7bdcb80625e3f7f2
Although parent view may invoke onDetachedFromWindow incorrectly,
itself should guarantee to unregister receiver only when removing
the last attached view.
Change-Id: I4b701c223c6aa354896a4067f77aad9c98d88dfd
Fixes: 78506836
Test: atest FrameworksCoreTests:DateTimeViewTest
As part of adding the hint text feature in
I357dd5c74b61d149cf8612d1f52c7118ec70c696 I refactored
the code inside reportExtractedText to avoid nesting but lost one
of the condition checks in the process. Since onDraw calls into
this method on each frame, the missing check was causing calls to be
made into the IME even when no content or selection changes have
happened.
Test: CtsWidgetTestCases:.TextViewTest
Bug: 73613936
Change-Id: If56e3f1d45e64dccd052e4cff4d742f0cbecc07c
In Id65443e93d277c106ea955c867d39e94192cc55d we fixed a monkey crash
happening when the smart selected text had changed while the smart
selection animation was running. However, the change introduced a new
crash, happening when the smart selection result was null. This CL fixes
it, and lets startSelectionActionMode run even when the result is null,
as there seems to be some logic there which should happen in this case.
Bug: 80244201
Test: none
Change-Id: I7f0304446dec85578bdcd5011d2e9ea2737d3c36
(cherry picked from commit a9d27ea869)
Merged-in: I7f0304446dec85578bdcd5011d2e9ea2737d3c36
This regressed when introducing TC sessions in
I3c9ceea0863099fc4f0a5ce5e823c648ee9c4521
When the user triggers a terminal selection event such as "Copy",
we should immediately end the session instead of waiting for the
"Abandon" event (i.e. selection dismissed) to be included in the
logs. Terminal selection events implicitly dismiss a selection and
we'd rather distiguish between an actual "selection dismiss" from
one that happened because of a "terminal" selection event.
This cl also removes the "*" marker used to distinguish the new
logging from the old ones. The code for the old logging has already
been deleted so no more need for a marker.
Bug: 78541105
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Iac7d45dbc63e7076683742bd045766a1d927cfc9
At the end of the smart selection animation, we run a callback that sets
the selection on the TextView (subsequently starting the action mode
toolbar and showing the handles). However, when the text changes before
the animation finishes, the selection might not be valid, and might get
out of the text bounds, which was producing a crash. This was observed
in a monkey crash. This CL fixes this bug by refusing to set the
selection when it goes outside the text bounds, corresponding to the
case when text has changed between the time the animation has started
and the time it ended.
Bug: 69919777
Test: manual testing before and after the fix
Change-Id: Iea043f320004d45ad16dd7e9e5b47e5256e6d9fa
(cherry picked from commit cce6e82d35)
Merged-in: Iea043f320004d45ad16dd7e9e5b47e5256e6d9fa
Approach here is to register a content observer that invalidates the
TC settings whenever updates to the settings happen.
This CL also ensures that the TC is invalidated when a settings
update happens. This is because the settings may change what
TC the system returns.
TextView's SelectionActionModeHelper has been updated to not cache
the settings and get them directly from TCM (which caches the settings).
NOTE that we expect TC settings to rarely change.
Bug: 77539576
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: manual - Made changes to TC settings and observed logs / app behaviour
Change-Id: I88bbb6f951708b17323fac1a72385fe808d270a5
DateTimeView won't update timestamp until the view is attached to
window and received TIME_TICK intent.
Update timestamp on onAttachedToWindow().
Test: manual 1) turn on DND 2) send a notification and wait some time 3)
turn off DND and check the timestamp
Fixes: 77970557
Change-Id: Ia8420aacf5b91b0bb9cbec561629ddbfc8de4f67
Since Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e, the magnifier can be
the child of a diffent surface than the one its content is copied from.
This initially led to much code duplication accross different methods,
making the code quite difficult to understand. This CL performs a small
refactoring, removing some of the TODOs and making the code a bit
cleaner.
Bug: 78876353
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ifa26f94ba2e4983446f058f016af6010c1017ea7
The position of the magnifier surface is always clamped inside its
parent surface. As of Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e, we are
always trying to make the magnifier surface a child of the main
application window, if possible (before, if the magnified view was a
SurfaceView, we were making the magnifier a child of the SurfaceView's
surface). However, the CL did not also update the clamping, continuing
to clamp to the SurfaceView space when the magnified view was a
SurfaceView (even if the magnifier was child of the main window). This
was making the magnifier window to be wrongly positioned on the screen
when the magnified view is a SurfaceView. The current CL fixes this.
Bug: 78876353
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I63f2b185f58e62e8ad6eadf788e641fb1de07b04
The CL fixes the magnifier's behavior when its parent window has
positive insets in its surface:
- we compute the content copy coordinates sent to the pixel copy request
relative to the surface the content is copied from. We were clamping
them inside the visible region of the magnified view as returned by
belonging to the view which is magnified. However, the method returns
coordinates relative to the window. Therefore, the CL offsets the
visible rectangle with the window insets, to account for them.
Otherwise, when the insets were non-zero, on a text line we were
allowing the magnifier to display content from the left outside of the
text line, while a certain region at the end of the text line could have
never been magnified
- when clamping against the visible view region, when the surface we
copy from is a SurfaceView, #getGlobalVisibleRect is still returning
coordinates relative to the main window, whereas the coordinates we are
trying to clamp are relative to the surface of the SurfaceView. In order
to make the visible rectangle relative to the surface of the SurfaceView
instead, this CL negatively offsets the visible rectangle with the
SurfaceView position in the parent surface
- the selection/insertion handles are hidden when they overlap the
magnifier. To check this, we intersect the magnifier rectangle with the
rectangle of each handle. However, when we were performing this check,
the magnifier rectangle was relative to the surface, whereas the
handles' rectangle was relative to the main window. The CL negatively
offsets the magnifier position with the surface insets, to make both
rectangles relative to the window.
Bug: 78621162
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I0d749c1abb38520fe8fc477d22d6523f470e9abc
Previously, we were making the magnifier surface a child of the main
window unless the magnified view was a SurfaceView, in which case we
were setting the SurfaceView to be the parent of the magnifier. In
Chrome, where the magnified views are usually SurfaceViews, this caused
the magnifier to be displayed underneath the omnibox, which was a
terrible user experience when trying to magnify the first lines of text
on a page. This was because the omnibox had a higher Z than the
SurfaceView, and therefore a higher Z than all children of the
SurfaceView (including the magnifier).
This CL sets the parent of the magnifier surface to be the main window's
surface when the magnified view is a SurfaceView as well. Therefore, the
magnifier becomes a sibling of the Chrome omnibox and, by giving the
magnifier a higher Z, it ends up being rendered on top.
Bug: 77926365
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e
