summaryrefslogtreecommitdiff
path: root/core/java/android/widget/Toast.java
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Add Toast#show() specific javadoc" into android13-tests-dev am: ↵Treehugger Robot2023-03-161-0/+3
|\ | | | | | | | | | | | | | | | | 1d8b567ae1 am: f8ba53d9c9 am: cd801e3f19 Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/2477605 Change-Id: I1acedf2003d23e18c388997fdbfb58b19fbac48f Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
| * Add Toast#show() specific javadocAzhara Assanova2023-03-101-0/+3
| | | | | | | | | | | | | | | | The added javadoc comment already exists in Toast's class level javadoc on line 75. Bug: 265306493 Test: None Change-Id: I5692db36461dae1f79a72eb2bb15d8379bd24a84
* | Add PbA branding to clipboardYi-an Chen2022-07-191-8/+29
|/ | | | | | | Bug: 213357911 Test: Manually on Raven Change-Id: If9944393fe64c7f94a5be139a538833d91ae98fe
* Update Toast documentationBeverly2021-12-211-0/+3
| | | | | | | | | | | | to explicitly callout the 2-line limit Note: more information can be found in https://developer.android.com/guide/topics/ui/notifiers/toasts which is also linked in the documentation but could be missed. Test: manual Fixes: 207767563 Change-Id: Icc7fbf6fddf101bd2422bbeab04e0da8084c6698
* Expand toast javadoc to include rate limiting info.Jan Tomljanovic2021-06-091-0/+3
| | | | | | Test: N/A just adding javadoc Bug: 190468866 Change-Id: I0a1ab865f5db7a990c1a667b729df52c4735a38c
* Fix broken @see tags in public documentation.Andrew Sapperstein2020-04-281-3/+1
| | | | | | | | | | | | | | | | These were previously being suppressed by doclava but with this change, all failures are fixed and the suppression logic has been removed. To fix the issues, there were a few possible changes made: - broken reference to a public API (such as incorrect parameters): fixed - unnecessary @link inside an @see tag: fixed - @see referring to an @hide or @SystemApi: reference removed - broken references to inner class constructors - worked around by fully qualifying the constructor Bug: 6963924 Test: make doc-comment-check-docs Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
* Wire user info and use user context for text toastsBernardo Rufino2020-04-061-5/+5
| | | | | | | | | | | | | | | | | Text toasts don't currently support multi-user. This CL prepares toasts for multi-user by wiring the user information from who requested the toast (in the form of uid) to ToastUI, where text toasts are actually rendered. We go only as far as obtaining a new user-specific context for that user and using that to construct the view. Actual support will come in future CLs. Bug: 151414297 Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest ToastWindowTest ToastUITest NotificationManagerServiceTest LegacyToastTest Change-Id: I8c92453c6a2b73c31f9a41ca9ff463d194d4f44f
* Refactor ToastPresenter to perform show()/hide()Bernardo Rufino2020-04-031-54/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support multi-user, we need to create a new context based on the user id and retrieve the services from it (http://b/151414297#comment9). This meant retrieving the services in ToastUI.showToast() instead of on its constructor, which would make the code diverge from Toast$TN.handleShow(). In order to avoid that, now seemed a good time to refactor ToastPresenter to perform show() and hide(). This means ToastPresenter will now be instantiated in every request for a new toast in ToastUI, but fortunately with the refactor we were able to get rid of ToastEntry (which was also beign instantiated in every request). Also found out a bug with this where window tokens were being used to locate the toasts instead of the (non-window) tokens. This is a bit confusing because the method NM.finishToken(package, token) receives a non-window token to locate the ToastRecord and then finish its window token. This didn't have any side-effects because NM itself finishes the tokens after a time-out. Added a test for this. Bug: 152973950 Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest ToastWindowTest ToastUITest NotificationManagerServiceTest LegacyToastTest Change-Id: I13cf18890ca22022adb7576c8ecf3285a9b82299
* Gate toast block and remove warningBernardo Rufino2020-03-241-6/+1
| | | | | | | | | | | | Gate background custom toast block on targetSdk for beta 1, after having gathered dogfood feedback. So, enabling the change for apps with targetSdk > Q (>= R). Also removed warning toast. Added tests in topic CL to cover all the cases. Bug: 144152069 Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest Change-Id: If368a97a2a8ff56770635615f89c79007bb27075
* Clarify Toast.Callback javadocBernardo Rufino2020-03-241-1/+2
| | | | | | | | | Text was ambiguous and could mean callback object construction instead of toast construction. Test: Builds Bug: 144152069 Change-Id: I06160de2b85f339517ae45d3bd4cc1098f433ef0
* Show toasts from system/sysUI to all usersBernardo Rufino2020-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | The package name test is safe: * If it's used by Toast class in an app, apps have access to layout params anyway via getWindowParams() and applied flag is already protected by INTERNAL_SYSTEM_WINDOW permission. * If it's used by ToastUI class in sys UI on behalf of another app, sys UI is trusted domain and can't be messed up by another app. It also has INTERNAL_SYSTEM_WINDOW permission. Bug: 149408635 Test: atest ToastUITest android.widget.cts.ToastTest android.widget.cts29.ToastTest android.server.wm.ToastTest Test: Change phone to vibration/silent in secondary user and observe toast is displayed. Change-Id: I227e9f74166300fcb3ba8f3871b464afe6ec6a28 Merged-In: I227e9f74166300fcb3ba8f3871b464afe6ec6a28 (cherry picked from commit caef507aa935b3724bd19096b31d557aa0fc787a)
* Unify toast presentation codeBernardo Rufino2020-02-281-69/+14
| | | | | | | | | | | | | | | Extract window layout construction and view inflation from Toast and ToastUI into common @hide class ToastPresenter. This is desirable by itself but also in preparation for making system toasts visible to all users. Bug: 149408635 Test: atest ToastUITest android.widget.cts.ToastTest android.widget.cts29.ToastTest android.server.wm.ToastTest Change-Id: Ifdd7ee37687da2e4c7abed61569cf342f95b2611 Merged-In: Ifdd7ee37687da2e4c7abed61569cf342f95b2611 (cherry picked from commit aea2c50cd81ebb4665380aa6ddc76e2d9b2a6f09)
* Merge "Return null for getWindowParams() on system-rendered toasts"Bernardo Rufino2020-02-111-2/+13
|\
| * Return null for getWindowParams() on system-rendered toastsBernardo Rufino2020-02-071-2/+13
| | | | | | | | | | | | Bug: 144754526 Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest Change-Id: I768424ab157d64cfc922cd307ffcc688a6ab6de3
* | Mark getView() with @NullableBernardo Rufino2020-02-071-4/+9
|/ | | | | | | | Since they can return null. Test: Builds Bug: 144754526 Change-Id: I46a517584d5862fc09764a9f03ac5e2603e98957
* Add Toast logs and update docsBernardo Rufino2020-02-061-2/+71
| | | | | | | | | | | | Some methods should not be called on text toasts rendered by the system UI, adding logging and updating docs. Check go/toast-block-design for details. Bug: 128611929 Bug: 144754526 Test: Builds Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest Change-Id: I282288afd0be604b2fdaa1348f09fc59e8f33d98
* Don't block app-rendered text toast on apps with targetSdk < 30Bernardo Rufino2020-02-061-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We've decided to gate the text toast move on targetSdk due to an app crash (b/148438364) but decided not to gate the background custom toast block (in NMS) on targetSdk temporarily to gather dogfood and DP feedback. This meant that app-rendered text toasts (which are only possible for apps with targetSdk < 30) were being blocked in NMS since they were being considered custom toasts. This brings back the boolean inside Toast class that differentiates between custom and text toasts for apps with targetSdk < 30, since both are app-rendered in this case. This code won't be present on final version and is temporary to gather feedback on dogfood and DP, since almost no app currently targets SDK 30+. We'll gate both changes (the system UI move and the bg custom toast block) on targetSdk later on. Bug: 148761979 Bug: 148794147 Bug: 144754526 Test: Verify that, while on the background: App with | Custom toast | Text toast targetSdk < 30 | Blocked | Allowed targetSdk 30+ | Blocked | Allowed Test: atest android.widget.cts.ToastTest android.widget.cts29.ToastTest LegacyToastTest Change-Id: Id529028bc463034cd2f64a6f2f97e71bc6ea7c36
* Add @Deprecated tag to Toast.getView()Bernardo Rufino2020-02-051-0/+1
| | | | | | | | | | | | | For some reason I had added @deprecated inside javadocs but forgot to add @Deprecated to the method on ag/10117117. Repo-hooks only warned me now that touched that method for something unrelated. Curiously even api/current.txt in that CL has the method marked as @Deprecated. Bug: 128611929 Bug: 144754526 Test: Builds Change-Id: I8e4a58ae5ba2204aaced6d7a83746b17573a8c97
* Gate CHANGE_TEXT_TOASTS_IN_THE_SYSTEM on targetSdk 30+Bernardo Rufino2020-01-291-3/+2
| | | | | | | | | | | | Bug: 148438364 Bug: 144152069 Bug: 144754526 Bug: 128611929 Test: atest android.widget.cts29.ToastTest Test: Verify com.commsource.beautyplus doesn't crash when sharing photo (details on b/148438364) Change-Id: Iea3ffd69c3fd217b993d89020b7ec6c3c32cea15
* Move text toast creation to system UIBernardo Rufino2020-01-271-45/+167
| | | | | | | | | | | | | | | | | | | | In order to do that, NotificationManager now calls StatusBar.showToast(), which is in SystemUI. StatusBar then calls a new component, ToastUI, which is responsible for rendering the toast. The code for rendering the toast was extracted from the Toast class, so it should behave identically. Also refactored the code a bit on NotificationManagerService, creating two children of ToastRecord (one for custom, other for text toasts). The change is gated in Toast class in this CL, but it's also gated on the system server, so apps can't circumvent the background block. Bug: 128611929 Bug: 144754526 Test: atest android.widget.cts.ToastTest Merged-In: Id0021cdc6f72f41b55ff1c5a4f09ae7687586460 Change-Id: Id0021cdc6f72f41b55ff1c5a4f09ae7687586460
* Window Manager Flag Migration (12/n)Tiger Huang2020-01-231-1/+1
| | | | | | | | | | | | - Unhide new APIs - MaxInsets -> InsetsIgnoringVisibility - Deprecate SystemUI flags - Deprecate some other stuff Bug: 118118435 Test: Build, CTS coming soon Change-Id: I0a0cbdb48258b3779d536668b59e8c88f3c96d18 Exempt-From-Owner-Approval: Trivial rename
* Merge "Use IBinder token for indexing toasts instead of ITransientNotification"Bernardo Rufino2020-01-211-8/+13
|\
| * Use IBinder token for indexing toasts instead of ITransientNotificationBernardo Rufino2020-01-211-8/+13
| | | | | | | | | | | | | | | | | | | | | | In preparation for text toasts, which won't contain a ITransientNotification object associated with them, indexing toasts by an IBinder token provided by the app. Bug: 144754526 Bug: 128611929 Test: atest android.widget.cts.ToastTest Change-Id: I8ec649066154f59bc28bcb49bb6f156eadb796d8
* | Deprecate custom toastsBernardo Rufino2020-01-211-0/+19
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecating custom toasts as discussed, the reasons are: * We're blocking background custom toasts for security reasons (go/toast-abuse). * This means custom toasts are only possible if the app is in the foreground. In the foreground the app has control over its own view hierarchy and is capable of creating any visual elements it would otherwise use custom toasts for. * If we were to declare ongoing support for foreground toasts the developer would be in a situation where they either check for foreground status of the app before posting a custom toast or they accept that the information they want to display may not be shown at all. This is not great. * There is also a desire to avoid custom toasts altogether since they hurt UX consistency (https://docs.google.com/presentation/d/1r5WEofZ_G3B9M65nS37uD4RqA4iV9HUmngyE6ZpBSsw/edit#slide=id.g7b69852da2_0_0). Also added a recommendation to use Snackbars while the app is in the foreground. Bug: 128611929 Bug: 144754526 Test: Builds Test: atest android.widget.cts.ToastTest Change-Id: I4ed0bd671e308491590c28ff24087c76d0623f13
* Merge "Add Callback API to Toast"TreeHugger Robot2020-01-151-0/+63
|\
| * Add Callback API to ToastBernardo Rufino2020-01-101-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for moving text toasts to system UI, we need a new way of telling if a toast is being displayed or not since the view won't live in the app's process. This is needed for our CTS tests and good to have for developers so we don't take the functionality away from them, so making it a public API. Also updated tests in topic CL. Bug: 128611929 Bug: 144754526 Test: atest android.widget.cts.ToastTest Change-Id: I41ff1ed11d5af66e415c772c2e5f611a3d1b17fc
* | Use new UnsupportedAppUsage annotation.Artur Satayev2020-01-061-1/+1
|/ | | | | | | | Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library. Bug: 145132366 Test: m && diff unsupportedappusage_index.csv Change-Id: I41e12e425284e74561c6b61663241df364ae54a1
* Window Manager Flag Migration (7/n)Tiger Huang2019-12-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Introduce new APIs in Window/WindowManager.LayoutParams for developers to decide which types of insets at which side a window should avoid: setFitWindowInsetsTypes(@InsetsType int types) setFitWindowInsetsSides(@InsetsSide int sides) setFitIgnoreVisibility(boolean ignore) The existing logic in DisplayPolicy.layoutWindowLw uses combinations of window types, window flags, and system UI flags to decide what frames a window should have, which is very complex, difficult to maintain, and should be replaced with the new APIs. Bug: 118118435 Test: atest InsetsSourceProviderTest InsetsStateControllerTest InsetsPolicyTest WindowStateTests CommandQueueTest RegisterStatusBarResultTest InsetsFlagsTest LightBarControllerTest RegisterStatusBarResultTest ViewRootImplTest DisplayPolicyLayoutTests DisplayPolicyInsetsTests DisplayPolicyTests TaskSnapshotSurfaceTest Change-Id: I06ddc9d0d2887ba4ded7bb8adbf9c9c0da4bf7b4
* [Roll Forward] Block background custom toastsBernardo Rufino2019-11-201-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous CL (ag/9699132) broke CTS ToastTest and was reverted (ag/9754500). This was because the test was posting a background toast and verifying it wasn't clickable. Test has been updated to use a foreground toast in ag/9754274 and I will also look into having it be executed in presubmit.(b/144810971). -- Previous CL description (updated "Test:" lines) To assess app compatibility problems early on, this CL blocks background custom toasts in a non-secure way. We create a new method in the AIDL called enqueueTextToast() that now contain the same parameters as enqueueToast(), receiving the view created inside the app's process. But this method will, in the future, contain a CharSequence instead of ITransientNotification, for window creation inside the system. We use PlatformCompat infrastructure to check if the change is enabled. I learned with this change that if user blocks notifications for an app, it won't be able to show background toasts, allowing me to re-use the foreground check that was already in place. This change will display a text toast (from the system) in case the app's custom toast gets blocked, this is temporary to get feedback from dogfood. Test: With sample app, verify that: 1. Posting text toast in bg works 2. Posting custom toast in fg works 3. Posting custom toast in bg does NOT work Test: atest CtsToastTestCases CtsWindowManagerDeviceTestCases:ToastTest CtsWidgetTestCases:ToastTest CtsToastLegacyTestCases Test: Working on CTS Bug: 128611929 Change-Id: I25c6339c6adeb907878596332f57e2fa229bfda9
* Merge "Restrict reflection access to Toast's TransientNotification."TreeHugger Robot2019-02-151-6/+6
|\
| * Restrict reflection access to Toast's TransientNotification.Daniel Santiago Rivera2019-02-051-6/+6
| | | | | | | | | | | | | | | | | | | | | | Apps accessing the transient notification end up modifying the Toast's presentation in un-intended ways, such as forcing it to show on top of the lock screen. For other cases, as configuration of duration, gravity or view to show, Toast has available public APIs. Bug: 123768598 Test: n/a Change-Id: I0854389e4cc60baff2d433d4c49fa603a242982e
* | Restrict reflection access to INotificationManager from ToastAdam Powell2019-02-041-2/+2
|/ | | | | Bug: 123768917 Change-Id: Ice757d9f10f08f6d50dc34ca5c459e44d1ade10d
* Add Context.getDisplayId() to avoid possible IPCYohei Yukawa2018-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 c53d78e992694e471ddaae73f9a30977db9cdb75 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
* Move some members to the "Q blacklist".Mathew Inwood2018-09-141-1/+2
| | | | | | | | | | | | | | 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 Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
* Add @UnsupportedAppUsage annotationsMathew Inwood2018-08-211-0/+13
| | | | | | | | | | | | | | | | 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: Ic61019b1df85448a158fc2ba55c326353222c6b9
* Merge "Code reformatting for upcoming automated code changes." am: ↵Mathew Inwood2018-08-171-1/+2
|\ | | | | | | | | | | | | | | d68f003c67 am: d48ec695d3 am: 640fa1526d Change-Id: Idc4ce525b14a29f6ed87850f6df9577bdd05f38e
| * Code reformatting for upcoming automated code changes.Mathew Inwood2018-08-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Support the toast Window to show on the secondary display.Jeff Chang2018-08-151-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | 1) Looking for the specific display when add a toast window. 2) Modify the enqueueToast interface to support the toast with specific dispaly Id. 2.1 Toast get the specific display id from context. 2.1 Toast use the new interface with display id to communicate with the Notification manager servcie. 3) Support to add/remove toast window token according to the displayId. Bug: 80001975 Test: atest WindowManagerSmokeTest ActivityManagerMultiDisplayTests Test: atest android.widget.cts.ToastTest Test: manual, use ActivityView & launch a toast testing app in virtual display 1. Make a toast. 2. Verify the toast if show on the virtual display Change-Id: I3a95c291af647ed9c6e966b2a90924097df19b6a
* Fix toast lifetimeRobert Carr2018-03-011-0/+8
| | | | | | | | | | | | | | | | | | | In NotificationManagerService#cancelToast we have been calling WindowManagerService#removeWindowToken with 'removeWindows'=true. This is allowing for Surface destruction without any sort of synchronization from the client. Before the call to removeWindowToken we are emitting a one-way hide call to the Toast client. As a solution to the lifetime issue we have the client callback to let us know it has processed the hide call (and thus stopped the ViewRoot). On the server side we also instate a timeout. This mirrors the app stop timeout. All codepaths I could find leading to this sort of situation where a client is still rendering in to a toast following the total duration expiring seem to indicate a hung client UI thread. Bug: 62536731 Bug: 70530552 Test: Manual. go/wm-smoke Change-Id: I89643b3c3a9fa42423b498c1bd3a422a7959aaaf
* Add more IntDef prefixes for auto-documenting.Jeff Sharkey2017-12-131-1/+4
| | | | | | | Test: builds, boots Bug: 70177949 Exempt-From-Owner-Approval: annotation-only changes Change-Id: I76dde6054e06f52240bd4b1a0f196dcb74623608
* Revert "Don't generate irrelevant a11y events - framework"Eugene Susla2017-12-051-2/+1
| | | | | | | | This reverts commit 8ddfb4794f128ad6ac10fed72c73fdec61ea7bcb. Test: presubmit Bug: 69975306 Change-Id: I05cb545eb0adc77298dddf2dea2997ef36b58a5f
* Don't generate irrelevant a11y events - frameworkSvet Ganov2017-11-281-1/+2
| | | | | | | | | | | | Now before we fire an a11y event we check if this event has an observer. As a bonus we don't push the state to clients if the dynamic service config did not change. Test: cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases bug:69427760 Change-Id: Ie208e13b8557bb7a120198a43efcb79c2752f5db
* Merge "Fixes crash (race cond) when using toast that is immediately ↵TreeHugger Robot2017-05-161-2/+15
|\ | | | | | | cancelled" into oc-dev
| * Fixes crash (race cond) when using toast that is immediately cancelledSvet Ganov2017-05-151-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running cancel after toast is shown and adding some UI stress (or sleep on UI thread) causes a crash from toast when trying to add the toast window to the display. The toast must be triggered from app that is above N MR1 (25). The steps that crash the app are: 1. Show toast (Toast.makeText(...).show()), window token is created 2. Immediately cancel toast (Toast.cancel()), window token is removed 3. Stall UI thread (Thread.sleep, heavy task), both show and cancel events are queued to UI thread from window manager 4. Crash trying to add toast but no window token exists In Toast:handleShow(), the mNextView is required to add the toast to display, if the mNextView is null before posting to window manager, then when handleShow() runs later, it will ignore adding the toast to display. The issue before is that mNextView is set to null after cancel runs back from window manager in UI thread but the show post will always happen first. Therefore set mNextView to null at the beginning of cancel will ignore adding the toast to display and avoid the crash. Bug: 37606432 Test: manual - write an app to Toast.show(), Toast.cancel(), then Thread.sleep(), set app's sdk usage above 25 (N MR1) and show the toast Change-Id: I352e296c47b1b8776c78b6b0943b1dc809963026
* | Fix Toast exception in NotificationManagerServiceGeoffrey Pitsch2017-05-091-38/+71
|/ | | | | | | | Toast client code needed optional way to specify a looper Bug: 37945054 Test: runtest systemui-notification Change-Id: I8f0e051876871b8c44c225f53370392f1b7f353e
* Implicitly cast views obtained via View.findView methodsAlan Viverette2017-02-271-1/+1
| | | | | | | | | | Removes all explicit casts from android.widget classes. Also @removes methods on ListView that were overriding @hidden methods and should never have been exposed as public API. Bug: 24137209 Test: make Change-Id: I89f0e51258560987b3942251fd249210f825ac2a
* Revert "Implicitly cast views obtained via View.findView methods"Alan Viverette2017-02-031-1/+1
| | | | | | | | This reverts commit 06c2fffdaa81544522de751846754f781a9970a9. Reason for revert: Java 8 doesn't support this magic. Change-Id: Iaa41f4e4d0072b9a97cff9cd3788403d4ab79d13
* Implicitly cast views obtained via View.findView methodsAlan Viverette2017-01-271-1/+1
| | | | | | | | | | Removes all explicit casts from android.widget classes. Also @removes methods on ListView that were overriding @hidden methods and should never have been exposed as public API. Bug: 24137209 Test: make Change-Id: I6ccfc6f001b355c4880f2b54e1a5474df78d6228
* Prevent crash from early Toast surface destruction.Robert Carr2016-10-191-24/+43
| | | | | | | | | | | | | | | | | To understand this change it's first helpful to review Toasts. The ViewRoot is constructed on the client side, but it's added, to a window token controlled by the NotificationManagerService. When we call NotificationManagerService#cancelToast, the system will remove this window token. With the window token removed, the WindowManager needs to destroy the surface to prevent orphaned windows. If we destroy the Surface before removing the toast on the client side however, we've never asked the ViewRoot to stop rendering and we could have a crash. To solve this we just have to ensure we call removeView before cancelToast. Test: cts-tradefed run singleCommand cts -d -o --module CtsWidgetTestCases --test android.widget.cts.ToastTest Bug: 31547288 Change-Id: I96672b0ac07ff18e9f51348f2ed42913c5a5226f
* Remove toast window immediatelySvet Ganov2016-09-081-1/+1
| | | | | | | | | | | | | | To address a security issue where a toast window can be used by an app to overlay other apps without a permission we now allow legacy apps to be able to put at most one toast window on the screen to prevent adding the same window over and over again to go around the new restriction that toast windows are always removed after a timeout. This change ensures that Toast removes its window immediately. bug:31340854 Change-Id: Ia7f90844eb64b583321103d090e4407038b41547
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 20:01:00 +0000