summaryrefslogtreecommitdiff
path: root/core/java/android/view/ViewOverlay.java
Commit message (Collapse)AuthorAgeFilesLines
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-291-2/+3
| | | | | | | | | | | | | | | | | | | 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. This is a resubmit of ag/12929664 with some APIs excluded that caused test failures; see bugs 171886397, 171888296, 171864568. APIs excluded: Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord; Landroid/os/Process;->myPpid()I Landroid/os/SharedMemory;->getFd()I Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I Bug: 170729553 Test: Treehugger Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
* Revert "Add maxTargetSdk restriction to unused APIs."Hongwei Wang2020-10-281-3/+2
| | | | | | | | | This reverts commit 72f07d6a8a32db4a0dedd7682a0b3385be2b9cd6. Reason for revert: Droidcop-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?testMethod=testAppZygotePreload&testClass=android.app.cts.ServiceTest&atpConfigName=suite%2Ftest-mapping-presubmit-retry_cloud-tf&testModule=CtsAppTestCases&fkbb=6936597&lkbb=6936969&lkgb=6936551&testResults=true&branch=git_master&target=cf_x86_phone-userdebug>, bug b/171886397 Bug: 171886397 Change-Id: Ibe0f0430a3451477c1ee8ef56a596e91ea1e7672
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-271-2/+3
| | | | | | | | | | 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 Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
* Switch Java calls to enableZ and disableZ; remove isRecordingForLeon Scroggins III2020-05-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Bug: 155422223 Test: make insertInOrderBarrier and insertReorderBarrier are @hide and deprecated. Remove them and update all callers to enableZ and disableZ, which are already public. Update native code to refer to enableZ instead of insertReorderBarrier. In addition, remove @hide Canvas#isRecordingFor. This method was originally used to prevent a single RenderNode from being in two display lists. This is now supported, so there's no reason to avoid it. The one caller used it to determine whether to reorder drawing its child Views (which, as the comment says, makes sense to determine based on whether the Canvas isHardwareAccelerated) and whether to call insertReorderBarrier/insertInOrderBarrier (now enableZ/disableZ). In the latter case, there is no need for a conditional, since enableZ/disableZ only work on a hardware Canvas. Change-Id: Ib216a19d6aeff40b2e23532bacd62d1795c2ab27
* Use new UnsupportedAppUsage annotation.Artur Satayev2019-12-181-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: I5be7335b23a92b8ac80d2fd890198273b66ad644
* Add @UnsupportedAppUsage annotationsMathew Inwood2018-08-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | For packages: android.view.textservice android.view.textclassifier.logging android.view.textclassifier android.view.inputmethod android.view.autofill android.view.accessibility android.view 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: I4147b038ed7adf0311ee9918b44766f82a057eaf
* Fix ViewOverlay#onDescendantInvalidatedChris Craik2017-04-251-12/+12
| | | | | | | | | Fixes: 37307001 Test: android.view.ViewInvalidateTest Also removes damageChildInParent, since it's not called anywhere. Change-Id: Ic81d4465e4828c5826957ace2c44ac263b4662bd
* Replace invalidateChild/invalidateChildInParentChris Craik2017-01-271-15/+3
| | | | | | | | | | | | | | Fixes: 34361503 Test: CTS: android.view.cts.ViewGroupTest APCT: android.view.ViewInvalidateTest Simplify and unify HW accelerated invalidate/damage codepaths, since both simply walk up to ViewRootImpl and schedule a traversal. Adds a new overridable method 'onDescendantInvalidated' for observing subtree rendering updates. Change-Id: I7ef1f914c3411317692451787b3810b23e019591
* Support shadows and reordering in ViewOverlay am: 36d9a6dfbaChris Craik2017-01-141-0/+12
|\ | | | | | | | | | | am: 2369a6d753 Change-Id: I1f6574a4b9a1d24ccd4fc78cbc7e3368d815f8f5
| * Support shadows and reordering in ViewOverlayChris Craik2017-01-121-0/+12
| | | | | | | | | | | | Bug: 32726440 Test: manual Change-Id: Ic5d7efdee5a493b7768b9db8150f65f97b3f0a64
* | Revert "Revert "Fast-path for ViewGroup#invalidateChild, invalidate tests""Chris Craik2017-01-091-1/+2
| | | | | | | | | | | | | | | | Bug: 33797688 This reverts commit 1cb8b08ae459fddc860e5863b0ec30a70682654e. Change-Id: I322b550d65d48be4a99faf1790d138d26a996d7e
* | Revert "Fast-path for ViewGroup#invalidateChild, invalidate tests"Selim Cinek2016-12-211-2/+1
| | | | | | | | | | | | This reverts commit f7505803eaf3b31bae81151535ce6c05c58712be. Change-Id: Ie7714360357e2baaf7723b8d992b3c6c4b0b9989
* | Fast-path for ViewGroup#invalidateChild, invalidate testsChris Craik2016-12-201-1/+2
|/ | | | | | | | | | Bug: 33460152 Test: new tests passing We spend a lot of time computing a damage rectangle that the ViewRootImpl ignores with HW acceleration. Skip all that with a fast path. Change-Id: Ia7447d1242cd5279be2ce34eead0cd813baffd33
* Remove tracking of all drawables in ViewOverlay.clear()Kirill Grouchnikov2016-03-141-0/+3
| | | | | Bug: 27529505 Change-Id: Ibf35ffb7b9883ed8321107fc793d50172dff26f2
* Add consistent @NonNull annotations for drawable callbacksAlan Viverette2016-03-111-2/+2
| | | | | Bug: 27599515 Change-Id: I33fdc5392302403bfff9cc74a8226173ec962af6
* Tweaks to ViewOverlay.Kirill Grouchnikov2016-03-091-15/+34
| | | | | | | | | | * Clarify Javadocs for add / remove when called with the same Drawable. * Add @NonNull annotation to all add / remove APIs and throw IllegalArgumentException when null value is passed. Bug: 27528798 Change-Id: Ied8f28c70775309e4fa85aff6a7202c1a0eb6aa3
* Sync ViewOverlay size init with RenderNodeChris Craik2014-12-011-0/+3
| | | | | | | | bug:18381202 Setting mRight/mBottom must be accompanied by updating the RenderNode. Change-Id: I4dae06a5ca43247b0b3642d85808e2724e486692
* Move most TransformationInfo properties to RenderNodeChris Craik2014-04-021-3/+7
| | | | | | | | | | | | | | | | This change dedupes the various properties that were represented both in TransformationInfo, and RenderProperties on the native side. RenderNode (and its associated properties) are now permanently attached to a View in SW or HW. The native copy of these properties are their sole representation. Alpha to come in a later CL. Also fixed issue with copying RenderNode's transform, and added support of deleting RenderNodes in software rendering. Change-Id: Ideb6e7f32b780e87aa1c32637c368356b3eee3a1
* Verify drawables added to ViewOverlay so they can be scheduledAlan Viverette2013-12-111-0/+5
| | | | Change-Id: I73d0633966f84876e2093c874acd6813efdbc370
* Fix ViewGroupOverlay's handling of invalidating viewgroupsChet Haase2013-06-211-0/+11
| | | | | | | | | | | | | | | | | Invalidating a view property (alpha, rotation, etc.) causes an invalidation process that does not work correctly when the view is in a ViewOverlay. Specifically, if the view is not directly in the overlay, but is instead inside a hierarchy which is within the overlay, then the invalidation process stops at the ViewOverlay itself, because the ViewOverlay has no "parent" view. The fix is to override the invalidateChildInParentFast() method, just like we override invalidateChildInParent(), to forward the invalidation to the host view. Issue #9389230 Animations not running for nested views under ViewGroupOverlay Change-Id: I03fcef10ed1c8a91cb26d5d9d6945634b0b695b5
* Fix crash with LayoutTransition and ViewOverlay collisionChet Haase2013-06-061-0/+9
| | | | | | | | | | | | | | | | | When a View is added to a ViewGroupOverlay, it must not be parented in another container. If it is, it will automatically be removed. This works in general, but if there is a LayoutTransition on the view's parent, then the actual removal will be delayed until the transition completes. This means that the call to add(view) in the ViewGroupOverlay's container will fail and throw an exception because the view is still parented for the duration of the LayoutTransition. This fix cancels the running transition to ensure that the view is not parented prior to adding it to the overlay's container. Issue #9303245 Crash combo: add(View) and animateLayoutChanges Change-Id: Id4eaddccf64c353fc77e020882b978cdeb14c0ef
* Add null check in ViewOverlayChet Haase2013-05-201-1/+3
| | | | | | | | | | View.getOverlay().clear() can failed with an NPE if there are no drawables in the overlay. Fix: add a null check before dereferencing the mDrawables field. Issue #8895794 getOverlay.clear() crashes if drawables were not added previously Change-Id: I9b2a63036450915681ba3a89a0911e2490063702
* Avoid repositioning unattached overlay viewsChet Haase2013-04-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Adding a view to an overlay usually entails removing the view from its current parent, if it has one. ViewOverlay.add() will do this automatically. At the same time, it will check to see whether the parent view is in a different global location than the overlay's host view, and will adjust the added view accordingly. This enables the caller to simply toss a view into an overlay and have it end up at the same global position on the screen. the problem is that the current code doesn't bother to check whether the old parent is attached. If that parent has been removed from the view hierarchy before this overlay operation, then it will show up as being at (0,0) in the window, not its old location. This results in the view being mis-positioned in the overaly. Fix is simple: if the view's old parent is not attached, simply remove it from that parent before adding it to the overlay; don't try to compensate for its position which is based on wrong information. Issue #8620319 Overlay should only use relative window locations for onscreen parents Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
* Make adding views specific to a ViewGroup's overlayChet Haase2013-04-081-161/+232
| | | | | | | | | | | | | | | | | | | | | | Adding views to views (possible with the new Overlay API) is weird. This change moves the view-management facilities of Overlay to a subclass that is specific to the overlay returned from ViewGroup.getOverlay(). So now you can add drawables to all view overlays, but only add/remove views to/from the overlay returned from ViewGroup.getOverlay(). Also, the previous approach of using an interface for Overlay was changed to classes for both ViewOverlay and ViewGroupOverlay. Finally, this change makes not handling touch correctly the proper, and documented, behavior of overlay views. There are various tricky issues to sort out with input in overlays (including click handling as well as focus) and we don't want developers starting to use overlays as some kind of general container hierarchy, so we're purposely constraining overlays to have visual-only behavior. Issue #8459085 Overlay needs to handle touch correctly Change-Id: I207b8dbf528f87c92369d270d8b0a6556826d207
* Fix touch processing for Overlay viewsChet Haase2013-03-251-11/+38
| | | | | | | | | | | | | | | Previous implementation processed Overlay touch after other children in a ViewGroup; it should be the other way around. Also, fixed some invalidation issues. Finally, added new behavior to automatically place View which is already parented into the same global position, by calculating where the overlay is on the screen relative to the previous parent of the View. Issue #8459085 Overlay needs to handle touch correctly Change-Id: Ic2cee12d2bc345f64ed3f4d855a5c3496967a201
* Manage drawable invalidation automatically for OverlaysChet Haase2013-03-201-2/+9
| | | | | | | | | | | | | | | Drawables added to a view's Overlay will now cause the Overlay to be invalidated via the normal drawable-invalidation mechanism. That is, changes to any of the drawables in the overlay should cause invalidation of the proper area of the overlay and thus the hostView, causing the appropriate area to be redrawn. Also, fixed a bug in drawable invalidation so that bounds changes will now correctly invalidate both the old and new bounds areas. Issue #8350510 Add APIs needed for future animation capabilities Change-Id: Icae5fa0e420232ee17dc39be10084345bae8dbd8
* Add overlays to viewsChet Haase2013-03-151-0/+203
It is useful, particularly in animations, to be able to add a view, or at least some graphics, on top of a view. For example, to have a child of a layout fade away, we might want to remove the child from that layout and then fade it out gradually. Meanwhile, we have to have a place to put that view where it will be drawn. We could do this in the content container sometimes, but this is not a reliable workaround in the general case, and may obscure other siblings/parents of the layout/view in the hierarchy. A better approach would be to place a view/graphic temporarily in the layout itself. This feature adds the ability to add one or more Views and Drawables to an "overlay" layer, after which the view will handle drawing that extra content when it redraws itself. Issue #8350510 Add APIs needed for future animation capabilities Change-Id: I70bf78c46ee3db8bd87ea1cdc2ecb5c0747ccbf9
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-22 03:24:22 +0000