77e9a28e2faa36f127231b842476d47f9823a83a |
|
13-Sep-2013 |
Alan Viverette <alanv@google.com> |
Add live region politeness to View, AccessibilityNodeInfo Alters the content change API to contain a bit mask of types of changes represented by the event. Live regions send CONTENT_CHANGED events immediately. Removes unused APIs for EXPANDABLE/EXPANDED. BUG: 10527284 Change-Id: I21523e85e47df23706976dc0a8bf615f83072c04
/frameworks/base/core/java/android/view/ViewGroup.java
|
1487466dc2ce14cccf0ff2bd2f824238aaa0044e |
|
19-Jul-2013 |
Adam Powell <adamp@google.com> |
Add View#cancelPendingInputEvents API This API allows an application to cancel deferred high-level input events already in flight. It forms one tool of several to help apps debounce input events and prevent things like multiple startActivity calls, FragmentTransactions, etc. from executing when only one was desired since it's otherwise not desirable for things like click events to fire synchronously. Change-Id: I60b12cd5350898065f0019d616e24d779eb8cff9
/frameworks/base/core/java/android/view/ViewGroup.java
|
cb96db8d144a01aa41ec396247c548d8aa496131 |
|
04-Sep-2013 |
Chet Haase <chet@google.com> |
Perform layout and invalidation after bringChildToFront() Previously, calls to ViewGroup.bringChildToFront() or View.bringToFront() would need to be followed by calls to requestLayout() and invalidate() to force the container to redraw with the new child ordering. This change calls requestLayout() and invalidate() automatically. Issue #8667065 bringtoTop does not work Change-Id: Id37ce7a64dead82119e49f7a1b28385cf0d1f20d
/frameworks/base/core/java/android/view/ViewGroup.java
|
fee6f2b3d30fe222486a70a773683e21d9dd12bf |
|
27-Aug-2013 |
Chet Haase <chet@google.com> |
Fix NPE when setting new LayoutTransition ViewGroup.setLayoutTransition() has logic to cancel a previously-running transition and remove the ViewGroup's listener from that transition. However, it is possible for the transition to be set to null on the ViewGroup on the cancel() call, making the next call to remove the listener crash with an NPE. The fix is to use a temporary variable to hold the old reference and not depend on the class instance variable remaining valid/non-null across the call to cancel(). Issue #10488932 Hangout NPE in ViewGroup.setLayoutTransition on initiating a new conversation Issue #10509201 ViewGroup.setLayoutTransition(null) causes crash when being called in LayoutTransition.TransitionListener.endTransition() Change-Id: I7c181b79e6601024c93a8dc246d32b751f78b216
/frameworks/base/core/java/android/view/ViewGroup.java
|
ef3cbfd4c42719d3e4feabb74c08f0311066c194 |
|
21-Aug-2013 |
Chet Haase <chet@google.com> |
Cancel running LayoutTransition before removing it from a container Previously, setting a new LayoutTransition object on a container would not do anything to the old transition object (if it existed). This means that the previous transition could be mid-flight, changing stuff in that container, and would continue doing so even after it was removed. This could cause artifacts like that in the bug below where views that are fading out would be put in the containers "disappearing children" list for the duration of the fade... and then would never be removed from that list because the container was no longer connected to that transition. This caused items to stay visible even after they were removed from their parent containers. Issue #10119571 LayoutTransitions sometimes does not honor view's visibility Change-Id: I3efa4065e47fa97c4dd90410bbc1a0273c2b8079
/frameworks/base/core/java/android/view/ViewGroup.java
|
199acdfcc98e852975dd7edfbcb822ba5e73146f |
|
25-Jul-2013 |
Chet Haase <chet@google.com> |
Better Transition interruption Previously, a running transition on a scene root would simply be canceled when a new transition was started. This would result in abrupt scene changes, especially in generic use cases where apps/widgets would spawn multiple transitions in successive rendering frames due to small changes in view properties. The new approach is to check all running animations against new transitions. If there are overlapping properties that are being set to different values, the new animations win and the old ones are canceled. If the end values are the same, the new animations are noop'd and the old ones are allowed to continue as-is. There was also improvement to capturing state while other transitions are running, necessary in this new world where old transitions are allowed to continue running. Now, transitions are pause()'d while values are captured, then resume()'d after capturing is done. This allows the system to see what the real view properties are, instead of the mid-animation values. Change-Id: I8e77fb9c1967087a682bb26a45763005f5ca9179
/frameworks/base/core/java/android/view/ViewGroup.java
|
504a10f2f5c7343c863d31490700620109deb7ae |
|
12-Jul-2013 |
Adam Powell <adamp@google.com> |
Un-hide all ViewParent methods Make it possible for code outside the framework to implement the ViewParent interface. Change-Id: Ic1b4eb15a4b3da1d16c92b59e039d89861d893e4
/frameworks/base/core/java/android/view/ViewGroup.java
|
e4a2d7c48e17dd1c2f59dd18e91997029a6d0bdb |
|
22-Jun-2013 |
Chet Haase <chet@google.com> |
Fix ViewGroupOverlay's handling of invalidating viewgroups 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
/frameworks/base/core/java/android/view/ViewGroup.java
|
f78484b0b130472a5a73c2bab91f0475508aa018 |
|
18-Jun-2013 |
Scott Main <smain@google.com> |
am ea893536: am c4473d10: am 27a8508e: add attributes reference for splimotionevents and layoutmode * commit 'ea8935362da192508a4ff945b47e0c7ff1239679': add attributes reference for splimotionevents and layoutmode
|
ea8935362da192508a4ff945b47e0c7ff1239679 |
|
18-Jun-2013 |
Scott Main <smain@google.com> |
am c4473d10: am 27a8508e: add attributes reference for splimotionevents and layoutmode * commit 'c4473d10ed747fb1e84efff7183023e0ecc1a493': add attributes reference for splimotionevents and layoutmode
|
27a8508ee1236ded652cd452b93884a9193654fc |
|
10-Jun-2013 |
Scott Main <smain@google.com> |
add attributes reference for splimotionevents and layoutmode Change-Id: Id78f2957c994fc30a0837084f22766c8cfa70fe8
/frameworks/base/core/java/android/view/ViewGroup.java
|
6410c0aaf13c9aec606b90ee942f2ac2d98b1609 |
|
17-Jun-2013 |
Romain Guy <romainguy@google.com> |
Lazily allocate seldom-used data structures Change-Id: I8d6b9d2d821168329206c01ed6539a1466af272f
/frameworks/base/core/java/android/view/ViewGroup.java
|
00dbe81fea7be57ee2ff8a97844faf1bc15a427f |
|
10-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Notification for changed subtree in accessibility mode not fired properly. We fire notifications that the a view subtree changed for accessibility. In some cases the notifications were fired if accessibility is not enabled. This is now fixed. Also the runnable for making the recurring subtree change was not dequeued if it was pending but we received a request which we decided to run immediately. bug:9337912 Change-Id: I27401b3d11f81c653e8761a704ee530263b08c3a
/frameworks/base/core/java/android/view/ViewGroup.java
|
494cb689d09a82025b9d892241e62aa149ce3239 |
|
07-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Merge "Optimizing AccessibilityNodeInfo caching."
|
f69913056b8c6000ff0306573a97971702e8d35a |
|
06-Jun-2013 |
Romain Guy <romainguy@google.com> |
Remove unnecessary allocations Change-Id: Ia561a0a312ca2737d5afa742184f5392bb2f29a3
/frameworks/base/core/java/android/view/ViewGroup.java
|
6254f4806dd3db53b7380e77fbb183065685573e |
|
05-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Optimizing AccessibilityNodeInfo caching. 1. Before we were firing an accessibility event from the common predecessor of views with accessibility related state changes every X amount of time. These events designate that the tree rooted at the source is invalid and should not be cached. However, some of the state changes do not affect the view tree structure and we can just refresh the node instead of evicting and recaching nodes infos for views that did not change. Hence, we need a way to distinguish between a subtree changed over a node changed. Adding a new event type will not work since if say two siblings have local changes and their predecessor fires a window state change event, the client will drop the subtree rooted at the parent including the two views with changes. Subsequent, more specialized events emitted from the two changed siblings will be useless since the parent which did not changed is already evicted from the cache. Conversely, if the specialized events are fired from the two siblings with local changes and they are refreshed in the cache the subsequent window state change event from the common predecessor will force the refreshed nodes to be evicted. Hence, to enable distinction between node being changed and a subtree baing changed while not changing existing behavior, we will fire only window content change event with an additional argument specifying what changed - node or a subtree for now. Also if the changes are local to a view we fire the window content changed event from the view. So, the two siblings will fire such an event independently and the client will know that these are local changes and can just refresh the node. If the changes are structural, then we fire the window state change event from the common predecessor. 2. Added the input type of a text view as one of the properties reported by an AccessibilityNodeInfo. It is nice to prompt the user what input is expected. 3. Added a bundle for optional information to AccessiiblityNodeInfo. For example, it will be used for putting web specific properties that do not map cleanly to Android specific ones in WebView. 4. AccessibilityInteractionController was not taking into account whether the current accessibility focused node is shown before returing it. Hence, a disconnected node would be returned and caching it puts our cahche in an inconsistent state. Change-Id: I8ed19cfb4a70bdd7597c3f105487f1651cffd9e0
/frameworks/base/core/java/android/view/ViewGroup.java
|
19c618dbce1383541c292251b8b56afc99f1d6b5 |
|
29-May-2013 |
Jeff Brown <jeffbrown@android.com> |
am c8a77735: am dea6e86d: am 3422ceb6: Merge "Bug fix for building the hover target list" * commit 'c8a777356267803be3e235b2fdaf807166fb46eb': Bug fix for building the hover target list
|
dea6e86dce716b67fe92c9b281fe9e79256f3b78 |
|
29-May-2013 |
Jeff Brown <jeffbrown@android.com> |
am 3422ceb6: Merge "Bug fix for building the hover target list" * commit '3422ceb6ba453c28ac39dfce34534e0346394a3a': Bug fix for building the hover target list
|
3422ceb6ba453c28ac39dfce34534e0346394a3a |
|
28-May-2013 |
Jeff Brown <jeffbrown@android.com> |
Merge "Bug fix for building the hover target list"
|
6f3a6a453ac55ac2974d32ead4615746594382c8 |
|
11-May-2013 |
Svetoslav <svetoslavganov@google.com> |
am 1e4c6589: am b3c2b21b: Merge "Accessibility should not query for list items when data set changed." into jb-mr2-dev * commit '1e4c6589941e459871eed6e9d4675b05d977325c': Accessibility should not query for list items when data set changed.
|
5b578daac9cea174b15fcd13528270270aadd8a2 |
|
08-May-2013 |
Svetoslav <svetoslavganov@google.com> |
Accessibility should not query for list items when data set changed. AbsListView is backed by an adapter. After the adapter data changes the view sets a flag that its state is dirty and requests a layout. If an accessibility service asks for the state of a list item at this point, it may incur an error since the views and the adapter are not in sync. Now if an accessibility service queries for a list item when the data set is changed and the item views are dirty, we pretend the children do not exist. After the layout happens, we notify the accessibility layer that the screen content changed so it can refetch the views if desired (this notification mechanism is already in place in AbsListView#handleDataChanged()). bug:8433433 Change-Id: I4287a0ac2ef6bb33f1f988d5ddad973556c305ca
/frameworks/base/core/java/android/view/ViewGroup.java
|
fd06074c684968d372a3ad24d57c5a730532f766 |
|
07-May-2013 |
Romain Guy <romainguy@google.com> |
am c4818d86: am 4c95c537: Merge "Optimize list view scrolls Bug #8108706" into jb-mr2-dev * commit 'c4818d860b90813bde082c381de933933abc574c': Optimize list view scrolls Bug #8108706
|
5549cb590d0c63e4b7717664978e8512e67a9bfa |
|
07-May-2013 |
Romain Guy <romainguy@google.com> |
Optimize list view scrolls Bug #8108706 Change-Id: I8679b584132e82b7bb3301a38800de4ddfc57be6
/frameworks/base/core/java/android/view/ViewGroup.java
|
7caa1a87fe5d8dd229b296323191eaf9326a6786 |
|
06-May-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
am a8549041: am 8c2e3a41: Merge "Optimize RTL properties resolution" into jb-mr2-dev * commit 'a8549041ccdf38f8ddbdc5fc2bce84d737a89a7e': Optimize RTL properties resolution
|
09ecb255a6d37567c8ce43dcd01bfb7ed7488a5d |
|
04-May-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Optimize RTL properties resolution - dont bother children about resolving RTL properties if the ViewGroup parent has not done anything Change-Id: Iedf8a337097e04e1ab0054d59fc347e06b347ea7
/frameworks/base/core/java/android/view/ViewGroup.java
|
7aea41b3d63f5ef5a258323e9fc1e8b0e8fbaf59 |
|
23-Apr-2013 |
Chet Haase <chet@google.com> |
am 393abb1c: am 5e650cef: Merge "Expand invalidation rectangle when clipChildren == false" into jb-mr2-dev * commit '393abb1c54c6b847b81e2390efcd6ec95e8237f8': Expand invalidation rectangle when clipChildren == false
|
a4f14ebe29b9c1286badeb47da19af4df88250dd |
|
22-Apr-2013 |
Chet Haase <chet@google.com> |
Expand invalidation rectangle when clipChildren == false The current invalidation logic does not take into account the clipChildren flag. When this flag is set to false on a container (an uncommon but possible case), it is possible for views in the child hierarchy of the container to be draw outside of the container's bounds. But invalidations on that view hiearrchy can be clipped to the container's bounds, causing us to not redraw views outside of those bounds. Fix is to expand the dirty rect of an invalidation to encompass the complete bounds of any container with clipChildren==false. Issue #680037 Some transform combinations can leave old pixel values on the screen Change-Id: I426beee15d04145fac2f6b4203748ae309e392b4
/frameworks/base/core/java/android/view/ViewGroup.java
|
684634144b15e4da0ed04baa2c4531ef538652a6 |
|
21-Apr-2013 |
Chet Haase <chet@google.com> |
am 371d4ccc: am 339ac854: Merge "Fix quickReject logic to account for setClipChildren() setting" into jb-mr2-dev * commit '371d4cccde56ec4d26e51f8e82ef68f196169a3d': Fix quickReject logic to account for setClipChildren() setting
|
dd671599bed9d3ca28e2c744e8c224e1e15bc914 |
|
19-Apr-2013 |
Chet Haase <chet@google.com> |
Fix quickReject logic to account for setClipChildren() setting The rendering code optimizes by rejecting drawing operations that lie outside of the bounds of their views. This works in most situations, but breaks down when containers have called setClipChildren(false), because we reject drawing that is outside of that container, but which should be drawn anyway. Fix is to pass in the value of that flag to the DisplayList drawing routines which take that flag into account when deciding whether to quickReject any particular operation. Issue #8659277 animation clipping Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
/frameworks/base/core/java/android/view/ViewGroup.java
|
cbd5fe843d76c9d09d89d47f665026a01ac212fb |
|
13-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
am 64076958: am 72ab9b80: Merge "Respect custom view drawing order when dispatching hover events." into jb-mr2-dev * commit '640769589b5eb6a4c9a09f8710c3a585320fa075': Respect custom view drawing order when dispatching hover events.
|
72ab9b801794d42de83d3e7afb70ccc96ade7dfb |
|
13-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
Merge "Respect custom view drawing order when dispatching hover events." into jb-mr2-dev
|
0e5e9aa8e5528d4a09b861f10b599ee7a1cf7a32 |
|
12-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
Respect custom view drawing order when dispatching hover events. 1. The event dispatch methods should respect the child drawing order. Hover event dispatch in ViewGroup was not repsecting this order. bug:8606799 Change-Id: Ie2fd3aff1292c21df23a04ca0aa03a97813c44ef
/frameworks/base/core/java/android/view/ViewGroup.java
|
1d9648df5198cbc47ecb836ce084e9258624e0d2 |
|
13-Apr-2013 |
Chet Haase <chet@google.com> |
am d04215c4: am 0a41431d: Merge "API and doc cleanup, plus small animation/UI features" into jb-mr2-dev * commit 'd04215c440e7b7f4bbfe8aaa9a47ccdf3a8dacf5': API and doc cleanup, plus small animation/UI features
|
430742f09063574271e6c4091de13b9b9e762514 |
|
12-Apr-2013 |
Chet Haase <chet@google.com> |
API and doc cleanup, plus small animation/UI features Adding features which round out the animation APIs (missing getters, etc.). Also fix doc typos. Issue #8350510 Add APIs needed for future animation capabilities Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
/frameworks/base/core/java/android/view/ViewGroup.java
|
c6b0589b085931f10836e47ef6871962359271e0 |
|
09-Apr-2013 |
Chet Haase <chet@google.com> |
am 15c9e15e: am b9604a34: Merge "Amend getOverlay() docs for SurfaceView/TextureView" into jb-mr2-dev * commit '15c9e15e71dba40370946ca3837b80327d2925c2': Amend getOverlay() docs for SurfaceView/TextureView
|
95399493c6070638946e5e6acd3b3872d3a90451 |
|
08-Apr-2013 |
Chet Haase <chet@google.com> |
Amend getOverlay() docs for SurfaceView/TextureView SurfaceView and TextureView do not currently support overlays correctly; the docs now reflect this constraint. Change-Id: I79183c02b51ae4cd14638198d0668b2c2e3e22e1
/frameworks/base/core/java/android/view/ViewGroup.java
|
b7045d2fb9d4b37333dbccb25a2ae9eee3b54577 |
|
08-Apr-2013 |
Chet Haase <chet@google.com> |
am cbfce445: am edf6f4b4: Make adding views specific to a ViewGroup\'s overlay * commit 'cbfce445c500a12fee63e526251471839f44e26b': Make adding views specific to a ViewGroup's overlay
|
edf6f4b49f6e77c349f5055372ce381b74f12efb |
|
26-Mar-2013 |
Chet Haase <chet@google.com> |
Make adding views specific to a ViewGroup's overlay 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
/frameworks/base/core/java/android/view/ViewGroup.java
|
b38af997f683634de436922d45854c1e2d76415a |
|
04-Apr-2013 |
Chet Haase <chet@google.com> |
am 98f69881: am 77d94957: Merge "Adding small animation features" into jb-mr2-dev * commit '98f69881ce28fef261da45c7fbd7ee79e9b8d637': Adding small animation features
|
b989502e5cf44d65c6dddc0179b6d9b6e61ef7fd |
|
03-Apr-2013 |
Chet Haase <chet@google.com> |
Adding small animation features RectEvaluator is useful when animating object bounds. The other change is a hidden API that allows temporary suspension of layout, useful for animations which need to animate view bounds without conflicting with layout passes that might happen in the middle of the animation. Change-Id: I3dc08cb6ec455dfa3409e825506b218d3ea63d7a
/frameworks/base/core/java/android/view/ViewGroup.java
|
cfa775447e2a2b76c38b5ae5954fb64c8c2b48e3 |
|
30-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 68951ee9: am 83390182: Merge "Optimize ViewGroup.MarginLayoutParams memory and fix ViewDebug" into jb-mr2-dev * commit '68951ee958e72319facc267289ca363622758e0a': Optimize ViewGroup.MarginLayoutParams memory and fix ViewDebug
|
b365f91688dc081b3bcea82377ce0e94c09124ff |
|
28-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Optimize ViewGroup.MarginLayoutParams memory and fix ViewDebug - use private flag bit field for ViewGroup.MarginLayoutParams - make ViewDebug support "byte" type for FlagMapping Change-Id: Iff7c31544e3ce2d29919c9424425f2bf87042b8b
/frameworks/base/core/java/android/view/ViewGroup.java
|
97207ab9669ebb9c166c5d8aa2cd354f2081dbe3 |
|
27-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 9fb9a0f3: am f7fa08b7: Merge "Fix bug #8487785 Notification shade has text overlapping the icon" into jb-mr2-dev * commit '9fb9a0f3b8c22ca538a36b81769c7e1080fcf9f9': Fix bug #8487785 Notification shade has text overlapping the icon
|
f7fa08b7024fa91001080a766cd9ac8eab82d634 |
|
27-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #8487785 Notification shade has text overlapping the icon" into jb-mr2-dev
|
02a7d5637c961632dc67cd0012addfdd6060885b |
|
27-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #8487785 Notification shade has text overlapping the icon - follow up to the fix for bug #8480245 ViewGroup layout margins can be wrong in RTL mode - deal with "RTL compatibility mode": if left/right margins are not defined and if we haev some start/end ones then use the start/end ones. Change-Id: I98fe3276de2bd14f60a1c423a47569a68046f7be
/frameworks/base/core/java/android/view/ViewGroup.java
|
9a8c46f64e9fb1bff30d16a3f6a16e8f261f1225 |
|
27-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
am fc7a1020: am a803b094: Merge "Fix bug #8480245 ViewGroup layout margins can be wrong in RTL mode" into jb-mr2-dev * commit 'fc7a1020716d86204e7190b899a2e30fba4e9055': Fix bug #8480245 ViewGroup layout margins can be wrong in RTL mode
|
a803b094c6c60539426396ad57f0733cbe212664 |
|
27-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #8480245 ViewGroup layout margins can be wrong in RTL mode" into jb-mr2-dev
|
0072f64939b37a4d84940656c2180ad2e0594ff4 |
|
26-Mar-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #8480245 ViewGroup layout margins can be wrong in RTL mode - fix resolution of MarginLayoutParams - update related RelativeLayout code Change-Id: I261f127a8897f60d316fed2a73e6e76020e542cc
/frameworks/base/core/java/android/view/ViewGroup.java
|
89d4c0f3cb88b6366f26b1745db78bcef3680831 |
|
26-Mar-2013 |
Chet Haase <chet@google.com> |
am 656ed307: am bc6c050f: Merge "Fix touch processing for Overlay views" into jb-mr2-dev * commit '656ed307168ec2006108877a03788a31b15ebb78': Fix touch processing for Overlay views
|
9c17fe693deb0cc84099b619185472f192c2b52d |
|
23-Mar-2013 |
Chet Haase <chet@google.com> |
Fix touch processing for Overlay views 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
/frameworks/base/core/java/android/view/ViewGroup.java
|
36350a9592425c2bb4984eb2374356d2459238c4 |
|
18-Mar-2013 |
Chet Haase <chet@google.com> |
am fb38986e: am 138c58a9: Merge "Add overlays to views" into jb-mr2-dev * commit 'fb38986e452a51b6ce37131f293316adedc75ff0': Add overlays to views
|
91cedf1c3dbf7a52c2892294b2e5ba3e40ef3583 |
|
11-Mar-2013 |
Chet Haase <chet@google.com> |
Add overlays to views 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
/frameworks/base/core/java/android/view/ViewGroup.java
|
8725f36a76bdf85d7197e64fb725b67e993c6ce7 |
|
13-Mar-2013 |
Sangkyu Lee <sk82.lee@lge.com> |
Bug fix for building the hover target list lastHoverTarget should be updated even though lastHoverTarget is not null. If not, the hover target list cannot have more than one hover target. Change-Id: I21b49e8cbf3657321b2f1f2c20a3bdeb7f07bd48 Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
/frameworks/base/core/java/android/view/ViewGroup.java
|
32884c376fd06799f46ea3b1ded89ba9d21f8f14 |
|
07-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
am 6fea1665: am 1ab64b81: Merge "Add new sample code for writing a ViewGroup." into jb-mr2-dev * commit '6fea1665a91dafa49b78d1c92c53bb0fa1736020': Add new sample code for writing a ViewGroup.
|
7caab0ff2d4a09a1aa5f5c1d8479c386584cc26e |
|
06-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new sample code for writing a ViewGroup. Change-Id: Id6714b062884c9ed60703e5c199f16683c00a800
/frameworks/base/core/java/android/view/ViewGroup.java
|
c2a6e194a682d5b4c327c4c02289b4d96cf564e1 |
|
05-Mar-2013 |
Philip Milne <pmilne@google.com> |
Merge "Optical Bounds: clear inherited layoutModes when layoutMode of root layout is set to a new value."
|
f091b662467eeca05ac0de9c8f3f120f4dde5bdc |
|
27-Feb-2013 |
Philip Milne <pmilne@google.com> |
Optical Bounds: clear inherited layoutModes when layoutMode of root layout is set to a new value. This is an addendum to: https://googleplex-android-review.googlesource.com/#/c/246507 Change-Id: Ia9d6fdfe7fdb76c1152466315ff3b1c42c077ee2
/frameworks/base/core/java/android/view/ViewGroup.java
|
267097b00b073716ab2d02c3c068889d92ddb1a9 |
|
04-Mar-2013 |
Christopher Tate <ctate@google.com> |
DO NOT MERGE: Don't crash when we get a drag-ended after being detached Removing view groups during a drag would cause an NPE here. The child views will still get the drag-ended event as expected. (Cherrypicked from downstream) Bug 8298439 Change-Id: Ic14cbf9fdc305b91c1627f6882a45d34ee1c34ae
/frameworks/base/core/java/android/view/ViewGroup.java
|
e9accff210c25b0a4946925db699874331c8cb61 |
|
04-Mar-2013 |
Christopher Tate <ctate@google.com> |
Don't crash when we get a drag-ended after being detached Removing view groups during a drag would cause an NPE here. The child views will still get the drag-ended event as expected. Bug 8298439 Change-Id: I665ba1d139e8aaa820f5f515186bc4ce8bcdb1ea
/frameworks/base/core/java/android/view/ViewGroup.java
|
cfb631b0e56b7c6b9ca11e1a0553b7896b64b1c1 |
|
26-Oct-2012 |
Philip Milne <pmilne@google.com> |
When layoutMode is undefined, inherit the value defined by the parent (recursively). Change-Id: Ib5f1150d2ac132d9ec79204a974cea8945d742b4
/frameworks/base/core/java/android/view/ViewGroup.java
|
52036b19a5f82bc4d75cfcbff99c65df8d25a99b |
|
15-Feb-2013 |
Romain Guy <romainguy@google.com> |
Expose display list APIs The exposed APIs are slightly simpler than the full APIs used internally. Only APIs useful to applications are exposed. Change-Id: Ie03014628d40ad5ef63dedbc52ce3def84429d54
/frameworks/base/core/java/android/view/ViewGroup.java
|
149567f9d59a07a9d7793ea455ff4c2586c3ae53 |
|
09-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing a memory leak in ViewRootImpl and a focus change callback issue. 1. ViewRootImpl was keeping reference to the old focused view so it can call back the global on focus change listener when another view gets focus. The stashed reference, however was not cleared which caused a memory leak if the last focused view was removed from the view tree. In general keeping additional state for the last focus in ViewRootImpl is not a good idea since this add complexity due to additional book keeping work that is required. The view tree already keeps track of where the focus is and it should be the only place that holds this data. Since focus does not change that frequently it is fine to look up the focus since this operation is O(m) where m is the depth of the view tree. This change removes the duplicate book keeping from ViewRootImpl and the focus is looked up as needed. 2. ViewRootImpl was calling the global focus change callbacks when focus is gained, lost, or transferred to another view. This was done in *ChildFocus methods. In the case of a child losing focus, i.e. in clearChildFocus, there was a check whether focus searh yields a view to take focus and if so it did not call back the global focus listener assuming the the found view will take focus (the view tree gives focus to the first focusable when a view looses focus). This is not a correct assumption since some views override methods called as a result of View.requestFocus that determine what the next focused view should be. For example, HorizontalScrollView overrides onRequestFocusInDescendants and changes the direction of the search. In fact focus search does not take into accound ViewGroup descendant focusability. Hence, the view found by calling the focus search from the root is not necessarily the one that will get focus after calling requestFocus. Actually, it is possible that the focus search will find a view but no view will take focus. Now the View class is responsible for calling the global focus listeners which avoids the above problem. Also this saves book keeping in ViewRootImpl. bug:7962363 Change-Id: Ic95a18b364e997021f3f6bb46943559aac07d95a
/frameworks/base/core/java/android/view/ViewGroup.java
|
77c67665c83f824ca59c2dcf40d7fe4e3cd7b865 |
|
01-Dec-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "resolved conflicts for merge of 8794c80d to master"
|
be922dc976b1ce1735dcc0cf49509a2149766c96 |
|
01-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding pool management via the poolable APIs to some classes. 1. Removed the support for infinite pool size which nobody was using and does not make sense. 2. Update some classes in ViewGroup to use the poolable APIs. Change-Id: Ifdb8c10968cd06fe53085ec9d3d649f7c9a944b7
/frameworks/base/core/java/android/view/ViewGroup.java
|
5412ba1cb91527070dda81c3b0e602631765164e |
|
01-Dec-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
resolved conflicts for merge of 8794c80d to master Change-Id: I61313a3dd4cd0bcbf04c16dc17996a997b43fe0c
|
cb5f9db47a471620061ccb6a574afc209c610dd2 |
|
01-Dec-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7651552 resetRtlProperties() is called way too often - remove unnecessary calls to resetRtlProperties(). - now reset of RTL properties will only be done when adding a View (and no more when removing it) Change-Id: I0d42128c9f7df6085fb92bb5af5c9bd4d1ba88a3
/frameworks/base/core/java/android/view/ViewGroup.java
|
6fb05630cf406f3844878d44c585754cd160567e |
|
29-Nov-2012 |
Romain Guy <romainguy@google.com> |
Fire view removed event *after* a View is removed Change-Id: Ia4066002b19c438c90a57ef9c513d82564425640
/frameworks/base/core/java/android/view/ViewGroup.java
|
ea5e56ad9c2324dd6fbeab64e031878e03122c40 |
|
30-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am d31f0ab9: am 9d662c77: am 68b14054: Merge "Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)"" into jb-mr1-dev * commit 'd31f0ab93f4f35a7ca6df6d428db2a5fd3d6750a': Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)"
|
46e62fe39874abf2a9bdfab7635df98011c03cd1 |
|
30-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 024e70c8: am dd80335e: am 07ce0ca2: Merge "Fix bug #7419054 TextView Drawables resolution is broken in RTL mode" into jb-mr1-dev * commit '024e70c8156a0fa2d702ff2fba4a38c1f6b68f98': Fix bug #7419054 TextView Drawables resolution is broken in RTL mode
|
68b14054b96571d4009c6c5a9b4c3413d908a523 |
|
27-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)"" into jb-mr1-dev
|
bb4b601673a4f910d3e467bc5ce39538438859ce |
|
27-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)" This reverts commit 6bf6eb7d5f9207d6a3e1d6b61f17a8654d06fbdb. and also fbc21e126f329b7b7c161858c1390ccb023be07e I have also removed all unnecessary calls to resolveLayoutDirection(int). This is possible as we are resolving layout params on every child of a ViewGroup as of commit fcc3348f61b2992f0b84e8e8dcb3535fc715298f Change-Id: I262a375b03fcc3c9261cbe2edebb6ec42ec2e186
/frameworks/base/core/java/android/view/ViewGroup.java
|
1957d281ea123e4925e51fa5ad22ce239ef2a07d |
|
26-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7419054 TextView Drawables resolution is broken in RTL mode - check layout direction previous value in the onResolveDrawables(int) callback - dont do any Drawables resolution if we cannot resolve the layout direction - also remove unnecessary call to resolveRtlPropertiesIfNeeded() in ViewGroup when adding a child as the call to resolveRtlPropertiesIfNeeded() will be done into the measure() call itself later Change-Id: I62237af3d307dfea203f7f2865551d1c61a0e0b8
/frameworks/base/core/java/android/view/ViewGroup.java
|
3c371b28ef0e55ccd03ddc772fb5df62486cd09f |
|
20-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 0be6a28e: am 08f27b1b: am 59420ecd: Merge "Fix bug #7164967 android.view.cts.ViewGroup_MarginLayoutParamsTest#testResolveMarginsRelative failures on JO" into jb-mr1-dev * commit '0be6a28ed5f27217d66c69195524d8747a6975bc': Fix bug #7164967 android.view.cts.ViewGroup_MarginLayoutParamsTest#testResolveMarginsRelative failures on JO
|
d3156a2a5656e154b517b5fd3498fc46c045fcd3 |
|
20-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7164967 android.view.cts.ViewGroup_MarginLayoutParamsTest#testResolveMarginsRelative failures on JO This was a regression introduced by a previous CL. - we actually need to let the layout params resolution goes all the time as we dont have any "isResolved" state and a public API for doing its reset thru ViewGroup. The current implementation is simple and works even if it is doing sometimes a bit more than it should really do. This is a well conscious tradeoff. Change-Id: I5c4d532331b3970dfe88f016bc305cbc4a0d83f1
/frameworks/base/core/java/android/view/ViewGroup.java
|
0b9b415632f559d893ac9ee5e43385d6ffb65b99 |
|
19-Oct-2012 |
Dave Burke <daveburke@google.com> |
am b1f434c1: am 744b4dca: am 09a5321c: Merge "Revert "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.""" into jb-mr1-dev * commit 'b1f434c16eefb028ef441ba40df8abe1e087a4eb': Revert "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.""
|
09a5321c60c02d944684abb98e0daec9dd810fab |
|
19-Oct-2012 |
Dave Burke <daveburke@google.com> |
Merge "Revert "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.""" into jb-mr1-dev
|
579e14016c4a972e70cd2bd0c6d89bbd7e9e941c |
|
19-Oct-2012 |
Dave Burke <daveburke@google.com> |
Revert "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."" This reverts commit 57fca90ac65ecfe97acd4c93d442c3db8f815e11 Change-Id: I21b007a7d150a4c23f25a706cdba5cb86198198f
/frameworks/base/core/java/android/view/ViewGroup.java
|
c38684af87787b6625dc72a0dc0ce5b8d4abb3b9 |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 4c2db5f2: am 8de328c9: am 45c77ca0: Merge "Fix missing @hide on ViewGroup.resolveLayoutParams()" into jb-mr1-dev * commit '4c2db5f2a579132f6b6861c50d7ff99bb6c8035c': Fix missing @hide on ViewGroup.resolveLayoutParams()
|
1e0ed6b2320893efdecdf300a9adf1dce3700710 |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix missing @hide on ViewGroup.resolveLayoutParams() - as we dont need this to be public Change-Id: Ib8de262eec26d4785b13875d59599369b06a067d
/frameworks/base/core/java/android/view/ViewGroup.java
|
f9d08423e3d922d22f628e2628885b3d966e40be |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 6cb9d909: am 8c2bc7cc: am 07f85fec: Merge "Fix bug #7374285 GridLayout layout param margins are broken in RTL mode" into jb-mr1-dev * commit '6cb9d909f06433c5b9130c55dc08ce8d55e7dac8': Fix bug #7374285 GridLayout layout param margins are broken in RTL mode
|
fcc3348f61b2992f0b84e8e8dcb3535fc715298f |
|
18-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7374285 GridLayout layout param margins are broken in RTL mode - resolve layout params in ViewGroup when layout direction is changed - layout param resolution is checking the previous layout direction to check if we need to resolve Change-Id: I70af2ad2b4ec83c2ec6c93b3ff445852500d1687
/frameworks/base/core/java/android/view/ViewGroup.java
|
f1149452694713670a5e3849693841c0fbab0f25 |
|
18-Oct-2012 |
Justin Ho <justinho@google.com> |
am 22bd3726: am 76a01424: am 871a6d7d: Merge "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."" into jb-mr1-dev * commit '22bd3726be37a24e956d962d61657d8a3d54c985': Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."
|
5c555f39fb9bb1a47c081ae62658454e92792f44 |
|
18-Oct-2012 |
Justin Ho <justinho@google.com> |
am 0efebf0a: am c35f7650: am 4db31657: Merge "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height." into jb-mr1-dev * commit '0efebf0af4c21b9d02c9c06b67867a554e0b35ea': This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.
|
871a6d7d4fb3bffaff37e45f0b4f5e3c862239d2 |
|
18-Oct-2012 |
Justin Ho <justinho@google.com> |
Merge "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."" into jb-mr1-dev
|
4e360f06003dd31da25dc8529fa1876ab573d0aa |
|
18-Oct-2012 |
Justin Ho <justinho@google.com> |
Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height." This reverts commit f49d835dfe1bd21920ff8a48cbdfb9c1fd632fd9 Change-Id: If0093f23d6458e53619220fbf0aa5f844ad2c790
/frameworks/base/core/java/android/view/ViewGroup.java
|
4db3165793a837ffc8197184fbc13ef2217e3dfc |
|
18-Oct-2012 |
Justin Ho <justinho@google.com> |
Merge "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height." into jb-mr1-dev
|
f49d835dfe1bd21920ff8a48cbdfb9c1fd632fd9 |
|
18-Oct-2012 |
Justin Ho <justinho@google.com> |
This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height. This reverts commit 57fca90ac65ecfe97acd4c93d442c3db8f815e11 Change-Id: I0fe25056cd54b8852b32ae4621e048d3f5c7d555
/frameworks/base/core/java/android/view/ViewGroup.java
|
7daab459678efb2b7e4cf5e80d3b774b9defffcb |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 7e8d16fb: am 84cb0b17: am 161cfef3: Merge "Fix bug #7363015 Padding is wrong for first item in a ListPopupWindow" into jb-mr1-dev * commit '7e8d16fbfd8b83a743527412edf6bb4e767f37aa': Fix bug #7363015 Padding is wrong for first item in a ListPopupWindow
|
161cfef36d8fac79f8665ecdb78d3f8f8f5ba5af |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #7363015 Padding is wrong for first item in a ListPopupWindow" into jb-mr1-dev
|
8814ec37969656c01218cf80cef0504e7961ba47 |
|
17-Oct-2012 |
Justin Ho <justinho@google.com> |
am 47270268: am 8598646e: am 144d4055: Merge "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."" into jb-mr1-dev * commit '472702687d174c126752259485b83c39f3eb2801': Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."
|
57fca90ac65ecfe97acd4c93d442c3db8f815e11 |
|
17-Oct-2012 |
Justin Ho <justinho@google.com> |
Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height." This reverts commit dcf59629beed8182759a1068ab8ee997935bef82 Change-Id: I27426a0ffe993973ffb0b05ce1ed3afe73fcd87d
/frameworks/base/core/java/android/view/ViewGroup.java
|
a7e0bcd87287ff2f11cdd872026f2eb9ee22bcd0 |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7363015 Padding is wrong for first item in a ListPopupWindow - when adding a View to a ViewGroup reset all RTL properties of the View to be added instead of only resetting its layout direction Change-Id: Idfa3acce1700c52e20ebfd4c9c4f4ecb3c1d7520
/frameworks/base/core/java/android/view/ViewGroup.java
|
f7b77f1285ea9635085d2621a1db8d67316fcbd5 |
|
17-Oct-2012 |
Jim Miller <jaggies@google.com> |
am ef512f03: am cccf85c2: am 8e614501: Merge "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height." into jb-mr1-dev * commit 'ef512f03e3a10b39e82c9029d9d7623915ac8850': This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.
|
dcf59629beed8182759a1068ab8ee997935bef82 |
|
17-Oct-2012 |
Jim Miller <jaggies@google.com> |
This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height. Revert "Revert "Revert "Fix for bug 6050753.""" This reverts commit 6868d6f349610c15256471cc3d5fa708cbfd5f1d Change-Id: I8843d92dba14c82f06d9ee59517cf11b2abbbf04
/frameworks/base/core/java/android/view/ViewGroup.java
|
d8c4f50981a887b8332ad3abdb51c4cb4151dcb8 |
|
16-Oct-2012 |
Mathias Agopian <mathias@google.com> |
am 1167b7b9: am dcfe6cee: am 6868d6f3: Revert "Revert "Fix for bug 6050753."" * commit '1167b7b9e43878f077478f58e31e268c2e191110': Revert "Revert "Fix for bug 6050753.""
|
6868d6f349610c15256471cc3d5fa708cbfd5f1d |
|
16-Oct-2012 |
Mathias Agopian <mathias@google.com> |
Revert "Revert "Fix for bug 6050753."" Emergency revert -- fix reboot loop. This reverts commit 8e63bcc63fd002231f8391af8982eeb235d096c8. Change-Id: I4373b867d756de09cdf6aa0aba9e6ff8f47bcdbc
/frameworks/base/core/java/android/view/ViewGroup.java
|
dabcbfe46dd202aa03d0b1580f568c4ba4fba915 |
|
16-Oct-2012 |
Romain Guy <romainguy@google.com> |
am 3e6c9ba6: am cb09dba0: am 69fbc3c0: Merge "Revert "Fix for bug 6050753."" into jb-mr1-dev * commit '3e6c9ba6777cec3b3928ddb2b399c957735f7b06': Revert "Fix for bug 6050753."
|
8e63bcc63fd002231f8391af8982eeb235d096c8 |
|
15-Oct-2012 |
Romain Guy <romainguy@google.com> |
Revert "Fix for bug 6050753." This reverts commit c29f031598811486d83f418fd08fbfe1fc41788a.
/frameworks/base/core/java/android/view/ViewGroup.java
|
58072b573d4840199e3d19f3d6f6a873281c2e40 |
|
13-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am df4bcd6a: am b65b5133: am f9307c5c: Merge "Fix bug #7334966 Padding is still broken in RTL languages" into jb-mr1-dev * commit 'df4bcd6a36ae2e0248791f35c10f6f100543b2c6': Fix bug #7334966 Padding is still broken in RTL languages
|
84ebb35f392478600ddf8f08107fb345f13ef91c |
|
12-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7334966 Padding is still broken in RTL languages - do correct resolution and reset propagation for all RTL properties (padding and drawables included) - fix CheckedTextView padding too Change-Id: Ie603683a2324b2a6ef2c03633d01d5726c883b90
/frameworks/base/core/java/android/view/ViewGroup.java
|
0c5c23b3a237df63273694c2df594833836be9ed |
|
12-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 4c95bfd5: am 39b0c29e: am ec139240: Merge "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)" into jb-mr1-dev * commit '4c95bfd5ad4d17b6e0e618cd3244ee2d33bcbda1': Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)
|
6bf6eb7d5f9207d6a3e1d6b61f17a8654d06fbdb |
|
11-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic) Part 2 - fix remaining UI widgets by asking layout params resolution when needed Change-Id: I97c41639da645d77eeda85feec3bbcc7fc1260b9
/frameworks/base/core/java/android/view/ViewGroup.java
|
6acf744fab8441f18e8aa1599aa9d6937ac8707a |
|
11-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am f4a1dad6: am 5b04d032: am b8021a88: Merge "Fix bug #7326778 Rename LayoutParams.onResolveLayoutDirection(int)" into jb-mr1-dev * commit 'f4a1dad63db89b805df0c83b2044dad0d60e3686': Fix bug #7326778 Rename LayoutParams.onResolveLayoutDirection(int)
|
2918ab6c3258639148b8a5c78a34483af195246e |
|
11-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7326778 Rename LayoutParams.onResolveLayoutDirection(int) - rename to LayoutParams.resolveLayoutDirection(int) - upate 17.txt too Change-Id: I54fe28dc47cfdb65ef0b5b0244dabbe1d675c781
/frameworks/base/core/java/android/view/ViewGroup.java
|
9c377bd2d6c8315c6917ed58b2b7a5f6fb8b8a4c |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 481a0aac: am 88ae2e2a: am d9c99124: Merge "Incorrect temporary detach of accessibility focused view may lead to a crash." into jb-mr1-dev * commit '481a0aac1f28233854ead339f0c9697eb1286653': Incorrect temporary detach of accessibility focused view may lead to a crash.
|
c8860602726d771c69a3fefedfa03419d1c03b1c |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect temporary detach of accessibility focused view may lead to a crash. 1. If an app naither reattaches nor removes detached view that has accessibility focus, an exception in the drawing of accessibility focus occurs since we are trying to compute the focused rect by offseting the bounds of the focused view in coords of the root but the focused one is not attached. bug:7297191 Change-Id: Ib69d52e474b8ea365754f5311f5e809bd757dd1a
/frameworks/base/core/java/android/view/ViewGroup.java
|
a1a2cdf78aebd8d58ea722bc249e2efd69a8541a |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 5bfa59b3: am 82d5b6e1: am 020daada: Merge "Accessibility focus not cleared on temporary detach." into jb-mr1-dev * commit '5bfa59b32fcfd09fcd66381cc7d951f156d1363b': Accessibility focus not cleared on temporary detach.
|
8d0739da7ff6589101f1dc2d5f579f3bfdefd3b4 |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus not cleared on temporary detach. 1. There was a path for removing a view without clearing its accessibility focus. Then when we try to draw the focused rectangle we get an exception since the accessibility focused view is not attached to the view tree when computing the location of the rectangel to draw. bug:7297191 Change-Id: I81e3c35e830e27cf95e73accb665629d0c456afb
/frameworks/base/core/java/android/view/ViewGroup.java
|
3c269280620bf76b96752e9cae27687a13c72e1b |
|
28-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 2f37d37c: am 8af2a13d: Merge "Fix bug # 7172247 API REVIEW: android.view.ViewGroup.MarginLayoutParams" into jb-mr1-dev * commit '2f37d37c60ab3572b09fc06d2380624456a83666': Fix bug # 7172247 API REVIEW: android.view.ViewGroup.MarginLayoutParams
|
658d260b1af30998af2b5857c8c621284f2cd06e |
|
28-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am b1b6be8b: am 669aa7cb: Merge "Other improvements for bug #6427629 Clean up layout direction APIs" into jb-mr1-dev * commit 'b1b6be8bc36a95eab263c04cc77d3b7d29ca06f4': Other improvements for bug #6427629 Clean up layout direction APIs
|
8af2a13d038002522c2f4e5d65bd703db9f86a08 |
|
28-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug # 7172247 API REVIEW: android.view.ViewGroup.MarginLayoutParams" into jb-mr1-dev
|
03b8d3a9a4d5c04953e2370fc44fe5e40a381910 |
|
28-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug # 7172247 API REVIEW: android.view.ViewGroup.MarginLayoutParams - remove isLayoutRtl() from public API Change-Id: If700e3f5f30e3c98403b48dbcdd892535d929e2d
/frameworks/base/core/java/android/view/ViewGroup.java
|
9a04856d5ecb07dea564feae2942fd485b53f3dd |
|
26-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Other improvements for bug #6427629 Clean up layout direction APIs - hide isLayoutRtl() from public API - canResolveXXX() is now smarter: use recursion to get its returned value - in ViewGroup, if resolution cannot be done then dont ask resolution for its children - in ViewGroup, addViewInner() needs to ask to resolve the child. This is needed for example by ListView which is using the same measurespec before and after its childs being attached. It also take care of the general case where a measure pass is done when not attached to a parent (and thus asking for resolution that will "fail" if we are using IHNERIT) and never done again. That would lead to never do a resolution. - some code refactoring Change-Id: I120dd2fef7397944f5ba8deff0686b108dc827d2
/frameworks/base/core/java/android/view/ViewGroup.java
|
ad365cc217c989c3b688ae839d6f94ee8889a84e |
|
27-Sep-2012 |
Philip Milne <pmilne@google.com> |
Optical bounds support for LinearLayout, TableLayout and TableRow. The generic support for optical bounds provided in: https://googleplex-android-review.googlesource.com/#/c/228269/ did not work correctly for nested LinearLayouts. With this fix all the layouts in the APIdemos now seem to layout correctly when the optical bounds mode is enabled. (There's currently no, user level, way to do this. Instead, the optical bounds layout mode has to be enabled on a per view basis.) Change-Id: Id3d1d84445a8a2df277ddfe679c42f2d6cf775f4
/frameworks/base/core/java/android/view/ViewGroup.java
|
d28c3643a60853dfd4cdf71496a5ab4aabd6fb43 |
|
26-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 21289957: am fea9df63: Merge "Fix bug #6427629 Clean up layout direction APIs" into jb-mr1-dev * commit '21289957a91213c922236deb6010dbde1d652c5e': Fix bug #6427629 Clean up layout direction APIs
|
1f88ba8bf67bb9264e39547ab1201aa3c5395d0e |
|
24-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #6427629 Clean up layout direction APIs - getLayoutDirection() / getTextDirection() / getTextAligment() dont do resolution - resolution done into onMeasure() - use XX_RESOLVED bits to check if resolution needs to be done - code formatting Change-Id: Ie46a5535860e90f3449b96cfe0aa04dd7e3006d7
/frameworks/base/core/java/android/view/ViewGroup.java
|
8c549d6ffec427ed3f8f99eb25ffefaf55003893 |
|
25-Sep-2012 |
Philip Milne <pmilne@google.com> |
Merge "Bug #6110465. Optical bounds support for all ViewGroup subclasses."
|
1a7d487380460b4aea37140baf6bf4bf7f92f8a5 |
|
24-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #6427629 Clean up layout direction APIs - rename getResolvedTextAlignment() to getTextAlignment() Change-Id: I6a2b6c9ec4f5cea1adde46e35d5f3c49880791ee
/frameworks/base/core/java/android/view/ViewGroup.java
|
97e146cf02f87b91f81c37d53644e5415efddb72 |
|
24-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #6427629 Clean up layout direction APIs - rename getResolvedTextDirection() to getTextDirection() Change-Id: Id2a6025daf5521dcd676e454fc6bb9955fdccf2d
/frameworks/base/core/java/android/view/ViewGroup.java
|
e56ffdc7b31b0937628609cc3bbaa15879023569 |
|
23-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #6427629 Clean up layout direction APIs - rename getResolvedLayoutDirection() to getLayoutDirection() Change-Id: I3afe56c0db0751952f5056c23893cb7455531d29
/frameworks/base/core/java/android/view/ViewGroup.java
|
4457e85a7090ad51726d50a4daf981d917cceedd |
|
19-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #6427629 Clean up layout direction APIs - canResolveXxx() should be hidden - resetResolvedXxx() should be hidden - resolveDrawables(), resolveLayoutDirection(), resolvePadding(), resolveTextAlignment(), resolveTextDirection() should be hidden - onResolvedXxx() should be merged into one callback - fix also an issue with setting the layout direction of the drawable in ImageView - fix also an issue with checking if TextAlignment can be resolved Change-Id: I1402269ddf8632525f5550f80e5610e1a7b4034d
/frameworks/base/core/java/android/view/ViewGroup.java
|
7b7578184567f4e4f0740ce935cc192765410cca |
|
20-Sep-2012 |
Philip Milne <pmilne@google.com> |
Bug #6110465. Optical bounds support for all ViewGroup subclasses. This CL generalizes the optical bounds support previously contained in the GridLayout implementation and then incorporates the new form directly into the base View and ViewGroup implementations. After this change, GridLayout is returned to an 'optical bounds' unaware state, and all layouts (including non-platform ones) inherit the ability to perform their layout operation by optical (rather than clip) bounds using their existing implementations. The "layoutMode" property of ViewGroup and its associated constants are made public in this CL. Change-Id: Ic1bba0e1c6fc14da4aeab0b28c975d562b5f82dd
/frameworks/base/core/java/android/view/ViewGroup.java
|
61a21770b789ad87b5ed5da3565d0d39939fdd5c |
|
13-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix Javadoc spelling Change-Id: I93685d3d092ce5e16bfa0e65e11d85ae030f3f29
/frameworks/base/core/java/android/view/ViewGroup.java
|
a40627daee4891ab842fa509af254b349bff3a47 |
|
12-Sep-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Enforce encapsulation for MarginLayoutParams startMargin and endMargin Change-Id: Ibaf5ade22612dfa52173978e4b520a6407162d13
/frameworks/base/core/java/android/view/ViewGroup.java
|
ca479d468be963661fd82634f4b57f21c13f1fe6 |
|
31-Aug-2012 |
Chet Haase <chet@google.com> |
Make detachViewFromParent more robust Calling detachViewFromParent() without calling remove or attach in the same drawing frame could, in some situations, cause a crash in the native DisplayList code. detach/attach are intended to be very lightweight and do not manage the native DisplayList content the same way that add/remove do. Nor do they cause an invalidate() or requestLayout(), which would cause the native structures to get recreated appropriately. This fix makes this process more robust in two ways: - DisplayLists should not get finalized (therefore destroying their native structures) when there are still parent DisplayLists referring to them (each DisplayList keeps references to its child DisplayLists). This will prevent the native crash associated with unmatched detach*() calls. - The docs for detach/attach have been enhanced to make it easier for developers to understand how to use these methods more correctly and successfully. Issue #7064818 detachViewFromParent() should be more robust Change-Id: I53befc04d5d58c225060f397725566d470488c9b
/frameworks/base/core/java/android/view/ViewGroup.java
|
99de2459e200e0c86d55d5eee7ea000fd030990f |
|
20-Aug-2012 |
Adam Powell <adamp@google.com> |
Merge "Respect child drawing order when dispatching touch events" into jb-mr1-dev
|
4702a856973a553deb82f71b1d3b6c3db5dbf4ba |
|
18-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
More view hierarchy, fragment debugging. Add a View.toString() method. Rename all of the View private flags to have a PFLAG prefix to avoid going insane trying to figure out which constant goes with which flag. Activity.dump() now includes a summary of the activity's view hierarchy, using the View.toString() method. All exceptions thrown by FragmentManager now perform a dump of the owning activity state, where appropriate. Change-Id: I6482e397e10cb5a0612ab02ce6ed5131823437a6
/frameworks/base/core/java/android/view/ViewGroup.java
|
a6478a3a130c3680bc6d8fa6490ac805fa15bdd2 |
|
18-Aug-2012 |
Adam Powell <adamp@google.com> |
Respect child drawing order when dispatching touch events Make sure that touch events are always dispatched to the "topmost" view when views overlap. Bug 6996501 Change-Id: I4df25dd7531c4b268c8377c0bf0945ab862733b9
/frameworks/base/core/java/android/view/ViewGroup.java
|
23c89fd1685a006957dc0f2aacf167b4449f3d80 |
|
13-Aug-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Improve resolution of RTL related properties - fix bug #6887370 ListPreference shows misaligned radio drawables (in CheckedTextView?) - fix bug #6938146 "Show more cards..." text on bottom button is not centered - also defer scrollbar initialization as we need resolved padding values for them Change-Id: Ife651ffe6bbcc228ff6724f3d9b91079fac3a740
/frameworks/base/core/java/android/view/ViewGroup.java
|
2440e670de0294bdf64592849613db9b8f00ee11 |
|
07-Aug-2012 |
Romain Guy <romainguy@google.com> |
Catch padding changes in ViewGroup to properly clip children Bug #6886339 RTL support introduced a new way to handle padding which broke existing behavior in ViewGroup.setPadding(). The new code path was not notifying ViewGroup which would prevent it from setting a flag used to clip children. Change-Id: I584143714cb81fd664b4ecd9fb51d56bae04ba05
/frameworks/base/core/java/android/view/ViewGroup.java
|
ddd88726a247e4100cb62b3dc9d0887ca2ae2ec4 |
|
26-Jul-2012 |
Jeff Smith <whydoubt@yahoo.com> |
am 71930dd7: am a45746ef: Fix several cases of broken droiddoc syntax external issue 35214 * commit '71930dd77e4dc6f6be5c648019d2ab0da5f0584c': Fix several cases of broken droiddoc syntax external issue 35214
|
a45746efadd11bb7dfab026fb3c81a25fae74ca4 |
|
19-Jul-2012 |
Jeff Smith <whydoubt@yahoo.com> |
Fix several cases of broken droiddoc syntax external issue 35214 patch contributed by Jeff Smith <whydoubt@yahoo.com> Change-Id: I70dcee88a140699bf3e1ab369bed6dcd2fdd3d83
/frameworks/base/core/java/android/view/ViewGroup.java
|
2624c3adbecaf9ca2f97b7912899ecd1bc0a05da |
|
25-Jul-2012 |
Ed Heyl <edheyl@google.com> |
Merge "Account for static child transformations correctly"
|
599913d6e8e610665fad7edd7dfbd3cd48758b3a |
|
24-Jul-2012 |
Chet Haase <chet@google.com> |
Account for static child transformations correctly Optimizations in drawing and invalidation in JB did not correctly account for static child transforms (View.getChildStaticTransformation()). For the invalidation part, this meant that views were not properly setting the invalidation bounds (which should be transformed by the static transform), so the affected area of the invalidation was potentially incorrect. For the drawing part, this meant that views outside of their parent's bounds were being incorrectly rejected when the static transform would, in fact, place the views inside of those bounds. The fix is in two parts: - drawing: avoid the early quickReject() logic for containers that have static transformations set on them (ViewGroup.setStaticTransformationsEnabled()). - invalidation: Include the static transform in the invalidation area propagated up the view hierarchy. Issue #6864203 The child position outside of parent is not drawn even it will be drawn inside of the parent after applying static transformation Change-Id: I73bea01feab250bdcae2d575313be355a4a3c8f5
/frameworks/base/core/java/android/view/ViewGroup.java
|
f443f98e7f41badd8f5d6f7bf7d26432e79a88ed |
|
14-Jul-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Make RelativeLayout aware of layout direction - see bug #5429822 UI should be mirrored for RTL locales (Arabic, Hebrew, farsi) Change-Id: Ica92841fa0c13c25fcf89c4700b0771eec4fd6d7
/frameworks/base/core/java/android/view/ViewGroup.java
|
0f8e402e954c6e37102fa70f81a1d8ec47156338 |
|
03-Jul-2012 |
Chet Haase <chet@google.com> |
Force invalidates on non-visible views. DO NOT MERGE An optimization prunes invalidates on views which are not inside their parent's bounds. This works in most cases, but it is possible to run a situation where a view has been invalidated (and is thus waiting to be redrawn), but the pruning logic ensures that that draw call will not happen. Further, when/if the view comes into the bounds of its parent again, it may still not be redrawn, because now future invalidates on the view are noop'd because it is already in an invalidated state (and thus will not propagate invalidates up the hierarchy). The fix is to remove the optitmization. This will cause some overhead sending the invalidation request up to the view root, but this overhead is minimal (and only extra for cases of out-of-bounds views), and the more expensive part of rendering these views will still not be done since the view root will avoid re-drawing the hierarchy when the dirty rectangle is empty. Issue #6813661 offscreen views don't get invalidated properly (may remain invisible when returning onscreen) Change-Id: Ic4b439540084a7163be9afc585bea6560d073280
/frameworks/base/core/java/android/view/ViewGroup.java
|
15d03bf2a6102c1be9a90da4296155a93da97244 |
|
10-Jul-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix MarginLayoutParams resolution"
|
69bd55844b2b2b78a0ff43e5123954cab3693ea6 |
|
02-Jul-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix MarginLayoutParams resolution - need to keep initial left/right values for correct resolution Change-Id: Ia8d0fec7d3c427086b7b5898e544e369b2de4229
/frameworks/base/core/java/android/view/ViewGroup.java
|
05e91ed5a7ea17f021e1811166942a7d758e1cce |
|
03-Jul-2012 |
Chet Haase <chet@google.com> |
Force invalidates on non-visible views to traverse the hierarchy An optimization prunes invalidates on views which are not inside their parent's bounds. This works in most cases, but it is possible to run a situation where a view has been invalidated (and is thus waiting to be redrawn), but the pruning logic ensures that that draw call will not happen. Further, when/if the view comes into the bounds of its parent again, it may still not be redrawn, because now future invalidates on the view are noop'd because it is already in an invalidated state (and thus will not propagate invalidates up the hierarchy). The fix is to remove the optitmization. This will cause some overhead sending the invalidation request up to the view root, but this overhead is minimal (and only extra for cases of out-of-bounds views), and the more expensive part of rendering these views will still not be done since the view root will avoid re-drawing the hierarchy when the dirty rectangle is empty. Issue #6773607 Layered views animating from offscreen sometimes remain invisible Change-Id: Ia2c1a2b9d3e7f267253cb325ccceff1e7fdbe8bd
/frameworks/base/core/java/android/view/ViewGroup.java
|
27e2da7c171afa39358bbead18fbe3e6b8ea6637 |
|
03-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove the accessibility focus search code. 1. In JellyBean we have added some APIs to search for next accessibility focus in various directions and set accessibility focus from hover. However, we have decided that there is not clean answer for how this should behave and the APIs were hidden. Now the accessibility service is responsible for that. The unused code is now taken out. 2. This patch also takes out the hidden attribute accessibiligyFocusable since we moved the responsibility for implementing focus search strategy to accessibility services and we did not need that for Jellybean which is a good sign that this is not needed. I general this is one less thing for an app developer to worry about. We can add this if needed later. bug:6773816 Change-Id: I0c858d72c93a2b7ff1f8f35a08d33ec4b9eb85fd
/frameworks/base/core/java/android/view/ViewGroup.java
|
ba64974141bb04d35759c7a8f1741d23c172f9a5 |
|
29-Jun-2012 |
Michael Jurka <mikejurka@google.com> |
Removing setChildrenLayersEnabled Change-Id: I88d8228eadb59160648f2c4e131fcd85945f2109
/frameworks/base/core/java/android/view/ViewGroup.java
|
73b21cfa50fbad38a8802289dd9618f7fd383e34 |
|
20-Jun-2012 |
Chet Haase <chet@google.com> |
am 3662fe5e: am ebc9d317: Merge "Handle non-started LayoutTransition animations correctly" into jb-dev * commit '3662fe5e3507ada2a592b8df6120b8cebfb5d8d9': Handle non-started LayoutTransition animations correctly
|
ddbb346e5a08c94dca44d681af53f0d9dc75cadf |
|
19-Jun-2012 |
Chet Haase <chet@google.com> |
Handle non-started LayoutTransition animations correctly A recent change to LayoutTransition noop'd animations in non-visible parents, to avoid artifacts like scaling/moving from (0,0,0,0). But there was logic in ViewGroup that didn't account for transitions that didn't actually run an animation, causing a disconnect between the state of a parent (getting ready to remove an item later) and the state of the transition (not running, therefore not needing the child to be removed later). The fix was to detect when the transition did not start and avoid adding the view to the list of children to be removed later. Issue #6602502 Playing video through crackle application only audio is heard no video is displayed Change-Id: Id5260580ab0d6dd165c62006c7bd579fd821a5f5
/frameworks/base/core/java/android/view/ViewGroup.java
|
bc595b798ea55fefddedb253afb6ac8c7849eff6 |
|
04-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am b59d0618: am b6585d19: Merge "Double input focus and focus movement in list not working." into jb-dev * commit 'b59d06186130921c02b6a4b0c98d0c43379df6d4': Double input focus and focus movement in list not working.
|
b552d89e901225e2b6aa2602e874ab984c638415 |
|
02-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Double input focus and focus movement in list not working. 1. The clearFocus routine in ViewGroup was clearing the pointer to the descendant which has focus after calling clear focus on that child. However, currently clearing the focus of a view causes the view that loses focus to try to give the focus to the first focusable which potentially sets the pointer to the child that has input focus in the ViewGroup but the ViewGruop essentially clears that pointer. This resulted in having two focused views at the same time in some cases. 2. AbsListView was not calling the super implementation of add focusables if the focus type was not accessibility. bug:6559819 Change-Id: I478dfed000b5de3f9b15e12eb82aa3d34c2301e4
/frameworks/base/core/java/android/view/ViewGroup.java
|
0597161ee43cfaa7dbe14691a134fb358a00317a |
|
31-May-2012 |
Philip Milne <pmilne@google.com> |
Merge "Fix for bug 6050753."
|
425f126a0f2284423f4ccea0b00fbd5ea670a6c9 |
|
24-May-2012 |
Romain Guy <romainguy@google.com> |
am a865d7d7: am df3633b3: Merge "Make it harder for apps to mess up ViewGroup\'s internal state Bug #6421288" into jb-dev * commit 'a865d7d7d3612d99e3b1407793610056c7df163c': Make it harder for apps to mess up ViewGroup's internal state Bug #6421288
|
393a52c9f628bbf2ab68508913177650f9183ee4 |
|
23-May-2012 |
Romain Guy <romainguy@google.com> |
Make it harder for apps to mess up ViewGroup's internal state Bug #6421288 Change-Id: I8c2c597f45391d3c1ae40c8341a68bb25d8ad4d9
/frameworks/base/core/java/android/view/ViewGroup.java
|
abafe372ee70496ac6b323e1d05d397785651779 |
|
21-May-2012 |
Romain Guy <romainguy@google.com> |
am 6fa51de8: am 46a8b1ac: Merge "Remove unused, obsolete debug code" into jb-dev * commit '6fa51de80bae65a93346ed18628010a0867607cc': Remove unused, obsolete debug code
|
13b907353f18215b52b5ceda24bbf520d91d72a1 |
|
21-May-2012 |
Romain Guy <romainguy@google.com> |
Remove unused, obsolete debug code All these features have either been abandonned and left un-maintained for years or can be replaced by systrace. Change-Id: I42e4579a8078744047e5fe08a7a15254970b09bc
/frameworks/base/core/java/android/view/ViewGroup.java
|
38f4c223c0fde274c2089b1dad026593c06de06f |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am d83a0800: am 8ce2d78a: Merge "Improving accessibility focus traversal." into jb-dev * commit 'd83a0800679583ccc99a90a128f8d6c11afbeca4': Improving accessibility focus traversal.
|
24ef21aeebb247f5dd6de13aea878f3d7194143a |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am e436812e: am 844047ac: Merge "Fix inconsitency in aAccessibilityNodeInfo cache." into jb-dev * commit 'e436812e85f4a8da724f4fe36c1547a1b806f1f9': Fix inconsitency in aAccessibilityNodeInfo cache.
|
8ce2d78aa89e89e9a5607d8809bf6d248508a531 |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Improving accessibility focus traversal." into jb-dev
|
e5dfa47d84668376b84074c04570fb961870adeb |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility focus traversal. 1. Now the views considered during the accessibility focus search are the ones that would get accessibility focus when thovered over. This way the user will get the same items i.e. feedback if he touch explores the screen and uses focus traversal. This is imperative for a good user experience. 2. Updated which focusables are considered when searching for access focus in ViewGroup. Generally accessibility focus ignores focus before/after descendants. 3. Implemented focus search strategy in AbsListView that will traverse the items of the current list (and the stuff withing one item before moving to the next) before continuing the search if forward and backward accessibility focus direction. 4. View focus search stops at root namespace. This is not the right way to prevent some stuff that is not supposed to get a focus in a container for a specific state. Actually the addFocusables for that container has to be overriden. Further this approach leads to focus getting stuck. The accessibility focus ignores root names space since we want to traverse the entire screen. 5. Fixed an bug in AccessibilityInteractionController which was not starting to search from the root of a virtual node tree. 6. Fixed a couple of bugs in FocusFinder where it was possible to get index out of bounds exception if the focusables list is empty. bug:5932640 Change-Id: Ic3bdd11767a7d40fbb21f35dcd79a4746af784d4
/frameworks/base/core/java/android/view/ViewGroup.java
|
c406be9036643ebe41bafcd94fe4aa861b4e4f4f |
|
12-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix inconsitency in aAccessibilityNodeInfo cache. 1. Fixed errors in the accessibility node cache. A. The cache was not catching the case when the current window changes as a result the user touch exploring it. As a result the cache had nodes from more that one window but the node ids are not unique thus causing a mess. B. The node info tree was prefetched regardless if a prefetched node is root name space (i.e. view ids - not accessibility ids - are namespaced) while the prefetched nodes were taking this into account. As a result there can get disconnected subtrees in the cache. C. When an event for a property change such as focus was received the cache we were removing the source node. As a result there may be disconnected nodes. D. When a node was added to the cache and an older version exists there was no check if it will point to the same children and parent. As a result if the state of the node has fewer children the subtrees rooted at the no longer present children will stay disconnected in the cache. E. When a node got accessibility or input focus the old one in the cache was not removed. As a result you may have a state with more than one access or input focus. 2. Added integrity check enabled only on user builds when a specific flag is set for the cache which checks whether: A. All nodes are from the same window. B. All nodes are connected. C. There are no duplicates. D. There is only one input focus. E. There is only one accessibility focus. 3. The reported accessibility node info tree was stopping at the root namespace boundary which is not correct. The reported tree has to reflect everything on the screen that the user can see such a workspace with widgets. The root namespace is added to avoid clash of view id but the accessibility ids are unique no matter if the view is inflated from a remote view. 4. Added calls to notify the accessibility layer when a preoprty that is interesting for accessibiliy has changed. bug:6471710 Change-Id: I069470d91f209ba16313fa6539787a55efa3512e
/frameworks/base/core/java/android/view/ViewGroup.java
|
50d99215023ee346a95eb72c413759d6a58f82a5 |
|
11-May-2012 |
Dianne Hackborn <hackbod@google.com> |
am de888fec: am 255d1e15: Merge "Fix issue #6475693: OnSystemUiVisibilityChangeListener reporting..." into jb-dev * commit 'de888fec6b7c2f2c9a32a7e9faf38083f67da4d8': Fix issue #6475693: OnSystemUiVisibilityChangeListener reporting...
|
cf67578c7f99492273a8f8446dd18ddc5af2ae76 |
|
11-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6475693: OnSystemUiVisibilityChangeListener reporting... ...incorrect visibility when the ActionBar overflow menu is opened Don't report layout flags in system UI visibility callback. Update docs to reflect this. Change-Id: Icfa411b5537de037cafbcac04991101e8b9138c4
/frameworks/base/core/java/android/view/ViewGroup.java
|
529ddb895e74d226ba957da9b389dbce0f1c3071 |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am ca1e49ca: am cdbbecf3: Merge "Accessibility focus on temporary detached view not cleared." into jb-dev * commit 'ca1e49cad5b5eebdd47039289b604bea6f00e8f7': Accessibility focus on temporary detached view not cleared.
|
3ed259a43cd6532c9cf835c925fc89c2f4f75bc1 |
|
08-May-2012 |
Philip Milne <pmilne@google.com> |
am 2a52d26c: am 7bb66c9c: Hide optical bounds feature for JB. * commit '2a52d26c0b917de8b1e4d20ebad87b9b3825f6ca': Hide optical bounds feature for JB.
|
961bf0e9b4ef94f52ae66856ac573995f1f34578 |
|
08-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus on temporary detached view not cleared. 1. When a view that has accessibility focus is temporary detached we try to draw the focus highlight and crash. Since the detached view will be modified and then either attached or detached from the window we should not keep accessibility focus on a temporary detached view. Otherwise, we may have a scenario where the user thinks he is in one item scroll acound and being in completely different item because of the view being recycled but the user has no clue. 2. Clearing accessibility focus when the view is removed from the parent as opposed as when it is detached from the window. Since we may have transitioning views for removal we do not want accessibility focus on such views during the anumation. bug:6457339 Change-Id: I62287a089ec6850fb1d691ae26dea54e1da39c94
/frameworks/base/core/java/android/view/ViewGroup.java
|
7bb66c9cae7847e3d58f412a73d54ee5d4bcaba0 |
|
07-May-2012 |
Philip Milne <pmilne@google.com> |
Hide optical bounds feature for JB. Change-Id: I1fe38e9c64515acd550baa930ebc0af4c139bf40
/frameworks/base/core/java/android/view/ViewGroup.java
|
66388dcb09018933ccd1d38eae563f0890ba4f06 |
|
04-May-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Hide RTL related APIs - DO NOT MERGE - fix bug #6441155 API review: @hide RTL layout APIs Change-Id: I13c5ea5f579cecffed9d517f06180ab0576cd26a
/frameworks/base/core/java/android/view/ViewGroup.java
|
810a8676df1d504da17bad80c7bd6638bdd97711 |
|
02-May-2012 |
Chet Haase <chet@google.com> |
Corrects invalidation logic for layered views A bug in the invalidation logic meant that changes to a view would not cause parents in the view hiearchy that were set to have a layer (e.g., View.LAYER_TYPE_HARDWARE) to get invalidated properly. So even though the child view was all set to recreate its display list according to the property change, the layer in the tree above it would stay as-is, meaning that the change would not show up on the screen. Issue #5887530 DropTarget text does not change color with the icon Change-Id: Ie6eac4f406d172cb437822d9fe76340ab2afaf1c
/frameworks/base/core/java/android/view/ViewGroup.java
|
d7910dd42a24705172f2794de940f715bbc41410 |
|
29-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing crash in ViewGroup.dispatchPopulateAccessibilityEvent 1. There was a double call to recycle of a pooled instance which was causing an exception. Removed an unnecessary call. bug:6408689 Change-Id: Ic74b743c6be28ca95ab84b15f28edb5bc95f0a88
/frameworks/base/core/java/android/view/ViewGroup.java
|
65340c1682dc73671d59cfbe27ee86549d23ed1d |
|
28-Apr-2012 |
Philip Milne <pmilne@google.com> |
Merge "Fixes for optical bounds feature." into jb-dev
|
7a23b49a8ceb07d3fa12c45fd42cd16131fd746a |
|
25-Apr-2012 |
Philip Milne <pmilne@google.com> |
Fixes for optical bounds feature. 1. Make the feature opt-in (ViewGroup::layoutMode defaults to CLIP_BOUNDS) without inheritance. 2. Rename COMPONENT_BOUNDS to CLIP_BOUNDS. 3. Rename LAYOUT_BOUNDS to OPTICAL_BOUNDS. 4. Complete GridLayout implementation. 5. Change the default_gap between components to 8dp, to align with the Style Guide. Change-Id: I8d40dfc5f4ca469f6424eb3ff60d07bec56e3a9f
/frameworks/base/core/java/android/view/ViewGroup.java
|
cbc6774ef0285956da74193e5d217738e7411830 |
|
28-Apr-2012 |
Romain Guy <romainguy@google.com> |
Make debug.layout usable with hw acceleration on Change-Id: I35e41f83fc5049f5ede6b8a6731800bd6da50391
/frameworks/base/core/java/android/view/ViewGroup.java
|
8f94ec1565339015f3c62b3936b99a16f094c5aa |
|
25-Apr-2012 |
Philip Milne <pmilne@google.com> |
Merge "Fix for layout debug mode."
|
604f440dfd6e5ee857f1e71d12c635d4ee1afcbc |
|
25-Apr-2012 |
Philip Milne <pmilne@google.com> |
Fix for layout debug mode. Change-Id: I0d02aa4cf7e18c2bbb01a3296e573f2f9de60bf1
/frameworks/base/core/java/android/view/ViewGroup.java
|
0430ce908510f501276e7f588ba5c34d33a9d27a |
|
25-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Removing hierarchical accessibility focus directions."
|
b2b15716d8b5b5814e82575a592e76f522f6a4c6 |
|
24-Apr-2012 |
Philip Milne <pmilne@google.com> |
Merge "Promote layout debugging code from GridLayout to ViewGroup."
|
76f287e416ded85734b610f316e38d243d2ddb09 |
|
23-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Removing hierarchical accessibility focus directions. 1. The accessibility focus directions are not needed since an accessibility service just get the root, first child, next sibling, previous sibling and call execute the action to give it accessibility focus. Now the accessibility node info tree is properly ordered taking into account layout manager directions for both layout manager that we report and ones that we have determined as not important for accessibility. Also the position of a node info are ordered properly based on their coordinates after all transformations as opposed to child index. bug:5932640 Change-Id: I994a8297cb1e57c829ecbac73a937c2bcbe0bac7
/frameworks/base/core/java/android/view/ViewGroup.java
|
10ca24a97cefc14fca1b26f59e627f487b3b108b |
|
24-Apr-2012 |
Philip Milne <pmilne@google.com> |
Promote layout debugging code from GridLayout to ViewGroup. Layout debugging code draws rectangles around: 1. Layout insets (red) 2. Bounds (blue) 3. Margins (magenta) Layout debug mode is enabled with: adb shell setprop debug.layout true Change-Id: Ia155a2d0fbf33693a1e3c040f627ea3a534e1aff
/frameworks/base/core/java/android/view/ViewGroup.java
|
1271e2cc80b01d577e9db339459ef0222bb9320d |
|
20-Apr-2012 |
Chet Haase <chet@google.com> |
Remove USE_DISPLAY_LIST_PROPERTIES flag This flag was still hanging around pending any need to disable DisplayList properties. But things seem stable, so it's time to clean up and simplify the code. At the same time, I reduced redundance in DisplayList dimensions. We used to call drawDisplayList() with width/height parameters that were used to do a clip reject. This is redundant with the DisplayList properties that set the bounds of the DisplayList; the left/right and top/bottom properties represent the same width/height properties formerly used in drawDisplayList(). The new approach is to not pass dimensions to drawDisplayList(), but to instead pull those dimensions directly from the DisplayList when needed. Change-Id: I8871beff03b1d4be95f7c6e079c31a71d31e0c56
/frameworks/base/core/java/android/view/ViewGroup.java
|
59a422e90035ce5df45c526607db2d3303e3112e |
|
20-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Ensure that touch and hover targets are cleared when needed. When views are removed from a view or a view is detached from a window, we need to update the touch and hover targets appropriately. Failing to do this resulted in a NPE while dispatching an ACTION_HOVER_EXIT to a view that had previously been removed. Removed views should not get input events. Change-Id: I4af4f8e2c4028347d3f570894fd1b3b366d11455
/frameworks/base/core/java/android/view/ViewGroup.java
|
f01d3dd710e8b86b3e2846af62835158fd4e0db1 |
|
18-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding some more gestures and actions for accessibility."
|
005b83b0c62d3d0538f0d566b08bd457015ec661 |
|
17-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding some more gestures and actions for accessibility. 1. Added more gesture for accessibility. After a meeting with the access-eng team we have decided that the current set of gestures may be smaller than needed considering that we will use four gestures for home, back, recents, and notifications. 2. Adding actions for going back, home, opening the recents, and opening the notifications. 3. Added preliminary mapping from some of the new gestures to the new actions. 4. Fixed a bug in the accessibility interaction controller which was trying to create a handled on the main looper thread which may be null if the queried UI is in the system process. Now the context looper of the root view is used. 5. Fixed a bug of using an incorrect constant. 6. Added a missing locking in a couple of places. 7. Fixed view comparison for accessibilityt since it was not anisymmetric. bug:5932640 bug:5605641 Change-Id: Icc983bf4eafefa42b65920b3782ed8a25518e94f
/frameworks/base/core/java/android/view/ViewGroup.java
|
7dd4a536a125d5e9573e82c39581bf9ee3922424 |
|
16-Apr-2012 |
Chet Haase <chet@google.com> |
Adding new CHANGING transition to LayoutTransition. LayoutTransition used to depend on child views being added/removed or shown/hidden in the transition container. These evens would trigger animations to fade the child view as well as those to animate the side-affected changes to sibling views. This CL enables a new feature in LayoutTransition that enables animating any changes to the layout of the children in the container whenever a layout occurs. For example, you can change the LayoutParams of a child view and call requestLayout() to automatically animate those changes. This capability is not enabled by default. To enable, call the new LayoutTransition.enableTransitionType(LayoutTransition.CHANGING) method. Change-Id: I4d07a3b36245353b2151f0dca4f75080ab6a4592
/frameworks/base/core/java/android/view/ViewGroup.java
|
fcc6a0f145fa721e3feee70bedf8e120fcc4c494 |
|
17-Apr-2012 |
Philip Milne <pmilne@google.com> |
Minor doc fix. Change-Id: I8f20c4751b599e0108c9373caef7e672d1cd4821
/frameworks/base/core/java/android/view/ViewGroup.java
|
a5d552fc2bad6aea2087f56e88fb1ce836a79571 |
|
16-Apr-2012 |
Philip Milne <pmilne@google.com> |
Fix for doc error. Change-Id: I8aa029d96d4cd28354ecc742007e0fc35b05b705
/frameworks/base/core/java/android/view/ViewGroup.java
|
4e1cb3b7942d3ca05918604358b4ef83815ce448 |
|
16-Apr-2012 |
Philip Milne <pmilne@google.com> |
Merge "Fix for bug 6110465."
|
4213804541a8b05cd0587b138a2fd9a3b7fd9350 |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus - framework Usefulness: Keep track of the current user location in the screen when traversing the it. Enabling structural and directional navigation over all elements on the screen. This enables blind users that know the application layout to efficiently locate desired elements as opposed to try touch exploring the region where the the element should be - very tedious. Rationale: There are two ways to implement accessibility focus One is to let accessibility services keep track of it since they have access to the screen content, and another to let the view hierarchy keep track of it. While the first approach would require almost no work on our part it poses several challenges which make it a sub-optimal choice. Having the accessibility focus in the accessibility service would require that service to scrape the window content every time it changes to sync the view tree state and the accessibility focus location. Pretty much the service will have to keep an off screen model of the screen content. This could be quite challenging to get right and would incur performance cost for the multiple IPCs to repeatedly fetch the screen content. Further, keeping virtual accessibility focus (i.e. in the service) would require sync of the input and accessibility focus. This could be challenging to implement right as well. Also, having an unlimited number of accessibility services we cannot guarantee that they will have a proper implementation, if any, to allow users to perform structural navigation of the screen content. Assuming two accessibility services implement structural navigation via accessibility focus, there is not guarantee that they will behave similarly by default, i.e. provide some standard way to navigate the screen content. Also feedback from experienced accessibility researchers, specifically T.V Raman, provides evidence that having virtual accessibility focus creates many issues and it is very hard to get right. Therefore, keeping accessibility focus in the system will avoid keeping an off-screen model in accessibility services, it will always be in sync with the state of the view hierarchy and the input focus. Also this will allow having a default behavior for traversing the screen via this accessibility focus that is consistent in all accessibility services. We provide accessibility services with APIs to override this behavior but all of them will perform screen traversal in a consistent way by default. Behavior: If accessibility is enabled the accessibility focus is the leading one and the input follows it. Putting accessibility focus on a view moves the input focus there. Clearing the accessibility focus of a view, clears the input focus of this view. If accessibility focus is on a view that cannot take input focus, then no other view should have input focus. In accessibility mode we initially give accessibility focus to the topmost view and no view has input focus. This ensures consistent behavior accross all apps. Note that accessibility focus can move hierarchically in the view tree and having it at the root is better than putting it where the input focus would be - at the first input focusable which could be at an arbitrary depth in the view tree. By default not all views are reported for accessibility, only the important ones. A view may be explicitly labeled as important or not for accessibility, or the system determines which one is such - default. Important views for accessibility are all views that are not dumb layout managers used only to arrange their chidren. Since the same content arrangement can be obtained via different combintation of layout managers, such managers cannot be used to reliably determine the application structure. For example, a user should see a list as a list view with several list items and each list item as a text view and a button as opposed to seeing all the layout managers used to arrange the list item's content. By default only important for accessibility views are regared for accessibility purposes. View not regarded for accessibility neither fire accessibility events, nor are reported being on the screen. An accessibility service may request the system to regard all views. If the target SDK of an accessibility services is less than JellyBean, then all views are regarded for accessibility. Note that an accessibility service that requires all view to be ragarded for accessibility may put accessibility focus on any view. Hence, it may implement any navigational paradigm if desired. Especially considering the fact that the system is detecting some standard gestures and delegates their processing to an accessibility service. The default implementation of an accessibility services performs the defualt navigation. bug:5932640 bug:5605641 Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
/frameworks/base/core/java/android/view/ViewGroup.java
|
1557fd7809078e421f751efc7d2539b3efdc54b2 |
|
05-Apr-2012 |
Philip Milne <pmilne@google.com> |
Fix for bug 6110465. Add layout bound metadata to 9-patch files and make layouts take them into account. This CL contains a proposed API for dealing with layout bounds. This solution exposes: 1. Class: Insets - for storing layout Insets (and later possibly padding). 2. Methods: View:(get/set)LayoutInsets() - for storing layoutBounds. 3. Methods: ViewGroup:(get/set)LayoutMode() - for controlling layoutMode. It also iuncudes the changes to GridLayout to support layout bounds. Change-Id: I60c836b6530b61c5abf37f93ee9c44aad73573f1
/frameworks/base/core/java/android/view/ViewGroup.java
|
57cadf2a97a81e5bea49bac573249076ebd95a93 |
|
05-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing broken clear focus behavior. 1. In a prevous patch I fixed the issues when on clearing focus of the first focusable view the callback for gaining focus were called before the ones for losing focus. Since it cause some issues the patch was reverted and resubmitted. In this chaos some code was missed so tests are failing. Added the missing logic to give focus to the first focusable in the current touch mode when a view loses focus. 2. Removed clear focusForRemoval methid since it is a dup of unFocus(); Note: All focus tests now pass. Change-Id: I06881d4b5a66fc5a33efca16a96f20207a7220d3
/frameworks/base/core/java/android/view/ViewGroup.java
|
9da0f8a5c4bccf8e722ae2ebf43873457aec3271 |
|
14-Mar-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add View textAlignment - fix bug #6163772 - use bits field and pack them as much as possible - take care of "supportsRtl" flag from Manifest - add visual unit tests CTS unit tests in another CL Change-Id: Ib77c4eb423854209af130688c5ef9977401a9c1c
/frameworks/base/core/java/android/view/ViewGroup.java
|
3a3a6cfd8ec12208ca75c0d0d871d19d76c34194 |
|
26-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature to let apps layout over status bar / system bar. The main change is a few new flags you can supply to View.setSystemUiVisibility(). One is a new visibility mode, SYSTEM_UI_FLAG_FULLSCREEN, which is basically the same as the global FLAG_FULLSCREEN option for windows, but driven as part of the system UI state. There are also three new flags for telling the framework that you would like to have your application's UI ignore screen decorations -- SYSTEM_UI_FLAG_LAYOUT_NO_NAVIGATION for going behind the navigation bar and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN for ignoring full screen decorations (that is the status bar). In combination with this you can use SYSTEM_UI_FLAG_LAYOUT_STABLE to have the framework report consistent insets to your application. When using NO_NAVIGATION, when the user taps the screen we now also automatically clear ONLY_CONTENT, so that we atomically show both UI elements. This should make it easy for apps like video players that want to move between fully full-screen and regular modes. The ActionBar has also been extended when in overlay mode so that it will adjust the system window insets to also account for its space, and allow it to be hidden using the new SYSTEM_UI_FLAG_FULLSCREEN. Change-Id: Ic8db1adec49a0f420bfe40c1d92eb21307856d0b
/frameworks/base/core/java/android/view/ViewGroup.java
|
b85967b9af76e1e60f7a96603e2567a6449d2e04 |
|
26-Mar-2012 |
Chet Haase <chet@google.com> |
Re-enabling DisplayList properties Several issues came up after DisplayList properties were enabled, so they were disabled pending fixes. Those issues have been fixed, so DisplayList properties are once again being enabled by default. This CL both re-enables these properties (in View.java and DisplayListRenderer.h) and fixes the various issues that enabling them caused the first time around. Related issues (all currently marked as Fixed, though that was simply because DL properties were disabled - this CL provides the real fixes now that DL properties are enabled by default): Issue #6198276 Text input broken Issue #6198472 Native crash at pc 00076428 in many different apps in JRM80 Issue #6204173 Date/time picker isn't rendering all parts of UI Issue #6203941 All Apps overscroll effect is rendered weirdly/has flickering Issue #6200058 CAB rendering issue - not drawing items? Issue #6198578 Front camera shows black screen after taking picture. Issue #6232010 Layers not recreated when children change (DisplayList properties) Change-Id: I8b5f9ec342208ecb20d3e6a60d26cf7c6112ec8b
/frameworks/base/core/java/android/view/ViewGroup.java
|
a998dff5d49a423aaf7097aa8f96bf5bdc681d25 |
|
24-Mar-2012 |
Romain Guy <romainguy@google.com> |
Destroy the hardware renderer when ViewRootImpl's die is post-poned Bug #6109035 ViewRootImpl.die() can be invoked in such a way that doDie() will be executed later. On memory limited device, an eglTerminate() may happen before doDie() is executed which leads to unstable behaviors. This change makes sure the renderer is destroyed as soon as possible. Change-Id: I3322410cdd744b464951e2055aeade6069d1d673
/frameworks/base/core/java/android/view/ViewGroup.java
|
d11e6151fe88314505fa7adca6278de2e772b11c |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Revamp of the NumberPicker widget. 1. The number picker no longer shows up and down arrows, it has only three touch targets which are the currently selected number in the middle with a lesser one above and greater below, now what you touch is what you get, flingability and long press are still supported. 2. Removed the restriction for a View with an AccessibilityNodeProvider to not have any concrete children. If the View has a provider, then this provider is responsible for creating the AccessibilityNodeInfos for all its descendants, concrete and virtual. The number picker is a good example for such a case - it has a concrete input view and two virtual buttons as its children. This is a safe change since this behavior has not been released. 3. This patch also fixes bug where the number picker is stretched too much in the Theme theme. bug:6177794 bug:5728294 Change-Id: I5fb370fe0b864a156f5f2aaf2de5f55f6b6d4e84
/frameworks/base/core/java/android/view/ViewGroup.java
|
9d1992deaeb3d60d5928f05b649a2cc654ba98a3 |
|
13-Mar-2012 |
Chet Haase <chet@google.com> |
Optimizing DisplayList properties DisplayList properties are still disabled default (flags in View.java and DisplayListRenderer.h). When they are enabled, and when a View has a DisplayList, invalidations due to property changes are now optimized to avoid causing DisplayList recreation. This eliminates the drawing step of invalidation (due to changes in these properties), only requiring issuing the previously-created DisplayList to the GL renderer. Invalidation is slightly faster (less overhead as we walk up the hierarchy), getDisplayList() is potentially much faster (going down to ~0ms), depending on the complexity of the View being redrawn and the size of the invalidated hierarchy. Change-Id: I57587d5b810c3595bdd72a6c52349c2a3d1bdf25
/frameworks/base/core/java/android/view/ViewGroup.java
|
a1cff5043d0fbd78fcf9c48e7658e56a5b0c2de3 |
|
21-Feb-2012 |
Chet Haase <chet@google.com> |
Handle view properties at the native level Basic functionality of handling View properties (transforms, left/right/top/bottom, and alpha) at the native DisplayList level. This logic is disabled for now (via compile-time flags in View.java and DisplayListRenderer.h) as we continue work on it (there is no advantage to the new approach until we optimize invalidation and rendering paths to use the new code path). Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
/frameworks/base/core/java/android/view/ViewGroup.java
|
bb9908b828a8cfd5965553be66faa6af89973697 |
|
08-Mar-2012 |
Romain Guy <romainguy@google.com> |
Dispatch screen state change events to Views Bug #6120957 Using this new callback, views can interrupt and resume their animations or other periodic tasks based on the current state of the display. Change-Id: I398f4abd421e9c5f207107bf1009a7b92cf45daa
/frameworks/base/core/java/android/view/ViewGroup.java
|
dd3ef2c573396271c7c3b71e30fbd10cf66d3bc0 |
|
02-Mar-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Improve RTL APIs - follow changed / reset pattern Change-Id: I1c5e9b39196029bd78add2ab13b984da124822ca
/frameworks/base/core/java/android/view/ViewGroup.java
|
98aec1c7efa639ac902d1200a3ac5a4a7a140129 |
|
14-Feb-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Make layoutDirection API public Change-Id: Ie125513e4ea72b33b42355dbc43f9b9b6d46d7eb
/frameworks/base/core/java/android/view/ViewGroup.java
|
8a7259bdc2bd70b7d26998b1c552ab45e69cebb1 |
|
01-Mar-2012 |
Steve Block <steveblock@google.com> |
Prevent a 'TODO' from appearing in the JavaDoc Change-Id: I3fdd46263cea413d519c56f4bd0e9d873f6fbfa6
/frameworks/base/core/java/android/view/ViewGroup.java
|
035a1fcd5ea3ac0080bb74101cf2793ccb9aa689 |
|
28-Feb-2012 |
Adam Powell <adamp@google.com> |
View pressed state dispatching tweaks Bugs 6075823, 6050563 Revise pressed state dispatch logic: Only propagate pressed state to non-clickable views. This should eliminate the "double glow" problem in some list items where a clickable child button has a secondary glow along with a clickable parent. This only applies to setPressed(true) calls; setPressed(false) must propagate. Don't early-out in setPressed to support this use case. Change-Id: Ibbe2309f5030282fad8d23e4a9bc4616b3f5dc7c
/frameworks/base/core/java/android/view/ViewGroup.java
|
c29f031598811486d83f418fd08fbfe1fc41788a |
|
23-Feb-2012 |
Philip Milne <pmilne@google.com> |
Fix for bug 6050753. The method: TypedArray: getLayoutDimension(int, String) throws an undocumented exception when either the width and/or height attributes are undefined. See the bug report above for reasons why this was deemed unhelpful both in the tools area and to developers in general. Fix by: 1. Documenting the conditions under which the method raises an exception. 2. Deprecating the method, advising callers to supply a default instead. Additionally, redefine the: ViewGroup: setBaseAttributes(TypedArray, int, int); methods to provide the appropriate defaults in ViewGroup subclasses as advised above. For the platform layouts the default value is WRAP_CONTENT (and is defined in the ViewGroup.LayoutParams class). The special cases are accomodated in LayoutParams subclasses in the following cases: Subclass width height FrameLayout.LayoutParams: MATCH_PARENT, MATCH_PARENT TableLayout.LayoutParams: MATCH_PARENT, WRAP_CONTENT TableRow.LayoutParams: MATCH_PARENT, WRAP_CONTENT Change-Id: I335a3bd8e2d7f7866692898ed73492635a5b61ea
/frameworks/base/core/java/android/view/ViewGroup.java
|
311a63af40e76925e21dcf273749dcab9d598ddd |
|
23-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add check for no children in VIew hosting virtual view tree. 1. For accessibility purposes View may report a virtual tree rooted at them to convey the logical structure they draw. These are usually custom Views. Such views cannot have children and this patch adds a check for that. bug:6022217 Change-Id: I3795a613b4aef1a7ec5810db8584a11b648870f2
/frameworks/base/core/java/android/view/ViewGroup.java
|
e8585b1721b84798c4e7413939fd085f7a39bc0e |
|
18-Feb-2012 |
Romain Guy <romainguy@google.com> |
Correctly offset the dirty bounds by 0.5px in every direction The existing code was behaving differently for the leaf view and its parents. Change-Id: I14c1ce5cc149ff840ad957408d6a41bbb4137264
/frameworks/base/core/java/android/view/ViewGroup.java
|
539ee8716b4f81260bab2e9f3dc5d88d81c99985 |
|
04-Feb-2012 |
Adam Powell <adamp@google.com> |
Add transient state tracking to Views Transient state is temporary bookkeeping that Views need to perform that the app should not need to be aware of. Examples include text selection regions and animation state. Transient state is a problem for AdapterViews like ListView that do view recycling. Unless the app takes responsibility for tracking and restoring transient state as if it were a part of the adapter's data set, it cannot correctly recycle views. Selections disappear when an EditText is scrolled out of sight and animations seem to play on the wrong views. Views can now flag themselves as having transient state. (As the name implies, this should be a temporary condition.) If a ViewGroup contains a child with transient state, that ViewGroup also has transient state. AbsListView's recycler now tracks views with transient state separately. Views with transient state will be retained, and until a data set change occurs the same view will be reused for that position instead of calling the adapter's getView() method. The API to set and check transient state is currently hidden. Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
/frameworks/base/core/java/android/view/ViewGroup.java
|
6917e6550d2dc11ad3b794be08cc9caa53970d32 |
|
18-Feb-2012 |
Romain Guy <romainguy@google.com> |
Merge "Record possible clip rejects when recording display lists"
|
33f6beb10f98e8ba96250e284876d607055d278d |
|
17-Feb-2012 |
Romain Guy <romainguy@google.com> |
Record possible clip rejects when recording display lists This optimization allows us to quickly skip operations that lie entirely outside of the known bounds of a display list. Because of ViewGroup.setClipChildren, we must keep the operations recorded in the display list. setClipChildren(false) is however a very uncommon operation and we will therefore often benefit from this new optimization. Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
/frameworks/base/core/java/android/view/ViewGroup.java
|
6d3d5057b445069e73fd06adbc11fa412e7c48c3 |
|
16-Feb-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Improve textDirection APIs Change-Id: I8bff30f5adb0ab4077145d83ac4a716e04f289ac
/frameworks/base/core/java/android/view/ViewGroup.java
|
f7280ccbfe6d71686a4e609ee7628f84e514a32d |
|
16-Feb-2012 |
Romain Guy <romainguy@google.com> |
Merge "Add a compile time condition to remove unnecessary code"
|
fe455af277183f910eb74653a3ad172c717e7abf |
|
16-Feb-2012 |
Romain Guy <romainguy@google.com> |
Add a compile time condition to remove unnecessary code Change-Id: Ia44916af8e22e548fbb62cb2b53da285d5959102
/frameworks/base/core/java/android/view/ViewGroup.java
|
54546f22fbec63f8c12e56fa7109706a1bbc4e7b |
|
15-Feb-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Make MarginLayoutParams startMargin and endMargin API public Change-Id: I519f8ede818b068883ee1565d28e188298af9f0e
/frameworks/base/core/java/android/view/ViewGroup.java
|
b36a0ac9709e9e1c7098559c0435cfbdc09e6c46 |
|
15-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus v2.0. The framework tries to have a focused view all the time. For that purpose when a view's focus is cleared the focus is given to the first focusable found from the top. The implementation of this behavior was causing the following issues: 1. If the fist focusable View tries to clear its focus it was getting focus but the onFocusChange callbacks were not properly invoked. Specifically, the onFocusChange for gaining focus was called first and then the same callback for clearing focus. Note that the callback for clearing focus is called when the View is already focused. 2. If not the first focusable View tries to clear focus, the focus is given to another one but the callback for getting focus was called before the one for clearing, so client code may be mislead that there is more than one focused view at a time. 3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup was calling the super implementaion when there is a focused child. Since there could be only one focused View, having a focused child means that the group is not focused and the call to the super implementation is not needed. 4. Added unit tests that verify the correct behavior, i.e. the focus of the first focused view cannot be cleared which means that no focus change callbacks are invoked. The callbacks should be called in expected order. Now the view focus clear precedes the view focus gain callback. However, in between is invoked the global focus change callback with the correct values. We may want to call that one after the View callbacks. If needed we can revisit this. Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
/frameworks/base/core/java/android/view/ViewGroup.java
|
dd29f8c4e3db3338bc055302145c3bc51a27566f |
|
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Merge "Revert "Incorrect behavior of View clear focus.""
|
73eb97f628b298c7bd032aa9db11dadf05f5b539 |
|
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Revert "Incorrect behavior of View clear focus." This reverts commit c6fd88e213703a581fe4680259981f09ae0444f2
/frameworks/base/core/java/android/view/ViewGroup.java
|
bcca79acb1ed31238a80079930bc69f8b9d8cceb |
|
14-Feb-2012 |
Chet Haase <chet@google.com> |
Refactor animation code in new Draw() method into its own method. Ongoing cleanup of View drawing code, continuation of drawChild() refactoring. Change-Id: I6d7383bb858d39ced6917d559defe7713e53de38
/frameworks/base/core/java/android/view/ViewGroup.java
|
4212d3fc736712d6e5fb69d5067ce8d9a83806ef |
|
14-Feb-2012 |
Chet Haase <chet@google.com> |
Merge "Refactor ViewGroup.drawChild() into View.draw()"
|
64a48c1d3daca9e0565f2aa4d56f6e94ea073d9b |
|
14-Feb-2012 |
Chet Haase <chet@google.com> |
Refactor ViewGroup.drawChild() into View.draw() Some of the ongoing and upcoming jank work involves having Views optimize their rendering. For example, it would be more efficient for native display lists to be able to redraw themselves with updated transform/alpha properties than it would be to do it the way we do now, which causes view hierarchy invalidation and display list recreation. In order to do this, we need to push more intelligence for view rendering into the Views themselves, rather than the complicated mechanism we have now of ViewGroup handling some View properties (transforms and alpha) and the Views handling the rest of their rendering. The first step toward this is to take the current drawChild() method and push it into a new, package-private method in View that does the same thing. Future checkins will refactor the code further, simplifying it and eventually optimizing around view property changes. Change-Id: Id44b94536fc3ff80b474db7ef06862f4f51eedce
/frameworks/base/core/java/android/view/ViewGroup.java
|
d7dd89095ff2041f0793317c4ee8e8be49388148 |
|
27-Jan-2012 |
Philip Milne <pmilne@google.com> |
New hooks to allow layouts to improve their performance by doing more caching This change allows layouts to be notified of changes to LayoutParameters that have occurred between layout operations. If an assignment is made to the fields of LayoutParams instances that are already in use, cachced data may become inconsistent with the new values. For complex layouts, like GridLayout, in which the layout parameters define the structure of the layout, caching could have caused ArrayOutOfBoundsException to be raised without this change. This case is rare in normal code as initialisation is typically performed once. Its nevertheless possible and much more likely in environments like design tools where layout parametrs may be being edited on the fly. Prevent errors as follows (belt and braces): 1. Change javadoc to request that changes to the fields of LayoutParams be accompanied with a call to View.setLayoutParams(). (This calls requestLayout() which was what the previous javadoc advised.) Provide a (for now, private) hook for layouts with caches to receive notification of such calls so they can invalidate any relevant internal state. 2. For GridLayout, we cannot clone layout parameters as traditional Java grids do without retaining two complete copies because of the public getLayoutParameters() method on View. Retaining two copies is wasteful on constrainted devices. Instead, we keep just one copy and compute a hashCode for the critical fields of a GridLayout's layoutParams. The hashChode is checked it prior to all layout operations; clearing the cache and logging a warning when changes are detected, so that developers can fix their code to provide the call to setLayoutParams() as above. Change-Id: I819ea65ec0ab82202e2f94fd5cd3ae2723c1a9a0
/frameworks/base/core/java/android/view/ViewGroup.java
|
2eecea3b48ece6f45b30fef9b41dc20075ccc94f |
|
01-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Speedup the accessibility window querying APIs and clean up."
|
12df3cf156885a421beccfa6b6e20fd1a188847a |
|
31-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Incorrect behavior of View clear focus."
|
0d29936ec3b5545a415e8d032150ea987aab36e3 |
|
26-Jan-2012 |
Chet Haase <chet@google.com> |
Fix bug in LayoutTransition for INVISIBLE views When a view is becoming VISIBLE or INVISIBLE in a container with a LayoutTransition, animations run to fade the view in and out and also to run 'changing' animations on the view's other siblings. This logic also cancels any running 'changin' animations to account for new ones running. However, in the specific case of INVISIBLE changes, there will be no layout changes in the container - layout has already accounted for that view (unlike in the case of GONE views); the visibility is just a matter of drawing the view (or not). Therefore, we're canceling 'changing' animations that should continue running and not replacing them with any other animations, since new animations would only be started on layout chnages which are not forthcoming. One artifact seen from this bug is that the navigation bar buttons sometimes disappear when changing orientation. This is because the menu button may toggle between VISIBLE and INVISIBLE, causing animations on the other buttons to get canceled, which leaves those views in a completely wrong state. The right thing to do is to avoid canceling in-process 'changing' animations and to skip the logic of setting up new 'changing' animations which won't fire anyway. There is some minor API work in here because we did not previously have the necessary information in LayoutTransition to know whether a view was being hidden or shown to/from the INVISIBLE state. Issue #5911213: LayoutTransitions ending in an odd state Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
/frameworks/base/core/java/android/view/ViewGroup.java
|
53f2d55740c50507797475a2f7186421c0ada2d1 |
|
19-Dec-2011 |
Chet Haase <chet@google.com> |
Fix old issue with compatibility-scaled apps and Animations Previously, we'd pass in a scale factor (based on whether the app was being scaled by the compatibility mode) to Animation.getTransformation(). This scales the pivot point of the animation based on thes cale factor. However, the pivot points were already using information that took the compatibility mode scale into account. For example, using ABSOLUTE and basing pixel values on the width/height of the view would give you values relative to the width/height of the view (pre-scaled). Using RELATIVE_TO_* would use percentages for the pivot point, again taking the scaling of the view into account. So scaling the pivot point added in another scale on top of that already being applied. The net effect was to scale the pivot point in cases where it should not be scale. For example, setting a pivot point to half-way (.5 and RELATVE_TO_SELF) would end up with an animation that would pivot around the bottom/right of the view. The fix is to simply remove the scale factor being passed in; we've already accounted for it in the pivot point, so we shouldn't concatenate it into the transform calculated by the animation. Change-Id: I9daa7581b1b9d0dfb10515e96947160c28c5130e
/frameworks/base/core/java/android/view/ViewGroup.java
|
c6fd88e213703a581fe4680259981f09ae0444f2 |
|
26-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus. The framework tries to have a focused view all the time. For that purpose when a view's focus is cleared the focus is given to the first focusable found from the top. The implementation of this behavior was causing the following issues: 1. If the fist focusable View tries to clear its focus it was getting focus but the onFocusChange callbacks were not properly invoked. Specifically, the onFocusChange for gaining focus was called first and then the same callback for clearing focus. Note that the callback for clearing focus is called when the View is already focused. Also note that at the end the View did not clear its focus, hence no focus change callbacks should be invoked. 2. If not the first focusable View tries to clear focus, the focus is given to another one but the callback for getting focus was called before the one for clearing, so client code may be mislead that there is more than one focused view at a time. 3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup was calling the super implementaion when there is a focused child. Since there could be only one focused View, having a focused child means that the group is not focused and the call to the super implementation is not needed. 4. Added unit tests that verify the correct behavior, i.e. the focus of the first focused view cannot be cleared which means that no focus change callbacks are invoked. The callbacks should be called in expected order. Now the view focus clear precedes the view focus gain callback. However, in between is invoked the global focus change callback with the correct values. We may want to call that one after the View callbacks. If needed we can revisit this. Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
/frameworks/base/core/java/android/view/ViewGroup.java
|
79311c4af8b54d3cd47ab37a120c648bfc990511 |
|
18-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Speedup the accessibility window querying APIs and clean up. 1. Now when an interrogating client requires an AccessibilibtyNodeInfo we aggressively prefetch all the predecessors of that node and its descendants. The number of fetched nodes in one call is limited to keep the APIs responsive. The prefetched nodes infos are cached in the client process. The node info cache is invalidated partially or completely based on the fired accessibility events. For example, TYPE_WINDOW_STATE_CHANGED event clears the cache while TYPE_VIEW_FOCUSED removed the focused node from the cache, etc. Note that the cache is only for the currently active window. The ViewRootImple also keeps track of only the ids of the node infos it has sent to each querying process to avoid duplicating work. Usually only one process will query the screen content but we support the general case. Also all the caches are automatically invalidated so not additional bookkeeping is required. This simple strategy leads to 10X improving the speed of the querying APIs. 2. The Monkey and UI test automation framework were registering a raw event listener for accessibility events and hence perform connection and cache management in similar way to an AccessibilityService. This is fragile and requires the implementer to know internal framework stuff. Now the functionality required by the Monkey and the UI automation is encapsulated in a new UiTestAutomationBridge class. To enable this was requited some refactoring of AccessibilityService. 3. Removed the *doSomethiong*InActiveWindow methods from the AccessibilityInteractionClient and the AccessibilityInteractionConnection. The function of these methods is implemented by the not *InActiveWindow version while passing appropriate constants. 4. Updated the internal window Querying tests to use the new UiTestAutomationBridge. 5. If the ViewRootImple was not initialized the querying APIs of the IAccessibilityInteractionConnection implementation were returning immediately without calling the callback with null. This was causing the client side to wait until it times out. Now the client is notified as soon as the call fails. 6. Added a check to guarantee that Views with AccessibilityNodeProvider do not have children. bug:5879530 Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
/frameworks/base/core/java/android/view/ViewGroup.java
|
8a78fd4d9572dff95432fcc4ba0e87563415b728 |
|
17-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityEvent/AccessibilityNodeInfo class name property should be set to only framework classes. AccessibilityEvent and AccessibilityNodeInfo have a property className which is set to the source Java class. This is problematic since leads to leaking private classes which would allow an accessibility service to load classes from other packages. This is strongly undesirable since not trusted code can be loaded, and hence executed, in the accessibility service. To address that the class name is set to the most concrete framework class extended by the info/event source. bug:5878943 Change-Id: I7b3114ece8772ea2773f5151e21b8a6f2006882a
/frameworks/base/core/java/android/view/ViewGroup.java
|
2d46fcc669ff5efe365e9be435ab9e5c5a304939 |
|
20-Dec-2011 |
Chet Haase <chet@google.com> |
Minor small fixes to old Animation code and docs. Change-Id: Ib8a1ba2d12e26cc42a2cec48312a5229bb6d4e8a
/frameworks/base/core/java/android/view/ViewGroup.java
|
f8c2abcadd5d7fbac64f84e6b31ec45102bcf3dd |
|
13-Dec-2011 |
Adam Powell <adamp@google.com> |
am bffe0be3: am 9c92fcd9: Merge "Bug 5727679 - CTS test ViewGroupTest#testGetChildVisibleRect" into ics-mr1 * commit 'bffe0be3af2bd19a392e7d332cbfda9a60b8e057': Bug 5727679 - CTS test ViewGroupTest#testGetChildVisibleRect
|
f93bb6d8fd81d8938b16cf40259f97c336e9ef3a |
|
13-Dec-2011 |
Adam Powell <adamp@google.com> |
Bug 5727679 - CTS test ViewGroupTest#testGetChildVisibleRect Preserve the ability to call getChildVisibleRect without the view being attached to a window. Change-Id: I702b19fa1625c346eb22fda4a4ffb6e8f790b689
/frameworks/base/core/java/android/view/ViewGroup.java
|
9650b018e3b1ed42de9b48f3c0eaf4e04733f065 |
|
08-Dec-2011 |
Dave Burke <daveburke@google.com> |
am e118c1de: am ef8913c0: Merge "Remove dangerous and useless optimization Bug #5525888" into ics-mr1 * commit 'e118c1de0037e6732b66b9f52903567caa961c31': Remove dangerous and useless optimization Bug #5525888
|
c7ee3cab56b8cc90c4f6659a262a1cba5c71e92a |
|
08-Dec-2011 |
Romain Guy <romainguy@google.com> |
Remove dangerous and useless optimization Bug #5525888 Change-Id: I553828c0da09b15d0dce3727e4c26a9d0bcf72ea
/frameworks/base/core/java/android/view/ViewGroup.java
|
9c4b79af221b53f602f946faa9ff317a596a0c39 |
|
11-Nov-2011 |
Romain Guy <romainguy@google.com> |
Discard framebuffer rendering queues when discarding layers Bug #5581817 Change-Id: Ie30700a29059d2ea60eb7bd3f8bd20ac48a149ab
/frameworks/base/core/java/android/view/ViewGroup.java
|
f240ac99d6bc3a9c77c00fab0ff102f9da504fd5 |
|
03-Dec-2011 |
Gilles Debunne <debunne@google.com> |
am 0c7e894e: am 2f1e1e4a: Merge "Handle animations in Views\' rectangle clipping methods." into ics-mr1 * commit '0c7e894e79bea35f979d30e4e3bb6115b102cafd': Handle animations in Views' rectangle clipping methods.
|
cea45132e3d5d32a6fc737abf10b8893a50f465b |
|
24-Nov-2011 |
Gilles Debunne <debunne@google.com> |
Handle animations in Views' rectangle clipping methods. getChildVisibleRect and getLocationInWindow do not take the new mTransformationInfo View attribute. As a result, these methods return invalid value during an animation Bug 5638710 Changes in Patch Set 2: - temporary allocations removed using static thread local variables (method calls are NOT reentrant). - scroll should be handled *before* applying the transformation matrix. Fixed the call order in View#getLocationInWindow() Patch set 4: fix from comments. Patch set 5: <p>s Change-Id: I15dc44c0659305d9029c59a47aba3a738bb35ae1
/frameworks/base/core/java/android/view/ViewGroup.java
|
8c39defde61d5c8cd0956a44a193c283af350d88 |
|
29-Nov-2011 |
Chet Haase <chet@google.com> |
Fix invalidation of transformed, opaque views There is an optimization in the invalidation logic which notes when opaque views are invalidated and avoids drawing any of the content behind those views. This runs afoul of some invalidation logic that invalidates previous positions of views prior to transforming them. The opaque-dirty optimization guarantees that the background behind the old positions of these views will not be painted, causing the views to leave behind artifacts from their previous positions. The fix is to disable the optimization when the view in question is transformed (has a non-identity matrix). Issue #5678545: Invalidation logic broken for software-rendered opaque/transformed views Change-Id: Ia365ab97725bf36e08797bf319945a52ffca4616
/frameworks/base/core/java/android/view/ViewGroup.java
|
7077506f9945b87b02bdd47ffce75a5b813c821c |
|
14-Nov-2011 |
Dave Burke <daveburke@google.com> |
Revert "Discard framebuffer rendering queues when discarding layers" This reverts commit da96f8ac2c1c35a54f3f36e6d776cb386a251d03.
/frameworks/base/core/java/android/view/ViewGroup.java
|
da96f8ac2c1c35a54f3f36e6d776cb386a251d03 |
|
11-Nov-2011 |
Romain Guy <romainguy@google.com> |
Discard framebuffer rendering queues when discarding layers Bug #5581817 Change-Id: If612846ec5f7793710fc4df152791fb32c506551
/frameworks/base/core/java/android/view/ViewGroup.java
|
6e42470f928bbf60c9fd3d17a2a69a4b96cec170 |
|
02-Nov-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Accessibility window query APIs should respect root name space." into ics-mr1
|
0500b3cfda5192efc09d6d4344b0c6c785c0a815 |
|
01-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Some optimizations. - Don't try to create a thumbnail bitmap on the client side. This wastes 64k, and isn't needed since we are doing screenshots. - Optimize View to put all of the callback pointers out of line. Added a couple new APIs so these don't need to be protected/public. - Lazily create ViewGroup's cache paint. - Change FrameworkPerf app to not use HW accel drawing, to give better comparison with GB. Change-Id: Iec56d02459820d74a4cc9c7ec9c1856563c82c7b
/frameworks/base/core/java/android/view/ViewGroup.java
|
57f3b566db630233087b121d3d43ecd81a6dfd95 |
|
01-Nov-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility window query APIs should respect root name space. 1. The window query API used to not-respect the root name space while traversing the parent relation i.e. a client was able to fetch the parent of a root name space node. 2. Children that are root name space were reported but their descendants not. Actually such children should not be reported since they are the root of a separate logical sub-tree. Such a tree is exposed by its root allowing its traversal. The accessibility APIs should be able to explore a virtual tree, i.e. one with a descendant which is root name space, only if an accessibility event from there was received. bug:5480096 Change-Id: I4c4d805aa2f6d4edba86eda213b5239bea83eed2
/frameworks/base/core/java/android/view/ViewGroup.java
|
558459fe85f56f29a6ed6a4d0adb4a0bd6665884 |
|
14-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross-references, Project ACRE, Round 2 Change-Id: I39a534ae3a2a34b4dabc333a09961012ef911d3e
/frameworks/base/core/java/android/view/ViewGroup.java
|
9a230e01a1237749a8a19a5de8d46531b0c8ca6a |
|
06-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately This cleans up how ui flags are managed between the client and window manager. It still reports the global UI mode state to the callback, but we now only clear certain flags when the system goes out of a state (currently this just means the hide nav bar mode), and don't corrupt other flags in the application when the global state changes. Also introduces a sequence number between the app and window manager, to avoid using bad old data coming from the app during these transitions. Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
/frameworks/base/core/java/android/view/ViewGroup.java
|
2cdedffcfa5594f9d516fa235d5edf4d4f92c21d |
|
03-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility services cannot obtain the source of an event coming from a root namespace descendant. 1. The user can touch the screen at an arbitrary location potentially crossing the root namespace bounday which will send an accessibility event to accessibility services and they should be able to obtain the event source. Also accessibility ids are guaranteed to be unique in the window. Added a package scoped findViewByAccessibilityId method that dives into nested root namespaces. 2. Added accessibility support to the AnalogClock. bug:5405934 Change-Id: I84edcb554bae41aafcbbc2723c5e62c1ef8a6ddf
/frameworks/base/core/java/android/view/ViewGroup.java
|
59c7f80dd20258cefa1fc4bdd3c9a709a8dd53b8 |
|
30-Sep-2011 |
Romain Guy <romainguy@google.com> |
TextureView works best when it draws stuff. Bug #5391188 Change-Id: I5e754881ccb08ff288ebd60de77282c9cbcf3f86
/frameworks/base/core/java/android/view/ViewGroup.java
|
2fcbbd0363633765e1ab5b9890ccb807002370e8 |
|
29-Sep-2011 |
Adam Powell <adamp@google.com> |
Fully qualify javadoc links and make the tools happy Change-Id: I2ad839be71b550a2bcfb90f67627afdd10d3ae14
/frameworks/base/core/java/android/view/ViewGroup.java
|
2a9fa89643ce796ee6dc7edae2742b291b6c5f40 |
|
29-Sep-2011 |
Romain Guy <romainguy@google.com> |
Don't build display lists for views with a layer. This could cause the draw() code of views to be invoked too often or worse, called with the wrong canvas. For instance, a view backed by a software layer could get its draw() method called to record a display list. Using a software layer is the recommended way to use drawing operations not supported in hardware. Since we would sometimes call the draw() method with the hardware backend anyway, the app could crash by executing an unsupported operation. Change-Id: Ib5f9a3a4c6f3efff5e0162ecd73d2dffe06e30a6
/frameworks/base/core/java/android/view/ViewGroup.java
|
6e6db61809a9cf31f110fb53be09b43cfb9f14de |
|
26-Sep-2011 |
Chet Haase <chet@google.com> |
Fix display list issue that was crashing an external app. The app was removing a View whilst in its onDraw() method. This meant that we asked it for its display list and it invalidated that display list (by removing itself) before it returned from onDraw(). We later attempted to draw that invalid display list into its parent nad died in native code. The fix is to check the state of the display list after the call to getDisplayList() and to avoid doing further work with it if it's invalid. Change-Id: I14a342b4fe79c8dce2626ff61237b447040e7f42
/frameworks/base/core/java/android/view/ViewGroup.java
|
b84b94e1a04cd1f396dd6fef98d65ca1a2729c92 |
|
23-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Scroll accessibility events should not populate text. Scroll events are used to report position change and should not contain the text content of the view that fires them because it is usiually a containter for many other views and the text will be long and not informative for accessibility purposes. Also such evens are fired relatively frequently. If a client wants to fetch some textual content for a scroll event he can use the interrogation APIs. bug:5352059 Change-Id: I43e02aca895c8ab16ba82ebe1cee3aea8ce7711a
/frameworks/base/core/java/android/view/ViewGroup.java
|
4b86788003b3ddc968d0681d5ed4e5da07e4a65a |
|
16-Sep-2011 |
Adam Powell <adamp@google.com> |
Bug 5244365 - Prevent views from receiving multiple onAttachedToWindow calls. If a View is added to a ViewGroup during the ViewGroup's onAttachedToWindow method, the child can receive two calls to onAttachedToWindow. Guard against this. Change-Id: I845d0cb2c9172071eee1eadc6bc2dd282ee0ef43
/frameworks/base/core/java/android/view/ViewGroup.java
|
ea515aeafa01de6f50c854ee381b972ef2478284 |
|
15-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Update the public APIs for finding views by text to optionally use content description. 1. Added flags to the search method to specify whether to match text or content description or both. 2. Added test case for the seach by content description. 3. Updated the code in AccessibilityManager service to reflect the latest changes there so test automation service works - this is the fake service used for UI automation. Change-Id: I14a6779a920ff0430e78947ea5aaf876c2e66076
/frameworks/base/core/java/android/view/ViewGroup.java
|
031d9c1389de2b9dac7f175af0b962e24b21d5be |
|
10-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding accessibility delegate mechanism for backwards compatibility support. 1. Added an AccessibilityDelegate class in View which can be set by a client that wants to cutomize accessibility behavior via composition as opposed to inheritance. Insead overriding a new method in View thus being bound to the API version that introduced this method a developer can conditionally inject the accessibility customization if the platform API version is heigh enough. The developer will have to override the method of interest of the delegate. The default implementation of the delegate methods is the same as that of View in the case that there is no delegate set. If a delegate is set calling an accessibility related method on View will be handed off to the corresponsing method of the delegate. bug:5259555 Change-Id: I00e750e22e5e7164a1b571cb3d12ecaf4ab93db4
/frameworks/base/core/java/android/view/ViewGroup.java
|
aceafe63eeb7d3bfc05ef5ab0b3957572d61ecf5 |
|
27-Aug-2011 |
Chet Haase <chet@google.com> |
Fixed error in invalidation/LayoutTransition logic A recent fix for invalidation noop'd calls to invalidate() on GONE/INVISIBLE views. This logic also noop'd views which might be GONE, but which are in the process of fading in/out via LayoutTransition animations. These views should invalidate as usual. Change-Id: Ie90a340f70290391a3aa4e68df535c6aabf4e5eb
/frameworks/base/core/java/android/view/ViewGroup.java
|
530b22ab4e9076926e13502b443e3ce3879b45ae |
|
23-Aug-2011 |
Chet Haase <chet@google.com> |
Fix invalidation roundoff error with old animations We need to add .5 to the width/height of invalidation areas to avoid truncation errors. Change-Id: Iaa2407a91a6a7f6d729af21d45e77e436197df11
/frameworks/base/core/java/android/view/ViewGroup.java
|
1abf7fa1d1930e24739cae9874970420101bc2f9 |
|
18-Aug-2011 |
Chet Haase <chet@google.com> |
Fix potential null deref in ViewGroup when running transition Change-Id: I9075c4a05e19122592145468e220afa43faee540
/frameworks/base/core/java/android/view/ViewGroup.java
|
4dfbec2665bd5f567d7321f2e88a39e1ab45fdf8 |
|
15-Aug-2011 |
Jeff Brown <jeffbrown@google.com> |
Find next focus id from inside-out. Bug: 5165543 This change fixes some problems when the view hierarchy contains duplicate ids, such as when ListViews contain nested custom views. If the custom views contain next focused id hints, then the system should prefer the other views within the ListView item over any other views outside of the ListView item. Change-Id: I5653ff6bac0bf9f08bd6ecbe5a3bb22ea47ab566
/frameworks/base/core/java/android/view/ViewGroup.java
|
ea83503e8683531fac2534047e50bc1e5979b6dd |
|
29-Jul-2011 |
Romain Guy <romainguy@google.com> |
Don't create hw layers when there's no hw context. Bug #5093805 Change-Id: Ia58b3381c83b9a200e80020e5c1b9c337ad6c35c
/frameworks/base/core/java/android/view/ViewGroup.java
|
93b2182a2e1a42ef60d3c0fa79fbdc4b27875685 |
|
28-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
AccessibilityNodeInfo reports no children for the topmost view in the tree. 1. My previous change to restrain AccessibilityNodeInfo to report children if it is root namespace did not take into account that the tompost view i.e. the decor view actually is a root namespace. Adding check to allow the info to report children of rthe topmost view but do not do so if a descendant is flagged as root namespace. bug:5086988 Change-Id: Ib82b8ebe5a2c287ab1c5333d130ec50eb9ced78c
/frameworks/base/core/java/android/view/ViewGroup.java
|
effe10fd67645bcaeb987dfefa154c284771064e |
|
27-Jul-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
findViewWithText inconsistent with other findView* methods and AccessibilityNodeInfo not respecting root namespace. 1. Find viewsWithText does not respect if the current view group is a root name space and keeps its traversal. This is inconsistent with the other findView* methods. Also only visible views are returned witch is inconsistent with the other findView* methods. 2. AccessibilityNodeInfo reports children it the source is root namespace. This is not correct since thi flag denotes the beginning of a logically separate view hierarchy. bug:5082601 Change-Id: I9c7ca51f284d04728828d5e656112257c9a2c6e2
/frameworks/base/core/java/android/view/ViewGroup.java
|
29d23ecfd8612ecd4a7b2140acd344934b73a558 |
|
25-Jul-2011 |
Romain Guy <romainguy@google.com> |
Add debug flag to print out the EGL configuration used by libhwui Change-Id: I8be5aebb60b7441342d430131168d11dc551ec34
/frameworks/base/core/java/android/view/ViewGroup.java
|
5bae58dff90025dd1419bd7508d17bbd32c26beb |
|
23-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Nested alpha animations should cause invalidates too Bug #5041061"
|
d4745a689f36211afaff396874d78b1d5202762d |
|
23-Jul-2011 |
Romain Guy <romainguy@google.com> |
Nested alpha animations should cause invalidates too Bug #5041061 Change-Id: I96835449b6b5537872afda90956c5d06d826e841
/frameworks/base/core/java/android/view/ViewGroup.java
|
6179ea3196e9306d3f14361fe9ef14191b1edba6 |
|
28-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding accessibility support to the Status Bar. 1. Added content description to pretty much all animals in the zoo including buttons in the navigation bar, notifications and status icons for battery, signal, data, etc. 2. Rectored to avoid ovelaying views since they block touch exploratino. In general overlaying views cause trouble for touch exploration and accessibility in general. 3. Avoid sending accessibility events in case the user is touching outside of the StatauBAr panels to avoid confusion. 4. Added records to accessibility events in the places where this would help the presentation. So the event comes from a given "leaf" view and its predecessor is adding a record to the event for itself to provide more cotext. It is up to the accessiiblity service to choose how to present that. bug:4686943 Change-Id: I1c1bd123d828fb10911bca92130e9a05c1f020b3
/frameworks/base/core/java/android/view/ViewGroup.java
|
350f0a63c9e785304063a95a6df9e128a67ec64f |
|
19-Jul-2011 |
Philip Milne <pmilne@google.com> |
Expose to the platform the ability to pick up changes in child visibility. Also: . use above, to flsuh GridLayout state when child's GONE state changes. Change-Id: I8567c24b51b807f0625918d42b6847a5a350311d
/frameworks/base/core/java/android/view/ViewGroup.java
|
db94b0a5b071bafd5ae8cb9735528aa9d4b31cc8 |
|
19-Jul-2011 |
Chet Haase <chet@google.com> |
Merge "Don't constrain invalidation rect when not clipping children"
|
a3db866056adb01820bbd6389d20fc550be87eb3 |
|
19-Jul-2011 |
Chet Haase <chet@google.com> |
Don't constrain invalidation rect when not clipping children View.setClipChidlren(false) allows children to draw outside of their containers. But logic in ViewGroup.invalidateChildInParent() constrains the invalidation rectangle to the bounds of the parent, making the flag useless in some situations. Avoid intersecting the dirty rect with the parent bounds when the parent is set to not clip its children. Change-Id: Icc485b539758c96da0bd62ef57974a1bcb94f866
/frameworks/base/core/java/android/view/ViewGroup.java
|
2e29de7cab35e4cf7c8f177b546cc95b101ed5c8 |
|
19-Jul-2011 |
Philip Milne <pmilne@google.com> |
Merge "Gather View's hierarchy notifications into methods that can easily be overidden."
|
f51d91c3ab232154b6c00d7f71377ff2421f79bf |
|
19-Jul-2011 |
Philip Milne <pmilne@google.com> |
Gather View's hierarchy notifications into methods that can easily be overidden. Also: . Remove backward compatibility Group class now that AppsCustomizePagedView has been updated. Change-Id: Ie3eabbdf57a539b28cdc3fd6d48cd984a4014960
/frameworks/base/core/java/android/view/ViewGroup.java
|
6dd005b48138708762bfade0081d031a2a4a3822 |
|
18-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
I. Can. Not. Stand. ViewAncestor. It was done so we would have the name "ViewRoot" available for a public API. However, the name "ViewAncestor" just makes no sense. So instead, change it to ViewRootImpl. Change-Id: If9599ca67896f339f6fefa7d1dde121201171d97
/frameworks/base/core/java/android/view/ViewGroup.java
|
cb379120456d8065d742021fc5c66748fc8a11a8 |
|
07-Jul-2011 |
Doug Felt <dougfelt@google.com> |
Implement textDirection heuristic selection. Change-Id: I2fcf18de573f2d66494fa5ed61e4273c3c6078c7
/frameworks/base/core/java/android/view/ViewGroup.java
|
7f86c806ada21fc7a3feefd89d6fcb4282b0af40 |
|
02-Jul-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix View reset of layoutDirection and textDirection - do it in onDetachedFromWindow() - make naming consistent too - update unit tests Change-Id: I320fcdbf75166bae793c4409e7344608b696667f
/frameworks/base/core/java/android/view/ViewGroup.java
|
b2479153b743df9e54f7e17c7132a5ecd87fa453 |
|
08-Jul-2011 |
Romain Guy <romainguy@google.com> |
Correctly position layers. Change-Id: I1678b1c5bdab140b44e56556c50ab8329255f18a
/frameworks/base/core/java/android/view/ViewGroup.java
|
f03712bf540db15d0594b848e63c207fd50e9379 |
|
02-Jul-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix default TextView textDirection heuristic"
|
0b28c757adfec4302b144d8230c01c04ae00ca2b |
|
01-Jul-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix default TextView textDirection heuristic - use "first strong" instead of "locale" - optimize "any rtl" heuristic too - fix a few wording issues too Change-Id: I239a11a49a7a6a6d45165f593c96e8b6b84f0661
/frameworks/base/core/java/android/view/ViewGroup.java
|
0e591ab277e777b0422463823e3abf28bb1fd5d8 |
|
01-Jul-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Add charCount heuristic to TextView textDirection"
|
8f5026562f26dcde43ee9d9182b309c3204dc1ad |
|
30-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add charCount heuristic to TextView textDirection - threshold set to 60% (using a constant) - fix also one issue during layout direction resolution (parent could be null so delay resolution up to when parent is no more null) Change-Id: I65f24a297aac6bc0d5d482ee31b55db0b201e5bf
/frameworks/base/core/java/android/view/ViewGroup.java
|
fe8b06cfb4cb4991bcfd09ffa60dcbb7b48ee45f |
|
30-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Support control of text alignment."
|
8ef7358fb3039765b98df170fea4307935145305 |
|
30-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Synthetic cancel event should have touchscreen source."
|
2fdbc5a0c499752285630336f0ef538d4a50e60e |
|
30-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Synthetic cancel event should have touchscreen source. Fixed a warning identified by the InputEventConsistencyVerifier due to some code that synthesizes a touch event which it sends to onTouchEvent with no input device source specified. This is generally harmless but a fake source is better than none in this case. Change-Id: I44cfa36a4746f598f8fde3086084af3896e2ba2a
/frameworks/base/core/java/android/view/ViewGroup.java
|
c0ccf0c47c00942a9d0f2670600a8f2d4d7adb5b |
|
24-Jun-2011 |
Doug Felt <dougfelt@google.com> |
Support control of text alignment. Change-Id: Id6f3682f67ba2e6811e3014cd34a281e6dd0a469
/frameworks/base/core/java/android/view/ViewGroup.java
|
222688682e6e072076489d8203d01bdf2366101a |
|
28-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Add textDirection support for TextView and ViewGroup - use ViewGroup inheritance if defined - use different heuristics (inherit, firstStrong, anyRtl, ltr, rtl) - add more unit tests Change-Id: Ic1325aa7d9e4689b181e0a2d08b7dd7fb3f0dbeb
/frameworks/base/core/java/android/view/ViewGroup.java
|
b76023afd192a1f5c81a8965cfd1b9dde2558726 |
|
21-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Introduce MarginLayoutParams marginStart and margingEnd - update BiDiTest app for adding more unit tests concerning margin Change-Id: Ia6a7e0a1948a2c375e8f3cc87d120a85351a8c27
/frameworks/base/core/java/android/view/ViewGroup.java
|
a54a600bc41c8ac760f85333b0c562cdc6770531 |
|
24-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #4813026 resolved direction of view doesn't change after layout direction changes"
|
a9489274d67b540804aafb587a226f7c2ae4464d |
|
23-Jun-2011 |
Romain Guy <romainguy@google.com> |
Add the ability to specify the opacity of a TextureView TextureView assumes its content is opaque by default. Change-Id: Iba873423566a5b67c388081838bd910dceba32ba
/frameworks/base/core/java/android/view/ViewGroup.java
|
80dc53d652b060d4dea7d70e9a5aa3b8321bcf8d |
|
22-Jun-2011 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #4813026 resolved direction of view doesn't change after layout direction changes - reset resolution if setLayoutDirection() is called - propagate resolution reset to the children if the View is a ViewGroup and direction is inherited Change-Id: Iab1a75b17426aead7e28caba827614d7cf8e9450
/frameworks/base/core/java/android/view/ViewGroup.java
|
87b7f805b94f5df53343264509f6d606d96dfb05 |
|
22-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Send hover to all children under pointer. Previously we only sent hover to the topmost child, but this doesn't handle cases where multiple children are overlapped to achieve certain special effects. Now we send hover to all children until one of them handles it. Also moved the call to send the accessibility event into the main dispatch function so that we can send the accessibility event for all innermost hovered views even when setHovered() might not be called. Change-Id: I6fb8b974db44b594c441deafc012b8415afdfac7
/frameworks/base/core/java/android/view/ViewGroup.java
|
10b6290c5f15ae512a2f6b5bf8d95bd2527c7235 |
|
21-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Only handle onHoverEvent in actionable views. Modified onHoverEvent so that a view only has its state changed to hovered when the view is clickable. The intent is to prevent labels from taking hover focus away from their containing view group despite not being actionable in any way. The child will still receive a hover event but, if it does not handle the event (returns false), the hover event will bubble up to its parent and ancestors allowing them a chance to handle the event instead. The new onHoverEvent semantics are better because now they closely mirror those of onTouchEvent. This makes it straightforward to implement views that respond to hover by changing their visual appearance (such as by making buttons glow when hovered). Added onInterceptHoverEvent to enable ViewGroups to explicitly intercept hover events within their bounds. Exposed the new hover event API for real. Change-Id: I63195c8f5c74b859f6047487f9a0f703e8f40ffe
/frameworks/base/core/java/android/view/ViewGroup.java
|
ea1da3d2e61625afcc7753ba2e03c5d2fb565dae |
|
16-Jun-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Invisible views should not be visible to accessibility services (interrogation) 1. Infisible children of a ViewGroup are reported by View group while constructing an AccessibilityNodeInfo. 2. AncestorView does not check whether a found view is shown before returining it or perform action on it. bug:4672230 Change-Id: Ic620ea71b7755c598407bdd813a2beeee400c89c
/frameworks/base/core/java/android/view/ViewGroup.java
|
8643aa0179e598e78d938c59035389054535a229 |
|
20-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Interrogation of the view hierarchy from an AccessibilityService. 1. Views are represented as AccessibilityNodeInfos to AccessibilityServices. 2. An accessibility service receives AccessibilityEvents and can ask for its source and gets an AccessibilityNodeInfo which can be used to get its parent and children infos and so on. 3. AccessibilityNodeInfo contains some attributes and actions that can be performed on the source. 4. AccessibilityService can request the system to preform an action on the source of an AccessibilityNodeInfo. 5. ViewAncestor provides an interaction connection to the AccessibiltyManagerService and an accessibility service uses its connection to the latter to interact with screen content. 6. AccessibilityService can interact ONLY with the focused window and all calls are routed through the AccessibilityManagerService which imposes security. 7. Hidden APIs on AccessibilityService can find AccessibilityNodeInfos based on some criteria. These API go through the AccessibilityManagerServcie for security check. 8. Some actions are hidden and are exposes only to eng builds for UI testing. Change-Id: Ie34fa4219f350eb3f4f6f9f45b24f709bd98783c
/frameworks/base/core/java/android/view/ViewGroup.java
|
cca2c9807206f320bd41bf8656a227e4f249e4ba |
|
20-May-2011 |
Chet Haase <chet@google.com> |
Add ability to transition parent hierarchy in layout transitions This change compensates for changes in the parent hierarchy of transitioning views. It automatically animates parents with the same animations as those used for the CHANGING animations run on the container children. Change-Id: I86471d16a9070b024cc09c8f6e0f504a881fa99f
/frameworks/base/core/java/android/view/ViewGroup.java
|
02739a8eecce26783350041da332f8daf6691e25 |
|
16-May-2011 |
Romain Guy <romainguy@google.com> |
Fix javadoc issues Change-Id: Ife66a8664955ac1a79b6ffd0080000c820f24632
/frameworks/base/core/java/android/view/ViewGroup.java
|
fe9f8ab03a63b1037f07dd85799fbea80ec6adaa |
|
07-May-2011 |
Jeff Brown <jeffbrown@google.com> |
Add initial API for stylus and mouse buttons. Added the concept of pointer properties in a MotionEvent. This is currently used to track the pointer tool type to enable applications to distinguish finger touches from a stylus. Button states are also reported to application as part of touch events. There are no new actions for detecting changes in button states. The application should instead query the button state from the MotionEvent and take appropriate action as needed. A good time to check the button state is on ACTION_DOWN. As a side-effect, applications that do not support multiple buttons will treat primary, secondary and tertiary buttons identically for all touch events. The back button on the mouse is mapped to KEYCODE_BACK and the forward button is mapped to KEYCODE_FORWARD. Added basic plumbing for the secondary mouse button to invoke the context menu, particularly in lists. Added clamp and split methods on MotionEvent to take care of common filtering operations so we don't have them scattered in multiple places across the framework. Bug: 4260011 Change-Id: Ie992b4d4e00c8f2e76b961da0a902145b27f6d83
/frameworks/base/core/java/android/view/ViewGroup.java
|
b51cc1dd63808da505cd8beb7300f57dc98ff1d3 |
|
05-May-2011 |
Patrick Dubroy <dubroy@google.com> |
Merge "Only delay pressed feedback for Views inside a scrolling parent"
|
e0a799a2ac1ca78e30fbac9e4e12a063425c08d3 |
|
05-May-2011 |
Patrick Dubroy <dubroy@google.com> |
Only delay pressed feedback for Views inside a scrolling parent Add a method on ViewGroup to determine whether it supports scrolling. This allows us to show the pressed feedback immediately in many cases, improving responsiveness of buttons, etc. This patch also lengthens the timeout in order to reduce flashes when the user is scrolling. Change-Id: Ieb91ae7a1f8e8f7e87448f2a730381a53947996f
/frameworks/base/core/java/android/view/ViewGroup.java
|
c6cc0f8c19d9eccf408a443fa2bf668af261dcd0 |
|
12-Apr-2011 |
Joe Onorato <joeo@google.com> |
Rename ViewRoot to ViewAncestor. ViewRoot is about to be a new public class for poking at ViewAncestor. Change-Id: Ie95d707c6d8bbb48f78d093d7b2667851812a7d5
/frameworks/base/core/java/android/view/ViewGroup.java
|
9fc27819d75e24ad63d7b383d80f5cb66a577a0d |
|
27-Apr-2011 |
Romain Guy <romainguy@google.com> |
Correctly compute tex coords for rect layers. Bug #4192695 This change also fixes Javadoc links in the framework. Change-Id: Ia548bcb18baba5d6fe6a4a04a2278e3a3bd465b2
/frameworks/base/core/java/android/view/ViewGroup.java
|
736c2756bf3c14ae9fef7255c119057f7a2be1ed |
|
23-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor 1. Added an Input Filter that interprets the touch screen motion events to perfrom accessibility exploration. One finger explores. Tapping within a given time and distance slop on the last exlopred location does click and long press, respectively. Two fingers close and in the same diretion drag. Multiple finglers or two fingers in different directions or two fingers too far away are delegated to the view hierarchy. Non moving fingers "accidentally grabbed the device for the scrren" are ignored. 2. Added accessibility events for hover enter, hover exit, touch exoloration gesture start, and end. Accessibility hover events are fired by the hover pipeline. An accessibility event is dispatched up the view tree and the topmost view fires it. Thus predecessors can augment the fired event. An accessibility event has several records and a predecessor can optionally modify, delete, and add such to the event. 3. Added onPopulateAccessibilityEvent and refactored the existing accessibility code to use it. 4. Added API for querying the currently enabled accessibility services by feedback type. Change-Id: Iea2258c07ffae9491071825d966dc453b07e5134
/frameworks/base/core/java/android/view/ViewGroup.java
|
3fb3d7c4e756bd32d5abde0abca9ab52d559bc84 |
|
23-Apr-2011 |
Adam Powell <adamp@google.com> |
Revert "Touch exploration feature, event bubling, refactor" This reverts commit ac84d3ba81f08036308b17e1ab919e43987a3df5. There seems to be a problem with this API change. Reverting for now to fix the build. Change-Id: Ifa7426b080651b59afbcec2d3ede09a3ec49644c
/frameworks/base/core/java/android/view/ViewGroup.java
|
ac84d3ba81f08036308b17e1ab919e43987a3df5 |
|
05-Apr-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Touch exploration feature, event bubling, refactor 1. Added an Input Filter that interprets the touch screen motion events to perfrom accessibility exploration. One finger explores. Tapping within a given time and distance slop on the last exlopred location does click and long press, respectively. Two fingers close and in the same diretion drag. Multiple finglers or two fingers in different directions or two fingers too far away are delegated to the view hierarchy. Non moving fingers "accidentally grabbed the device for the scrren" are ignored. 2. Added accessibility events for hover enter, hover exit, touch exoloration gesture start, and end. Accessibility hover events are fired by the hover pipeline. An accessibility event is dispatched up the view tree and the topmost view fires it. Thus predecessors can augment the fired event. An accessibility event has several records and a predecessor can optionally modify, delete, and add such to the event. 3. Added onPopulateAccessibilityEvent and refactored the existing accessibility code to use it. 4. Added API for querying the currently enabled accessibility services by feedback type. Change-Id: Iec03c6c3fe298de3f14cb6efdbb9b198cd531a0c
/frameworks/base/core/java/android/view/ViewGroup.java
|
bbdc50b102faf52768ac3028bc49e027ff140656 |
|
20-Apr-2011 |
Jeff Brown <jeffbrown@google.com> |
Track unhandled input events in consistency verifiers. This fixes spurious verification errors that would be generated when a view declined an initial event such as ACTION_DOWN. Since the view would not receive the rest of the event stream, it would not see the corresponding ACTION_UP and the next ACTION_DOWN would trigger a spurious verification error. Change-Id: I2386acf378cd1765d5446faed5ad9c6525f8b400
/frameworks/base/core/java/android/view/ViewGroup.java
|
21bc5c917d4ee2a9b2b8173091e6bba85eaff899 |
|
01-Mar-2011 |
Jeff Brown <jeffbrown@google.com> |
Add a little input event consistency verifier. The idea is to assist with debugging by identifying cases in which the input event stream is corrupted. Change-Id: I0a00e52bbe2716be1b3dfc7c02a754492d8e7f1f
/frameworks/base/core/java/android/view/ViewGroup.java
|
3d4bf17f49b82355b3b82d8bdaec4d65c4293bc9 |
|
29-Mar-2011 |
Christopher Tate <ctate@google.com> |
Add view/drawable states for drag-accepting / drag-hovered Added new drag_can_accept and drag_hovered XML attributes and the View logic to support them. Drawable states are now refreshed automatically when a drag starts/ends and when a drag crosses the boundary of a participating view. Change-Id: I25f8ee02c83b3fa4f27201997d7eabf4be653fd8
/frameworks/base/core/java/android/view/ViewGroup.java
|
b7c25ce3aef3c6e930fc3f31436f52aed8ebed14 |
|
24-Mar-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Add MotionEvent.HOVER_ENTER and HOVER_EXIT."
|
a032cc008618b83ecbbede537517d1e7998e3264 |
|
08-Mar-2011 |
Jeff Brown <jeffbrown@google.com> |
Add MotionEvent.HOVER_ENTER and HOVER_EXIT. The input dispatcher sends a HOVER_ENTER to a window before dispatching it any HOVER_MOVE events. For compatibility reasons, the window will *also* receive the HOVER_MOVE. When the pointer moves into a different window or the pointer goes down or when events are canceled for some reason, the input dispatcher sends a HOVER_EXIT to the previously hovered window. The view hierarchy behavior is similar. All views under the pointer receive onHoverEvent with HOVER_ENTER followed by any number of HOVER_MOVE events. When the pointer leaves a view, the view receives HOVER_EXIT. Similarly, if a parent view decides to capture hover by returning true from onHoverEvent, the hovered descendants will receive HOVER_EXIT. The default behavior of onHoverEvent is to update the view's hovered state by calling setHovered(true/false). Views can query their current hovered state using isHovered(). For testing purposes, the hovered state is mapped to the pressed drawable state. This will change in a subsequent commit with the introduction of a new hovered drawable state. Change-Id: Ib76a7a90236c8f2c7336e55773acade6346cacbe
/frameworks/base/core/java/android/view/ViewGroup.java
|
13f35f3ce6a7d26c20d1c63485bfb5e2ffff31b9 |
|
24-Mar-2011 |
Romain Guy <romainguy@google.com> |
Correctly check bottom padding in setPadding(). Change-Id: Ie8099d37ad865acc559c4a4d34eb84960a1a19f3
/frameworks/base/core/java/android/view/ViewGroup.java
|
7b5b6abf852c039983eded25ebe43a70fef5a4ab |
|
15-Mar-2011 |
Romain Guy <romainguy@google.com> |
Fix rendering artifact in edge fades. Bug #4092053 The problem always existed but was made visible by partial invalidation. When saving a layer, the renderer would try to postpone glClear() operations until the next drawing command. This however does not work since the clip might have changed. The fix is rather simple and simply gets rid of this "optimization" (that turned out to be usless anyway given how View issues saveLayer() calls.) This change also fixes an issue with gradients (color stops where not properly computed when using a null stops array) and optimizes display lists rendering (quickly rejects larger portions of the tree to avoid executing unnecessary code.) Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
/frameworks/base/core/java/android/view/ViewGroup.java
|
2243e555b061254f7f0f72ca1d6cd44db6c266fa |
|
08-Mar-2011 |
Romain Guy <romainguy@google.com> |
Correctly handle opaque fading views Bug #3475554 Change-Id: Ia4915ada67046486103dfc6f08e4dac8564f85dd
/frameworks/base/core/java/android/view/ViewGroup.java
|
bc8a8e8c926115cb7b3910d016e5cff12b0f7b0a |
|
08-Mar-2011 |
Romain Guy <romainguy@google.com> |
Merge "Add support for partial invalidates in WebView Bug #3461349" into honeycomb-mr1
|
cabfcc1364eb7e4de0b15b3574fba45027b45cfc |
|
08-Mar-2011 |
Romain Guy <romainguy@google.com> |
Add support for partial invalidates in WebView Bug #3461349 This change also fixes two bugs that prevented partial invalidates from working with other views. Both bugs were in our EGL implementation: they were preventing the caller from comparing the current context/surface with another context/surface. This was causing HardwareRenderer to always redraw the entire screen. Change-Id: I33e096b304d4a0b7e6c8f92930f71d2ece9bebf5
/frameworks/base/core/java/android/view/ViewGroup.java
|
3ba8f5d675831647e45d0ce11507c85dfb5f753b |
|
08-Mar-2011 |
Adam Powell <adamp@google.com> |
Fix bug 4021346 - crash while navigating Change-Id: Iff60c5f4214c56597f2a1b393982d023866e490e
/frameworks/base/core/java/android/view/ViewGroup.java
|
e8e45d32fd1f67fed1b70d0fc19d2f91a76f128e |
|
03-Mar-2011 |
Chet Haase <chet@google.com> |
Cancel LayoutTransition animations selectively A recent change to LayoutTransition caused new layout transitions to cancel any previously-running animations. This was to handle situations where a transition adding an item needed transitions removing items to finish their job first (and vice versa). But canceling *all* running animations from transitions caused some artifacts, like making the status bar icons blink or fade in, depending on which one was started last. The new approach is to cancel just the ones we care about: adding animations cancel removing animations, and vice versa. Either one cancels 'changing' animations, which prevents objects from being animated to the old end locations, since the new transition will animate them to the correct new end locations. Change-Id: I68ac351b05365cace6639b6618422395c35c83fd
/frameworks/base/core/java/android/view/ViewGroup.java
|
a7dabcd3dfb263468613fa2b04909c8fabb66a9d |
|
02-Mar-2011 |
Romain Guy <romainguy@google.com> |
Don't account for scrollX/Y when drawing a display list in a layer. Change-Id: I73bdcdab3e547d00ba2853aed550e65d5f8c6fcd
/frameworks/base/core/java/android/view/ViewGroup.java
|
d643bb56fdf21973ea75984f0816b7dc024698df |
|
01-Mar-2011 |
Romain Guy <romainguy@google.com> |
Correctly mark layers dirty when drawing WebView. Change-Id: I7ae0c3cfa0916d8fbeaf01e8da127c621a06a0f4
/frameworks/base/core/java/android/view/ViewGroup.java
|
33bbfd2232ea9eaae9a9d87a05a95a430f09bd83 |
|
25-Feb-2011 |
Jeff Brown <jeffbrown@google.com> |
Add support for mouse hover and scroll wheel. Dispatch ACTION_HOVER_MOVE and ACTION_SCROLL through the View hierarchy as onGenericTouchEvent. Pointer events dispatched this way are delivered to the view under the pointer. Non-pointer events continue to be delivered to the focused view. Added scroll wheel support to AbsListView, ScrollView, HorizontalScrollView and WebView. Shift+VSCROLL is translated to HSCROLL as appropriate. Added logging of new pointer events in PointerLocationView. Fixed a problem in EventHub when a USB device is removed that resulted in a long stream of ENODEV errors being logged until INotify noticed the device was gone. Note that the new events are not supported by wallpapers at this time because the wallpaper engine only delivers touch events. Make all mouse buttons behave identically. (Effectively we only support one button.) Change-Id: I9ab445ffb63c813fcb07db6693987b02475f3756
/frameworks/base/core/java/android/view/ViewGroup.java
|
cc0c159e9b3dd4e0f48da0ce3e33d2c68a651413 |
|
19-Feb-2011 |
Jeff Brown <jeffbrown@google.com> |
Add new hover move action and scroll wheel plumbing. Added support for tracking the mouse position even when the mouse button is not pressed. To avoid confusing existing applications, mouse movements are reported using the new ACTION_HOVER_MOVE action when the mouse button is not pressed. Added some more plumbing for the scroll wheel axes. The values are reported to Views but they are not yet handled by the framework. Change-Id: I1706be850d25cf34e5adf880bbed5cc3265cf4b1
/frameworks/base/core/java/android/view/ViewGroup.java
|
0211a0a10d20ec99bd78905ea9cd2960f7beb4c8 |
|
15-Feb-2011 |
Romain Guy <romainguy@google.com> |
Gracefully handle drawing caches allocation failure. Bug #3431451 This bug was causing ListView to not render properly when showing an item larger than the maximum drawing cache size. ListView relies on the drawing cache to correctly mask all the background pixels. However, if the cache is not properly created, the background will show through even though ListView.isOpaque() == true. This change detects this case and falls back to the default non opaque behavior. Change-Id: I30a45e7a03fb7ebb2b12f0e85c075c2901954c44
/frameworks/base/core/java/android/view/ViewGroup.java
|
add6577a0196258e5a48c5deefcdb12e05c935b3 |
|
10-Feb-2011 |
Chet Haase <chet@google.com> |
Fix animation and layoutTransition issues. There were some subtle timing issues in animators with ending animations that were not completely initialized (possibly because a startDelay'd animator was ended before the delay elapsed). Also, LayoutTransition had bugs around running a transition on a container while a previously-started transition was still in progress. This could result in some minor artifacts or crash bugs, depending on the durations and delays set on the transition animations. Change-Id: Ic6a69601f1ce9a55db15fff6b8ed25950b354491
/frameworks/base/core/java/android/view/ViewGroup.java
|
85cabc2eb367e8dcbe7445886bdd945e47d1bbfa |
|
07-Feb-2011 |
Mike Cleron <mcleron@google.com> |
am 9cfa9c7a: am f6141980: Merge changes I46acd27a,I70b322e1 into honeycomb * commit '9cfa9c7a3f5f23dec6ef4575407c1076d1b3c479': aa is better than cc Prevent ProgressBar from slowing down everything. bug #3422568
|
8b113cf6d78bdb673e97400951b0829d722dba2b |
|
04-Feb-2011 |
Romain Guy <romainguy@google.com> |
am cb2c84fd: am 3b66e43e: Merge "Refresh display lists when turning off layers rendering. Bug #3420565" into honeycomb * commit 'cb2c84fd81a0891071e8ed0237927ad785751850': Refresh display lists when turning off layers rendering. Bug #3420565
|
2f57ba56b3d4648476f0c00bd74fc4f6aa052810 |
|
04-Feb-2011 |
Romain Guy <romainguy@google.com> |
Prevent ProgressBar from slowing down everything. bug #3422568 Change-Id: I70b322e140a8fdbe504c6984c54a22bcb7b753e7
/frameworks/base/core/java/android/view/ViewGroup.java
|
9d18f2d189aa2670d96462f2220ee7fd7950ebe5 |
|
03-Feb-2011 |
Romain Guy <romainguy@google.com> |
Refresh display lists when turning off layers rendering. Bug #3420565 Change-Id: I2139540e591a97cd487e3d7cce6b70d6b23df9de
/frameworks/base/core/java/android/view/ViewGroup.java
|
44fbc03f651ce79b0726a6bb585567918a88e29c |
|
02-Feb-2011 |
Romain Guy <romainguy@google.com> |
am 57188f0d: am c1f8bcff: Merge "Fix incorrect dirty rectangle transformation in hardware layers. Bug #3413433" into honeycomb * commit '57188f0d1d7225991f8f5afb2740ed4cc878305b': Fix incorrect dirty rectangle transformation in hardware layers. Bug #3413433
|
beff8d83ef062975459f149ad0c632a3797d78ce |
|
02-Feb-2011 |
Romain Guy <romainguy@google.com> |
Fix incorrect dirty rectangle transformation in hardware layers. Bug #3413433 Change-Id: Iba201c7c4b4f11937797f3afcbf20c5a7395be25
/frameworks/base/core/java/android/view/ViewGroup.java
|
34cdf5bbb7d4d09e95cc6579a96c384284f99455 |
|
02-Feb-2011 |
Romain Guy <romainguy@google.com> |
am debeeef5: am d51eaa64: Merge "Update layers based on the dirty region. Bug #3413433" into honeycomb * commit 'debeeef50408cf12f1041426e7438be266789a62': Update layers based on the dirty region. Bug #3413433
|
3a3133d876caf60ebff2176ad75c3dcf0259148d |
|
02-Feb-2011 |
Romain Guy <romainguy@google.com> |
Update layers based on the dirty region. Bug #3413433 This helps Launcher when a widget updates during a scroll, or when interacting with widgets on the workspace if layers are still turned on. Change-Id: Ic7a42eb34f74f4ae988039754f815e2efd1d1e4f
/frameworks/base/core/java/android/view/ViewGroup.java
|
4e96efe2edb73a8fbe4b89e85e03327da9796d80 |
|
02-Feb-2011 |
Romain Guy <romainguy@google.com> |
am a42ee699: am 518813ec: Merge "New API to let apps draw without layers. Bug #3413433" into honeycomb * commit 'a42ee6994b59c02a745cb5d0f8ec257d01424753': New API to let apps draw without layers. Bug #3413433
|
849d0a37cf2ca6c6a6c2d4d4456495e32e363120 |
|
02-Feb-2011 |
Romain Guy <romainguy@google.com> |
New API to let apps draw without layers. Bug #3413433 Launcher now enables layers all the time, but in some cases (for instance, when the workspace is not scrolling,) it is more efficient to draw without the layer. Change-Id: I625fb5b48506acda9ae75356fdbbe812c85f2aab
/frameworks/base/core/java/android/view/ViewGroup.java
|
509e6cd89551d4222fab3dab9df190cc5e25666b |
|
01-Feb-2011 |
Romain Guy <romainguy@google.com> |
am 1c531f4a: am f222956c: Merge "Correctly set the alpha of a hardware layer before drawing it. Bug #3410819" into honeycomb * commit '1c531f4a44c9ea61e74dbe2ded1b8dca0f83f790': Correctly set the alpha of a hardware layer before drawing it. Bug #3410819
|
54229ee5eb92e3e2fc63d75353bcf09e0ebc8030 |
|
01-Feb-2011 |
Romain Guy <romainguy@google.com> |
Correctly set the alpha of a hardware layer before drawing it. Bug #3410819 Change-Id: I3ebaca2233f4edf5b59d84ec7706555056a1a4b1
/frameworks/base/core/java/android/view/ViewGroup.java
|
38d1f2530829ae14d5ee9bf7871cb359dbf03f89 |
|
28-Jan-2011 |
Chet Haase <chet@google.com> |
am 19312cfe: am 246bf85a: Merge "Fix NPE with display lists when view not attached" into honeycomb * commit '19312cfef15608fca2c8403dc240e8ec4f54d6b7': Fix NPE with display lists when view not attached
|
f4ac547f868db7c8a358e1f6e3d8fcebb02dbd49 |
|
27-Jan-2011 |
Chet Haase <chet@google.com> |
Fix NPE with display lists when view not attached There was logic in ViewGroup that assumed that an accelerated view must always be able to get a display list for any child that it was drawing. One situation occurred, however, that caused a problem with this - a contacts activity was started and not yet attached, but was being asked to render into an accelerated canvas. We assumed that the child would have a display list and simply called getDisplayList(). But since that call returned null, we later deref'd the null object. The fix is to check whether a child can have a display list instead of assuming that it can just because the container view is accelerated. Change-Id: I7de62fd597ad50720c9585d621bec02e77c171df
/frameworks/base/core/java/android/view/ViewGroup.java
|
75b8c858ab43375092da06658b6046a007eb85ef |
|
27-Jan-2011 |
Chet Haase <chet@google.com> |
am cd88c39b: am e38ba4ac: Fix gmail crossfade artifacts. * commit 'cd88c39b989fc927016aa8d1c3794b872519d575': Fix gmail crossfade artifacts.
|
e38ba4acbe6f1536997ffb98d662fc3eff07add8 |
|
27-Jan-2011 |
Chet Haase <chet@google.com> |
Fix gmail crossfade artifacts. Display lists could not handle custom views that did their own draw dispatching, as is the case with gmail. This fix makes that possible and display lists handle this case robustly. Now the crossfade works because the display lists contain the right content. Change-Id: Iea7d6e99239b24f833701d546fe083aa00e2b31b
/frameworks/base/core/java/android/view/ViewGroup.java
|
82782446cd0ea26604fcbd22d4b7e3608f32136d |
|
27-Jan-2011 |
Chet Haase <chet@google.com> |
am fcf51a67: am a45c056e: Merge "Fix display List bugs" into honeycomb * commit 'fcf51a67967a402bf2178c3d0e09828e8942cade': Fix display List bugs
|
678e0adbdbac5fa3f25ca8371fdff1b3182f67e9 |
|
25-Jan-2011 |
Chet Haase <chet@google.com> |
Fix display List bugs Various property setters in View need to invalidate the parent's cache to get redrawn properly when accelerated with display lists. Also, fix logic around display lists and old-style Animations in ViewGroup. Change-Id: I70e1c2fa49e62228ee4a1301a006ce50bda4c305
/frameworks/base/core/java/android/view/ViewGroup.java
|
e29131cac364d38e6ee598d190027a1b9bdda01d |
|
26-Jan-2011 |
Chet Haase <chet@google.com> |
am b69e985b: am ace9233b: Merge "Fix invalidation problem with display lists" into honeycomb * commit 'b69e985b9aa059d6cf7498a2350d3f814b4cf711': Fix invalidation problem with display lists
|
77785f9d257f663087a8c27957f506b9f7aa24c2 |
|
26-Jan-2011 |
Chet Haase <chet@google.com> |
Fix invalidation problem with display lists It was previously the case that a view marked ~DRAWN must be invalidated correctly already, so we would not mark any flags. Display lists added new logic such that an undrawn node must still be checked to see if its cache has been marked invalid. If not, we must mark it invalid to make sure that a future rendering call will cause the view to refresh its display list, thus refreshing its child node tree's display lists, since that's where the invalidate call must have originated. Change-Id: I0f73c85459174c0e3f16d703f7eb914a706c808a
/frameworks/base/core/java/android/view/ViewGroup.java
|
335f1513d7644a62e8d1a5b47befd950371d4665 |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
am b372d7cb: am 89fca351: Merge "Make nested hardware layers work again" into honeycomb * commit 'b372d7cbea0b80cda3c7b08dcaddbd5c398911b2': Make nested hardware layers work again
|
5e7f766e99c679110fa95501728bb81a8e396e58 |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
Make nested hardware layers work again Change-Id: I97bde694ec1b712a1e010c8137919e6d64af3148
/frameworks/base/core/java/android/view/ViewGroup.java
|
caf48e95e7ce9417c1f89aa28bc262b9ffd90797 |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
am 7b4950ae: am 169fafe6: Merge "Fix rendering issues with animated layers. Bug #3385247" into honeycomb * commit '7b4950ae350255a393125cc4262925b432770ac4': Fix rendering issues with animated layers. Bug #3385247
|
8168396d1acbcb5fdd29eeda4c30b2803d5283ae |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
Fix rendering issues with animated layers. Bug #3385247 - The layer's alpha was interpreted in the wrong range 0..255 instead of 0..1 - 9-patches would not correctly dirty the layer region, the generated mesh was incorrect Change-Id: I4916249bedcdb0794929f3796bd17854971efc88
/frameworks/base/core/java/android/view/ViewGroup.java
|
e965dee34135e7bce186408d1265a5cfd05a9fb1 |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
am 4e1db6da: am 2ff6d705: Merge "Enable partial invalidates when rendering with OpenGL." into honeycomb * commit '4e1db6dadd404c023b71ae1ab54e990fce56abc3': Enable partial invalidates when rendering with OpenGL.
|
2ff6d70521fe1f537f8ebd631f0b9b3aa8becf94 |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
Merge "Enable partial invalidates when rendering with OpenGL." into honeycomb
|
7d7b5490a0b0763e831b31bc11f17d8159b5914a |
|
25-Jan-2011 |
Romain Guy <romainguy@google.com> |
Enable partial invalidates when rendering with OpenGL. Change-Id: Ie8be06c4776b815e8737753eb8003b4fd8936130
/frameworks/base/core/java/android/view/ViewGroup.java
|
f8ac62237babea7ec08ba71d00539f33d6ad560d |
|
25-Jan-2011 |
Chet Haase <chet@google.com> |
am 235a20a3: am 21d405f5: Merge "Fix for display list problem with listview items." into honeycomb * commit '235a20a3d1b57492ba0fbebb7f9dcce41ef011d0': Fix for display list problem with listview items.
|
3b2b0fc257b4c69cdd5c1f2885359786af6787df |
|
25-Jan-2011 |
Chet Haase <chet@google.com> |
Fix for display list problem with listview items. We were not correctly invalidating items that were being attached to listviews. Change-Id: I5d29a82c4276f09e401c6869ab1e86a3c8281366
/frameworks/base/core/java/android/view/ViewGroup.java
|
3873da3c6ee0a63de0d91e6045b7546402f4ce3d |
|
24-Jan-2011 |
Chet Haase <chet@google.com> |
am 2acb67ec: am 67005b05: Merge "Use optimized display lists for all hwaccelerated rendering" into honeycomb * commit '2acb67ec9fe34316231519373f59dfb76c03d57b': Use optimized display lists for all hwaccelerated rendering
|
10f4126a367071a49f208f10ceb1ed0e1151d48c |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
resolved conflicts for merge of faf083ef to master Change-Id: I316a1b4356f6dba6c3880ccb02dbb2fa00d21a85
|
daf98e941e140e8739458126640183b9f296a2ab |
|
10-Jan-2011 |
Chet Haase <chet@google.com> |
Use optimized display lists for all hwaccelerated rendering Previously, display lists were used only if hardware acceleration was enabled for an application (hardwareAccelerated=true) *and* if setDrawingCacheEnabled(true) was called. This change makes the framework use display lists for all views in an application if hardware acceleration is enabled. In addition, display list renderering has been optimized so that any view's recreation of its own display list (which is necessary whenever the visuals of that view change) will not cause any other display list in its parent hierarchy to change. Instead, when there are any visual changes in the hierarchy, only those views which need to have new display list content will recreate their display lists. This optimization works by caching display list references in each parent display list (so the container of some child will refer to its child's display list by a reference to the child's display list). Then when a view needs to recreate its display list, it will do so inside the same display list object. This will cause the content to get refreshed, but not the reference to that content. Then when the view hierarchy is redrawn, it will automatically pick up the new content from the old reference. This optimization will not necessarily improve performance when applications need to update the entire view hierarchy or redraw the entire screen, but it does show significant improvements when redrawing only a portion of the screen, especially when the regions that are not refreshed are complex and time- consuming to redraw. Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
/frameworks/base/core/java/android/view/ViewGroup.java
|
664644d9e012aa2a28ac96f305b1ce6499ec8806 |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
visibility ("lights out") API. 1. Views may setSystemUiVisibility() to recommend that the system chrome (status bar or other UI) show or hide itself. (This functionality was previously available only via the FLAG_FULLSCREEN window flag for some SystemUI implementations.) 2. Views may register a OnSystemUiVisibilityChangedListener on a view, and find out when the system UI actually appears or disappears, allowing apps to coordinate the appearance of their own UI if desired. Bug: 3241144 Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
/frameworks/base/core/java/android/view/ViewGroup.java
|
22da4dd48ec8c143d90126a0760a06774c4923a9 |
|
19-Jan-2011 |
Christopher Tate <ctate@google.com> |
am 714066d8: am 5383d077: Merge "Fix a couple of drag & drop crashes" into honeycomb * commit '714066d873b70098c09c2c094d374781b12d65a2': Fix a couple of drag & drop crashes
|
1fc014fd0051a48083c6d469c2a4f22da1aa15e4 |
|
19-Jan-2011 |
Christopher Tate <ctate@google.com> |
Fix a couple of drag & drop crashes 1. ViewGroups being removed from the layout during a drag would wind up crashing the app with an NPE at drag-ended time, due to blind dereference of now-cleared object pointers. 2. Passing a 'null' ClipData to startDrag() would crash the system process with an NPE. Should this even be valid? I'm inclined to say yes, though it means that apps will need to guard against it. Fixes bug 3369542 Change-Id: I168fc1284d6fd4403999946609725414cf254df0
/frameworks/base/core/java/android/view/ViewGroup.java
|
0f6226b9f417182bbf791598000f0a153fbf191c |
|
18-Jan-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Add joystick support to framework."
|
d6cd572df8067c40b3e0e7e74e58cdb456b33e92 |
|
17-Jan-2011 |
Romain Guy <romainguy@google.com> |
Improve hardware layers rendering speed when setting a View's alpha. Change-Id: Ib1275677f531c60d9919978c5538c663fdb823b5
/frameworks/base/core/java/android/view/ViewGroup.java
|
cb1404e45639d20439d7700b06d57ca1a1aad1fa |
|
16-Jan-2011 |
Jeff Brown <jeffbrown@google.com> |
Add joystick support to framework. Change-Id: I95374436708752e1a9cff3f85c5b9bc3e0987961
/frameworks/base/core/java/android/view/ViewGroup.java
|
86cab1bd52197d6fa60786413fad9788d9236762 |
|
14-Jan-2011 |
Christopher Tate <ctate@google.com> |
Send DRAG_STARTED notices to views that become visible during drag We now recognize that a view is now a candidate for receiving the drop but hasn't yet been notified about it, and send the DRAG_STARTED lifecycle event properly. This change also changes the DRAG_ENDED policy: now, every view that had been sent a DRAG_STARTED receives the corresponding DRAG_ENDED event, even though subsequent visibility changes may have occured. Change-Id: If4ae9ddbf414703e9f15eb2005471626bf19f316
/frameworks/base/core/java/android/view/ViewGroup.java
|
c15c7a79a69733bd21d6548fd74c2874fdabe7e8 |
|
13-Jan-2011 |
Romain Guy <romainguy@google.com> |
Merge "Cleanup implementation of hardware layers." into honeycomb
|
ada830f639591b99c3e40de22b07296c7932a33f |
|
13-Jan-2011 |
Romain Guy <romainguy@google.com> |
Cleanup implementation of hardware layers. The new implementation relies on OpenGLRenderer's existing layer code instead of duplicating it. The new code is much cleaner, with simpler and better APIs and allows tracking of drawn regions inside layers. Region tracking is not yet enabled but this will be done in a future CL. Change-Id: Ie826121a2227de8252c77b992a61218defea5143
/frameworks/base/core/java/android/view/ViewGroup.java
|
9c0874408cfc6f6f4e4561973ca5ae52a5982db7 |
|
13-Jan-2011 |
Chet Haase <chet@google.com> |
Supress layout requests while a LayoutTransition is running. LayoutTransition works by animating layout-related properties (left, right, top, and bottom). This works great when that animation is the only thing affecting the layout of the UI. But if there are other things happening in the application that cause layout to run on that container or in its parent hierarchy, this can cause the layout properties on its children to get mis-set during the middle of the transition. This results in artifacts like animating objects jumping to locations where they would be were there no animation running. The fix is to supress layout requests on that container (and its children) until the transition is complete (then issue a layout request on the container to make sure that the container has the correct layout data) Change-Id: I15bf0423a11409f854076f86099233db7fe4edc0
/frameworks/base/core/java/android/view/ViewGroup.java
|
6c319ca1275c8db892c39b48fc54864c949f9171 |
|
11-Jan-2011 |
Romain Guy <romainguy@google.com> |
Better backend for hardware layers. With this new backend, a hardware layer is only recreated when its associated view is udpated. This offers fast composition in GL and fast update of the layer in GL as well. Change-Id: I97c43a612f5955c6bf1c192c8ca4af10fdf1d076
/frameworks/base/core/java/android/view/ViewGroup.java
|
e95003e4a15eea2d5f93950fc46f99ff2b9c973a |
|
09-Jan-2011 |
Romain Guy <romainguy@google.com> |
Tighten up AsyncTask's semantics and behavior. Bug #3109366 Bug #3109382 The new behavior of AsyncTask is the following: - Unchanged if you don't call cancel() - If you call cancel(): - Either onCancelled() *OR* onPostExecute() is invoked - onCancelled() is invoked only after doInBackground() finishes Change-Id: If53faec5890d2fa7098aea76973186a0b1026b39
/frameworks/base/core/java/android/view/ViewGroup.java
|
7e68efb0a098149e1e6f86663e978e9fd26e0ea1 |
|
07-Jan-2011 |
Romain Guy <romainguy@google.com> |
Non-opaque views with fading edges cannot be marked dirty opaque. Bug #3325084 Change-Id: I80b7653daa2ae3cc6d81da1063911aa4cb69e8f4
/frameworks/base/core/java/android/view/ViewGroup.java
|
171c592f0b7066acf279863c8a52ddabea49d3db |
|
06-Jan-2011 |
Romain Guy <romainguy@google.com> |
New layers API for Views. This API can be used to back a view and its children with either a software layer (bitmap) or hardware layer (FBO). Layers have various usages, including color filtering and performance improvements during animations. Change-Id: Ifc3bea847918042730fc5a8c2d4206dd6c9420a3
/frameworks/base/core/java/android/view/ViewGroup.java
|
03ab0c7231a5c534b86eca28d875c6026ae09564 |
|
07-Jan-2011 |
Joe Onorato <joeo@google.com> |
some touch event debugging Change-Id: I05d69da4db8c03f9c5131cd271bd9ee1b4996ca9
/frameworks/base/core/java/android/view/ViewGroup.java
|
995e77431982f9a320451dbe6132a62e69f73bab |
|
23-Dec-2010 |
Jeff Brown <jeffbrown@google.com> |
Enable touch splitting by default for Honeycomb apps. Also fixed some bad comments I noticed along the way. Change-Id: I4328c8aaa22f48a5c1fd274e889abb7823747330
/frameworks/base/core/java/android/view/ViewGroup.java
|
4e6319b73c85082e18d1c532b86336ddd1f8cfaa |
|
13-Dec-2010 |
Jeff Brown <jeffbrown@google.com> |
Add initial support for TAB navigation. Bug: 3286652 Change-Id: I813a0318b3b8d9c9bc791ea6a2427be11c08de00
/frameworks/base/core/java/android/view/ViewGroup.java
|
669084dbe6f1a20517964745028eff158c2c27e3 |
|
08-Dec-2010 |
Mathias Agopian <mathias@google.com> |
resolved conflicts for merge of a0f011ff to master Change-Id: I4c17021fc269ce66c98cc345353600eda332f980
|
e33811512eb061338792dbb0dbd37a1b8e4e1079 |
|
03-Dec-2010 |
Mathias Agopian <mathias@google.com> |
[3253328, 3171580] Treat GONE and INVISIBLE views the same when calculating transparent regions We only used to check for INVISIBLE, which prevented some Surfaceview optimization to take place. Change-Id: I244b54696d861a022ca1c334ff61ab7efb899587
/frameworks/base/core/java/android/view/ViewGroup.java
|
f2f7d8f9dd75c6e32a46a28fd3f53435addf0746 |
|
03-Dec-2010 |
Chet Haase <chet@google.com> |
Fix invalidation issue for optimized/GL case. The bug caused intermittent artifacts where some apps would not get repainted until some overall screen invalidation occurred. Change-Id: I82a3294429f15fe51cc8f4b47134e3b5540cb240
/frameworks/base/core/java/android/view/ViewGroup.java
|
0d200833fdc53f9796698f97c18cefc4a1b82df2 |
|
05-Nov-2010 |
Chet Haase <chet@google.com> |
Fix GL rendering of translucent surfaces GL renderer was not initializing scissor correctly for translucent surfaces, resulting in invisible window backgrounds in some cases like fading popup windows Change-Id: I87a964986e1ba2c4f59708c8892c5fa71903e6fc
/frameworks/base/core/java/android/view/ViewGroup.java
|
e213677037f836529efcc0ac201fc61dd95481c5 |
|
04-Nov-2010 |
Dianne Hackborn <hackbod@google.com> |
Push the jumpDrawablesToCurrentState() thing off everywhere it should be. Also add a new interface that items in AbsListView can implement to adjust the bounds of the selection shown for them. This will allow contacts to use list view's regular selection facility rather than implementing something special in their item views. Change-Id: I29cbdbc7122111ee97e47fe7d6ec55ff07be79cc
/frameworks/base/core/java/android/view/ViewGroup.java
|
9d1ab883293b047b654935b84d0803c8c383be91 |
|
02-Nov-2010 |
Chris Tate <ctate@google.com> |
Fix drag enter/exit reporting Now, each ViewGroup is tracking which of its child views [which might themselves be ViewGroups] is currently under the drag point, and when the drag leaves that child, a DRAG_EXITED is synthesized and dispatched all the way down to the leaf view previously under the point. ENTERED is still *not* dispatched down like this; instead, it's calculated and synthesized directly at each level based on the new LOCATION. The ViewRoot still tracks the leaf drag target, but solely for the purpose of reporting changes to the OS after full dispatch of a new LOCATION -- the entered/exited messaging is no longer initiated at the ViewRoot level. Change-Id: I0089cc538b7e33a0440187543fcfd2f8b12e197d
/frameworks/base/core/java/android/view/ViewGroup.java
|
a32edd4b4c894f4fb3d9fd7e9d5b80321df79e20 |
|
26-Oct-2010 |
Adam Cohen <adamcohen@google.com> |
Adding click feedback to widget collections Change-Id: I97fceb6c68ca6eb1b703eafacf201e1aed7c38e7
/frameworks/base/core/java/android/view/ViewGroup.java
|
70d4ba15b1f0c1133c5aabc86de828b41e482fff |
|
06-Oct-2010 |
Chet Haase <chet@google.com> |
Performance optimizations for animations and toolkit Change-Id: I316a48273a9cbb428a965e4b849b3e5e9e8202f1
/frameworks/base/core/java/android/view/ViewGroup.java
|
0d9275e565551eed57297627188aa39f3897a50b |
|
26-Oct-2010 |
Romain Guy <romainguy@google.com> |
Enable display lists. Change-Id: Id0d9b987251da5b7ecbb5497a55dbb5937430316
/frameworks/base/core/java/android/view/ViewGroup.java
|
5c13d89c1332fcc499379b9064b891187b75ca32 |
|
08-Oct-2010 |
Chet Haase <chet@google.com> |
Optimizing display lists by referencing pointers to resources instead of copying them Change-Id: I81ad3551d74aa1e5bb64d69e33d2eb29a6c1eb6a
/frameworks/base/core/java/android/view/ViewGroup.java
|
fb0547d2c0f84e8266dce1444d332433ada09249 |
|
20-Oct-2010 |
Patrick Dubroy <dubroy@google.com> |
Fix memory leak with TouchTargets not being recycled.
/frameworks/base/core/java/android/view/ViewGroup.java
|
32affef4f86961c57d9ba14572ec65dc2a5451de |
|
19-Oct-2010 |
Chris Tate <ctate@google.com> |
Introduce an OnDragListener mechanism If the listener's onDrag(view, event) returns 'false', the view's own onDragEvent() will be called. If the listener returns 'true', it consumes the event (and declares that it will handle the rest of the drag event sequence, in the case of DRAG_STARTED actions). Change-Id: I01aff0e4f59f71e55f5eea1049905c80714f0607
/frameworks/base/core/java/android/view/ViewGroup.java
|
67a2f7b5a1b3ec5d2440d8be6e5ee4274e90e226 |
|
14-Oct-2010 |
Romain Guy <romainguy@google.com> |
Never skip drawing SurfaceViews. Change-Id: I07fbc632b01d96cee16b6e000e0cbf05238a442b
/frameworks/base/core/java/android/view/ViewGroup.java
|
a3496a9e6011e73deadd33bd0edd9229512e23d3 |
|
12-Oct-2010 |
Romain Guy <romainguy@google.com> |
Fix invisible views issue in Launcher. Change-Id: Ic7cb8f418b5879110eaea5a9c5fdb4f237ca4cab
/frameworks/base/core/java/android/view/ViewGroup.java
|
dbc26d2ba13f80a7590c57de2d80530d96832969 |
|
12-Oct-2010 |
Romain Guy <romainguy@google.com> |
Don't draw fully transparent views/primitives. Change-Id: Icd7d8ef1f57b51a24faf32f7004125e6300d4fdc
/frameworks/base/core/java/android/view/ViewGroup.java
|
5ada6cb0591c1106e3591a3b7adcdc77a1322209 |
|
05-Oct-2010 |
Christopher Tate <ctate@google.com> |
More drag/drop adjustments: * Make View.onDragEvent() public instead of protected. * No longer @hide View.startDrag() * Properly manage the boundaries of DRAG_STARTED / DRAG_ENDED notifications to windows (and as a result don't send bogus empty DRAG_STARTED events or double-recycle pooled DragEvents) Change-Id: Ib75f5c1417640c82a5b043c555e02d6e6f4b4d9c
/frameworks/base/core/java/android/view/ViewGroup.java
|
469b1dbeaf7d3267d1b43af4e7391b49eac10ee0 |
|
05-Oct-2010 |
Romain Guy <romainguy@google.com> |
Code cleanup and disable display lists for now. Change-Id: I681213036b5279339cb96a016d1dfb15d74dafc8
/frameworks/base/core/java/android/view/ViewGroup.java
|
2c095f367779ef32130c72849936a2e3013c8492 |
|
04-Oct-2010 |
Christopher Tate <ctate@google.com> |
Refinements to drag/drop Thumbnail measurement & drawing has been moved out into a delegate class called View.DragThumbnailBuilder. This consolidates the thumbnail-related code as well as ensuring that the drag initiator does not have to know a priori where to place the thumbnail relative to the touch point *before* the thumbnail measurement step, as was previously the case. startDrag() no longer needs to be told where the current touch point is at the time the drag is launched. Drag events are now dispatched only to VISIBLE views. Dispatch shouldn't double-recycle events any more when the target window is local to the system process. Change-Id: I49419103765a0cad2e18ddfcdd6dacb94daf1ff1
/frameworks/base/core/java/android/view/ViewGroup.java
|
5e25c2c14593caee5638603120553ae1ec530f85 |
|
16-Sep-2010 |
Chet Haase <chet@google.com> |
Add ability to automate animated transitions on View show/hide Change-Id: Id6ff92c8fd06c3f5fb30c41b020b4de4f567154f
/frameworks/base/core/java/android/view/ViewGroup.java
|
a53146c5569f8ff5f7eb55e9ad35d23ddacf2add |
|
07-Sep-2010 |
Christopher Tate <ctate@google.com> |
Drag/drop APIs and infrastructure A View initiates a drag-and-drop operation (hereafter just called a "drag") by calling its startDrag(ClipData) method. Within the processing of that call, two callbacks are made into the originating View. The first is to onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this callback must respond by calling setDragThumbnailDimension(width, height) to declare the size of the drag thumbnail image that should be used. Following this, the View's onDrawDragThumbnail(canvas) method will be invoked to actually produce the bits of the thumbnail image. If all goes well, startDrag() will return 'true', and the drag is off and running. (The other arguments to startDrag() provide reconciliation between the current finger position and where the thumbnail should be placed on the screen relative to it.) Potential receipients of the ClipData behind the drag are notified by a new dispatch mechanism, roughly parallel to motion event dispatch. The core routine is the View's onDragEvent(event) callback, with the mechanics of dispatch itself being routed through dispatchDragEvent(event) -- as in the case of motion events, the dispatch logic is in ViewGroup, with leaf View objects not needing to consider the dispatch flow. Several different event 'actions' are delivered through this dispatch mechanism: ACTION_DRAG_STARTED: this event is propagated to every View in every window (including windows created during the course of a drag). It serves as a global notification that a drag has started with a payload whose matching ClipDescription is supplied with the event. A View that is prepared to consume the data described in this event should return 'true' from their onDragEvent() method, and ideally will also make some visible on-screen indication that they are a potential target of the drop. ACTION_DRAG_ENTERED: this event is sent once when the drag point enters the View's bounds. It is an opportunity for the View to set up feedback that they are the one who will see the drop if the finger goes up now. ACTION_DRAG_LOCATION: when the drag point is over a given View, that View will receive a stream of DRAG_LOCATION events, providing an opportunity for the View to show visual feedback tied to the drag point. ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point leaves the View's bounds. The View should undo any visuals meant to emphasize their being the hovered-over target. ACTION_DROP: when the drag ends at a given point, the View under that point is sent this event, with the full ClipData of the payload. ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global broadcast that the drag has ended and all Views should return to their normal visual state. This happens after the DROP event. Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
/frameworks/base/core/java/android/view/ViewGroup.java
|
20e987bfc35d0ae6cb6344ead65ed44ee7cf8750 |
|
23-Aug-2010 |
Jeff Brown <jeffbrown@google.com> |
Add MotionEvent Matrix transformations. Fixed issued in ViewGroup's transformation of MotionEvents to ensure that the entire historical trace is transformed, not just the current pointer. Simplified the code in ViewGroup for splitting events across Views. The new code also handles the case where some pointers are dispatched to the ViewGroup in addition to its children whereas the previous code would drop some pointers on the floor. Change-Id: I56ac31903e1de8a9c376d9c935b7217b0c42d93e
/frameworks/base/core/java/android/view/ViewGroup.java
|
b051e895ccb696604349c6c5efe7c4747e1d1ab6 |
|
29-Sep-2010 |
Romain Guy <romainguy@google.com> |
Add display lists caching. Change-Id: Iac3a248a81ed8cb076a83ef9d186b8ebba685b4c
/frameworks/base/core/java/android/view/ViewGroup.java
|
fd880425e058a039ed6483d822738b80f962eb08 |
|
24-Sep-2010 |
Romain Guy <romainguy@google.com> |
Don't clip alpha layers if the flag is not set. Change-Id: I820fa66bc3699357677f37a769de52fd176d9416
/frameworks/base/core/java/android/view/ViewGroup.java
|
879fb6b5d66bec90d3420fad12a2a9b2fe9592f3 |
|
20-Sep-2010 |
Adam Powell <adamp@google.com> |
Text selection anchors changed to use windows Manually cherry-picked Change-Id: Id080dfad0e2f324fef3a5175abc78f76c8bad4c8
/frameworks/base/core/java/android/view/ViewGroup.java
|
9aed300279db6953356aed5ef24a42291f5829cb |
|
20-Sep-2010 |
Adam Powell <adamp@google.com> |
Text selection anchors changed to use windows Change-Id: I14f138039f5e3175a8c07f21985715b8447708e5
/frameworks/base/core/java/android/view/ViewGroup.java
|
5d8f9dd3572c9d3b3d57985c31427dc9ca2a7f4a |
|
18-Sep-2010 |
Adam Powell <adamp@google.com> |
am 99f0f367: am 4258bfb7: Merge "Fix some drawing artifacts/bugs around overlays/text anchors" into gingerbread Merge commit '99f0f3676f50640dbb22bd12960f771fc414862e' * commit '99f0f3676f50640dbb22bd12960f771fc414862e': Fix some drawing artifacts/bugs around overlays/text anchors
|
23bd5f50759c54224a2620cbed4614e434437265 |
|
18-Sep-2010 |
Adam Powell <adamp@google.com> |
Fix some drawing artifacts/bugs around overlays/text anchors Change-Id: I28170d4e120506c09a1cfea721244fbcd3c2576a
/frameworks/base/core/java/android/view/ViewGroup.java
|
f37df070ea84c353ff8bed4b2591932126d7e2ca |
|
18-Sep-2010 |
Adam Powell <adamp@google.com> |
resolved conflicts for merge of b39470b5 to master Change-Id: If441c8684c576b6cbc485a37088d6869ad3fb23f
|
b08013c312e3d849029a2f4c11889274c00f438d |
|
17-Sep-2010 |
Adam Powell <adamp@google.com> |
Added overlay support for drawing/responding to text anchors. Overlays let views draw and respond to touch events outside of their bounds. This allows selection anchors to be friendlier and easier to grab. This is currently private API, pending further evaluation. Added themes/styles for text selection anchors. Added assets for text selection anchors as provided by UX. The left/right anchors are currently not suitable for use. They are here for bookkeeping and replacement later. The theme currently uses the 'middle' anchor asset for all three. This will be changed once assets are ready. Change-Id: I01b21e5ae90cab201f86f38f2f5eeaf2bd7f6bcd
/frameworks/base/core/java/android/view/ViewGroup.java
|
d0fa371f276fde32d81c037006941bc93da0bb03 |
|
15-Sep-2010 |
Dianne Hackborn <hackbod@google.com> |
Add a new "activated" state to View. Use this in ListView and GridView if the top view is not checkable. This allows PreferenceActivity to now highlight the current heading that is being shown. Change-Id: I0d28aded9a61a42962b4aece420ae4058712d963
/frameworks/base/core/java/android/view/ViewGroup.java
|
167bc821ddfee3d6d3b1c0ea10636be7c6eb591a |
|
14-Sep-2010 |
Adam Powell <adamp@google.com> |
Fix bug 2995805 - splitMotionEvents behavior change Changed the new split motion events behavior to match the enshrined behavior. A return value of false from a target's dispatchTouchEvent will not prevent the target from receiving further events in the gesture unless it is the initial ACTION_DOWN event. Change-Id: Ied8d531dfec7009a4124ed670b1700753c3f9caa
/frameworks/base/core/java/android/view/ViewGroup.java
|
b20db3ec34e846010f389880b2cfab4d7bf79820 |
|
10-Sep-2010 |
Chet Haase <chet@google.com> |
Make fragment animations work when fragments go away Change-Id: I136de6ef910cc02b8181fcfa065bdb0770841396
/frameworks/base/core/java/android/view/ViewGroup.java
|
b380c4d7edc158788a85c906900232675c0164ac |
|
08-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of a05088c1 to master Change-Id: I7973f9f28586dec9b9659f8f662f40db7997a521
|
85a3176704b5bfbeece9bd928369fbb76eec7dc6 |
|
02-Sep-2010 |
Jeff Brown <jeffbrown@google.com> |
Add support for secure views. Added the MotionEvent.FLAG_WINDOW_IS_OBSCURED flag which is set by the input manager whenever another visible window is partly or wholly obscured the target of a touch event so that applications can filter touches accordingly. Added a "filterTouchesWhenObscured" attribute to View which can be used to enable filtering of touches when the view's window is obscured. Change-Id: I936d9c85013fd2d77fb296a600528d30a29027d2
/frameworks/base/core/java/android/view/ViewGroup.java
|
5429e1d1026db8922478b715672e6c0703bbf4a9 |
|
07-Sep-2010 |
Romain Guy <romainguy@google.com> |
Use static final debug fields. Change-Id: I304c39f54f609729bcec581091f285b2baa6fefa
/frameworks/base/core/java/android/view/ViewGroup.java
|
13cc1207fab68adc5c7da0bf3b365196e26a273e |
|
04-Sep-2010 |
Chet Haase <chet@google.com> |
Add ability to enable layout transition animations by default from XML Change-Id: I2b884c83e868f5d22ef85d65ff8ee984633de65e
/frameworks/base/core/java/android/view/ViewGroup.java
|
21cd1389d2ef218b20994b617c57af120841a57f |
|
02-Sep-2010 |
Chet Haase <chet@google.com> |
Add transition effects for layout changes on ViewGroups Change-Id: Ibefcca5692450188fbcec608f3f7e36be1213b21
/frameworks/base/core/java/android/view/ViewGroup.java
|
9b34d45c8f164f1d4c51538f241263dfefc0f22e |
|
02-Sep-2010 |
Romain Guy <romainguy@google.com> |
Correctly apply alpha on TextView. Bug #2969691 Change-Id: Ied46e9a38718cb37df10f9dc79b48fbc3a8bd237
/frameworks/base/core/java/android/view/ViewGroup.java
|
9b073948cfb84c0dd04f8a94ee1f7f263f027c83 |
|
20-Aug-2010 |
Adam Cohen <adamcohen@google.com> |
Cleanup and bug fixes in StackView -> pushed functionality from AdapterViewAnimator to StackView -> only modifying clipping flags as far up the view hierarchy as needed -> still need framework level solution for drawing outside bounds ViewGroup touch dispatch temp fix -> Touch event was being modified and not reset in some code paths. Change-Id: I8135b62e2d73f239b9df407b0fa93bc434796989
/frameworks/base/core/java/android/view/ViewGroup.java
|
816c3be1d7e27ee91ad4e87d39a208dbdc27c8f9 |
|
24-Aug-2010 |
Adam Powell <adamp@google.com> |
Fix some issues with touch event splitting around event timing Change-Id: I15d04d226c218ad7b8a5fe43a55c33c3ade2128d
/frameworks/base/core/java/android/view/ViewGroup.java
|
2b342f0a76f3237e97f15dc2f4e8a0b72dd7c023 |
|
19-Aug-2010 |
Adam Powell <adamp@google.com> |
Allow ViewGroup to split MotionEvents to multiple targets during dispatch. Use the layout xml attribute splitMotionEvents="true" or the ViewGroup method setMotionEventSplittingEnabled(true) to enable motion event splitting. Rules for splitting are as follows: * Splitting is enabled per ViewGroup. When splitting is enabled any MotionEvent dispatched to that ViewGroup can potentially be split into several and dispatched to children independently. * Each pointer is assigned a target child view when the ACTION_DOWN or ACTION_POINTER_DOWN event is received. That will be the pointer's target until it goes up, the target returns false from onTouchEvent, or the MotionEvents are intercepted. * Multiple pointers may be assigned to the same target. All pointer data sent to a target are bundled into a single MotionEvent. Child views do not need to be aware that splitting has occurred. Change-Id: I993f838e2f6b455da9812f4742a016dfcd1c4cc9
/frameworks/base/core/java/android/view/ViewGroup.java
|
ecb1d5ded9afee63735dc91cfb08ada2c639d237 |
|
11-Aug-2010 |
Konstantin Lopyrev <klopyrev@google.com> |
resolved conflicts for merge of f00ee0f7 to master Change-Id: I13b968bde37fad8fffdaa9bb94a0f1da9b2e6e0c
|
bea95162ca25bd00b0479d93739b6283795c3986 |
|
11-Aug-2010 |
Konstantin Lopyrev <klopyrev@google.com> |
Categorizing exported view properties. Change-Id: I79c42019836973d80662c21d195d088ae01537a0
/frameworks/base/core/java/android/view/ViewGroup.java
|
fd2b002bcfca73958233a4e83a737612393e8a16 |
|
06-Aug-2010 |
Chet Haase <chet@google.com> |
Add 3D rotation to View Change-Id: I4aa2542eb821e82d44e13d69b0938de13ffd4f0d
/frameworks/base/core/java/android/view/ViewGroup.java
|
df030d2c160ff42927c58ff54c51049c69a48312 |
|
31-Jul-2010 |
Chet Haase <chet@google.com> |
View x/y properties now feed into matrix translation Change-Id: I35d8953ab6c7a511cdf90f3f94a4a1b5ef549fc3
/frameworks/base/core/java/android/view/ViewGroup.java
|
6e34636749217654f43221885afb7a29bb5ca96a |
|
23-Jul-2010 |
Adam Powell <adamp@google.com> |
Moved context modes into view, renamed to action modes ContextualMode renamed to ActionMode. Adds a reference to the action bar and reduces confusion around things named "Context". Change-Id: Ia5098b1d0799a0ece0810c34e6696eda039fb005
/frameworks/base/core/java/android/view/ViewGroup.java
|
ddc8e713ba345b24240fd16971283449c060a783 |
|
21-Jul-2010 |
Chet Haase <chet@google.com> |
Fix issue with touch MOVE events on transformed containers Change-Id: I17e58f2c6acce606a672756d48d20eb0796b69e8
/frameworks/base/core/java/android/view/ViewGroup.java
|
33e72aef05c75699c9180626dbaa00b06f86ad5b |
|
17-Jul-2010 |
Romain Guy <romainguy@android.com> |
Make View transforms work again. Change-Id: I42aa8b5a55d7584ed242e1cb1f7123a6354edbc8
/frameworks/base/core/java/android/view/ViewGroup.java
|
b5de9f3bafae2c30e7a67faa1cdf7d1c161820c3 |
|
17-Jul-2010 |
Adam Powell <adamp@google.com> |
Fix bug 2845609 - Touch event dispatching problem. Maintain the state of the CANCEL_NEXT_UP_EVENT flag properly. Change-Id: I5ca22409bf8557c486d02806811b10550c5576eb
/frameworks/base/core/java/android/view/ViewGroup.java
|
9bc829cc15757edd149a61868426b214430a1c24 |
|
16-Jul-2010 |
Chet Haase <chet@google.com> |
Fixing view property invalidation issues Change-Id: I51d2c03cabacfc1a7c05073977e7c22d32de7cb3
/frameworks/base/core/java/android/view/ViewGroup.java
|
c3aa361d65119de503224202ae2296dbb1d3cf33 |
|
17-Jun-2010 |
Chet Haase <chet@google.com> |
Add various properties to View to allow it to be moved, scaled, faded, and rotated by property manipulation instead of just Animation operations. Change-Id: Iefab11f243c7511f7bba0e32bd399ed716b9131f
/frameworks/base/core/java/android/view/ViewGroup.java
|
c047b956360a2476793b38d9d3e996fed941af8b |
|
23-Jun-2010 |
Adam Powell <adamp@google.com> |
am bc337d2f: am 73ccafb5: Merge "Fix a bug where requestDisallowInterceptTouchEvent does not get called when scrolling is resumed after stopping a fling." into gingerbread Merge commit 'bc337d2f675e8417be5534439e1b4ed1bc45a9c7' * commit 'bc337d2f675e8417be5534439e1b4ed1bc45a9c7': Fix a bug where requestDisallowInterceptTouchEvent does not get called
|
110486f932510fb49bfeff978b0b0e0237ee0656 |
|
23-Jun-2010 |
Adam Powell <adamp@google.com> |
Fix a bug where requestDisallowInterceptTouchEvent does not get called when scrolling is resumed after stopping a fling. Change-Id: I6796c5082cb81b3116de5baf1f27fe3addb40d00
/frameworks/base/core/java/android/view/ViewGroup.java
|
4846032ac7be7c28c7cfeb3096b8cb656312a382 |
|
11-Jun-2010 |
Chet Haase <chet@google.com> |
Fix bug with layout animations when apps are auto-scaled. The pivot points in RotateAnimation and ScaleAnimation are in pixel coordinates. When an app is being autoscaled, these values are incorrect and should be adjusted for the current scale factor. The fix adds API to Animation to allow ViewGroup to pass in the scaling factor. Change-Id: I978c48f9b5aea6760148435e74e1a8d49e2f785d
/frameworks/base/core/java/android/view/ViewGroup.java
|
2d6145993e19d2bb664766dbaf3c1e9ad3d12cdc |
|
10-Jun-2010 |
Romain Guy <romainguy@google.com> |
Move OpenGL support out of ViewRoot into a new HardwareRenderer class. Change-Id: Iffaed924a5defc3c4df26223c390dc27eee115b1
/frameworks/base/core/java/android/view/ViewGroup.java
|
812ccbeb3ce55c50463fda1d161b2eeed8b19cd2 |
|
01-Jun-2010 |
Romain Guy <romainguy@google.com> |
Add new hardwareAccelerated manifest attribute to enable HW drawing. Change-Id: I2bb0252f3699cb720e7f5b6868419c9904e4fb35
/frameworks/base/core/java/android/view/ViewGroup.java
|
b4bc78b16a05554c57508b488e21dd8eca4e13e6 |
|
13-May-2010 |
Dianne Hackborn <hackbod@google.com> |
Further work on fragments: - Implement all of the state saving and restoring machinery. This caused some flux in the API. - Add ability to have fragments that are retained across activity instances. - Fix some bugs. Change-Id: Ib6b5b0752d7f8d667cfdcd3e76d127cc9b6d901b
/frameworks/base/core/java/android/view/ViewGroup.java
|
203688c6579bc530288642972d1f872a12516dfe |
|
13-May-2010 |
Romain Guy <romainguy@google.com> |
Fix dump of the persistent drawing cache attribute. Change-Id: I351028f6e0858c9ebf7f59bd6cc964925bc3e2b9
/frameworks/base/core/java/android/view/ViewGroup.java
|
3d5f648f8fe61507107b900fc3c4cf79b19572c6 |
|
26-Mar-2010 |
Dirk Dougherty <ddougherty@google.com> |
doc change: cherry pick 75c66da20927e7e854397c00ef1974140270c57f. (clarify fill_parent/match_parent transition in ViewGroup.LayoutParams and R.attr. Mention match_parent in dev guide "declaring layout" doc.) Change-Id: I1d2b80b8dc3f8b2e3c1befcbb7c4c522d78a2db8
/frameworks/base/core/java/android/view/ViewGroup.java
|
75c66da20927e7e854397c00ef1974140270c57f |
|
26-Mar-2010 |
Dirk Dougherty <ddougherty@google.com> |
sdk doc change: clarify fill_parent/match_parent transition in ViewGroup.LayoutParams and R.attr. Mention match_parent in dev guide "declaring layout" doc. Change-Id: I07f6858f78e3b48ccaa99e87d81d18bf0499bdc0
/frameworks/base/core/java/android/view/ViewGroup.java
|
65554f27855ce1764123604b061b10346f8b8404 |
|
23-Mar-2010 |
Romain Guy <romainguy@android.com> |
Improve export to bitmap layers for HierarchyViewer. - Do not show layers with an invisible parent - Correctly draw extras from dispatchDraw() (ListView's dividers for instance) Change-Id: Id2e24ae9d52879290dffbf1cc446c5eda9522fbb
/frameworks/base/core/java/android/view/ViewGroup.java
|
223ff5c0586adbbd1d6d57a3a4d176222e8b7434 |
|
03-Mar-2010 |
Romain Guy <romainguy@android.com> |
Add new CAPTURE_LAYERS command to HiearchyViewer protocol. This command is used by the desktop tool to export a given view hierarchy into a layered file format.
/frameworks/base/core/java/android/view/ViewGroup.java
|
8afa515936e78ccfc5563ca9164dc9a50ca73db4 |
|
26-Feb-2010 |
Romain Guy <romainguy@android.com> |
Send cancel event to recycled views instead of an up. Bug #2309387 This was a problem in lists with list items that would cause notifyDatasetChanged() interleaved with a series of up/down motion events. This is a pretty rare case but it's worth fixing it to avoid getting views in a weird state.
/frameworks/base/core/java/android/view/ViewGroup.java
|
dcc490f20103a4bbd879ea040ce67779d211c2d7 |
|
25-Feb-2010 |
Romain Guy <romainguy@android.com> |
Fix the build.
/frameworks/base/core/java/android/view/ViewGroup.java
|
a440b002aa59e1455bdfa2c5a1ca51c74bbc19ac |
|
25-Feb-2010 |
Romain Guy <romainguy@android.com> |
Prevents ListView items children to modify properties of other children. Bug #2464502 This fix introduce a new dispatch mechanism to tell views when they are temporary detached/reattached from/to a ListView. This is very important to remove pending callbacks or cleanup temporary states. This change also modifies TextView which was relying on that callback in a very particular case: a focused EditText in a ListView. The modified code acts only when in that case, not if onStart/FinishTemporaryDetach() is called via dispatch*() (== recycled views in ListView.)
/frameworks/base/core/java/android/view/ViewGroup.java
|
e36d6e277e49475076b7872d36ea6a5c5b996e9d |
|
18-Feb-2010 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #2263557: PMF3000 showing hybrid of portrait and landscape modes This is a bunch of reworking of how configuration changes are handled: - When orientation is changing (for whatever reason), the window manager no longer tries to pre-emptively compute a new configuration. Instead, it just determines change is happening and tells the window manager. - The activity manager is now responsible for giving the window manager the final configuration it is using. This is both so it knows whem the activity manager is done with its configuration updates, and so the window manager can use the "real" configuration. - When an orientation or other configuration change is happening, freeze the screen and keep it frozen until the activity manager has given us the final configuration. - The window manager can now send new configurations to its clients during its layout pass, as part of a resize, if it has determined that it has changed. This allows for a new View.onConfigurationChanged() API for any view to easily find out when the configuration has changed. - ViewRoot now also works with the activity thread to make sure the process's current resources are updated to the new configuration when it receives one from a window. This ensures that at the time onConfigurationChanged() and other view callbacks are happening, the correct configuration is in force. - There is now a sequence number associated with Configuration, which ActivityThread uses to avoid using stale configurations. This is needed now that it can receive configurations asynchronously from both the window manager and activity manager. - The hack for keeping the locale has been removed, and underlying problem fixed by having Configuration initialize its locale to "unknown" instead of a valid default value.
/frameworks/base/core/java/android/view/ViewGroup.java
|
f5c6eff63d19a9f7a970a4f90619edac873c006d |
|
10-Feb-2010 |
Gilles Debunne <debunne@google.com> |
Force layout on TableRows when column widths are shrinked or streched. Also features some comment typos and import re-ordering. Change-Id: I32cb14419d7d349064032718469daf62a0a72e3a
/frameworks/base/core/java/android/view/ViewGroup.java
|
43c9cdffb619f93d9d4525dffd05701dc9c8c4bf |
|
27-Jan-2010 |
Romain Guy <romainguy@android.com> |
New View.dispatchDisplayHint() API. Bug #2399147 This new API will be used by scrollable containers to tell children that they are/are not displayed. This will allow lists to hide their filter popup window for instance.
/frameworks/base/core/java/android/view/ViewGroup.java
|
bc9fdc92603112b3462024c8d0096b4eca3001c3 |
|
19-Jan-2010 |
Romain Guy <romainguy@android.com> |
Make sure the drawing cache is invalidated when reattaching a view. Bug #2373677
/frameworks/base/core/java/android/view/ViewGroup.java
|
980a938c1c9a6a5791a8240e5a1e6638ab28dc77 |
|
09-Jan-2010 |
Romain Guy <romainguy@android.com> |
Deprecate fill_parent and introduce match_parent. Bug: #2361749.
/frameworks/base/core/java/android/view/ViewGroup.java
|
326d808b858359464b2ffeb84f2e0a8e0c79b600 |
|
10-Dec-2009 |
Adam Powell <adamp@google.com> |
Added View#dispatchViewVisibilityChanged and View#onDispatchVisibilityChanged; updated api; tests Reverted a change to InstrumentationTestCase that would have allowed @UiThreadTest on setUp() methods of tests.
/frameworks/base/core/java/android/view/ViewGroup.java
|
293451e4f005a26386db873f5192f86585cc79bc |
|
04-Nov-2009 |
Romain Guy <romainguy@android.com> |
Remove unused field and add new API to control the children drawing order. Approved by: xav, hackbod, mcleron. Change-Id: I3bbfb4f96e3c9adedbb68d78703059a2df1e2013
/frameworks/base/core/java/android/view/ViewGroup.java
|
fbd8f69a84163ef1cf52b07966320caf448c2bc9 |
|
26-Jun-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1946141. Introduce new caching API to control scaling. This change fixes issues with existing applications that access the drawing cache directly. The API now lets application choose whether they want to get a scaled drawing cache or not. The framework relies on the scaled cache for quality purposes.
/frameworks/base/core/java/android/view/ViewGroup.java
|
cafdea61a85c8f5d0646cc9413a09346c637f43f |
|
12-Jun-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1914574. An NPE could be causes in lists by ViewGroup.dispatchDraw(). ViewGroup was trying to access the AttachInfo without checking whether the info object is null. The object can be null at varioous times in the lifecycle of a list.
/frameworks/base/core/java/android/view/ViewGroup.java
|
8506ab4ac062d0e1ccde136e5e2f4081560e0c11 |
|
12-Jun-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1886237. Views drawing cache was not generated properly. In compatibility mode, a View's drawing cache was created at the 160 density scale instead of the right scale.
/frameworks/base/core/java/android/view/ViewGroup.java
|
ec25df9fbc685be384f8dd764fa224a4d923e9d8 |
|
25-May-2009 |
Romain Guy <romainguy@android.com> |
Fix drawing bug: opaque invalidations should not be taken into account when the invalidated view is animating. Also add the ability to disable the auto-fade on the GestureOverlayView.
/frameworks/base/core/java/android/view/ViewGroup.java
|
d6a463a9f23b3901bf729f2f27a6bb8f78b95248 |
|
22-May-2009 |
Romain Guy <romainguy@android.com> |
Add a new API to ListView: setGestures(int). This allows developers to enable gestures to jump inside the list or filter it. This change also introduces a new XML attribute to control this API. It also adds the ability to theme the GestureOverlayView from the gestures library. Finally, this adds a new VERSION header to the binary format used to store the letters for the recognizer.
/frameworks/base/core/java/android/view/ViewGroup.java
|
75986cf9bc57ef11ad70f36fb77fbbf5d63af6ec |
|
15-May-2009 |
svetoslavganov <svetoslavganov@google.com> |
Accessibility feature - framework changes (replacing 698, 699, 700, 701 and merging with the latest Donut)
/frameworks/base/core/java/android/view/ViewGroup.java
|
5bcdff45bf4ada77ae7c95f520b795876adef75c |
|
15-May-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1846038. The dirty region can sometimes be modified by SurfaceFlinger. When this happens, force the view hierarchy to ignore the dirty flags.
/frameworks/base/core/java/android/view/ViewGroup.java
|
13922e03037d71a538f24ddf61c0b61bb4eb5af0 |
|
13-May-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1836075. Adds consistency checks for the View hierarchy. To enable them, you need a debug build and ViewDebug.sConsistencyCheckEnabled set to true in debug.prop. This change also lets you easily enable drawing and layout profiling in ViewRoot by setting ViewRoot.sProfileDrawing, ViewRoot.sProfileLayout and ViewRoot.sShowFps in debug.prop with a debug build.
/frameworks/base/core/java/android/view/ViewGroup.java
|
24443ea3992e372e47daa50266b0f2ec38cac388 |
|
11-May-2009 |
Romain Guy <romainguy@android.com> |
Fixes #1596240. Optimize invalidate/draw passes by marking opaque views and avoiding drawing them. Whenever a View requests an invalidate its parent check whether the view is opaque or not. When the view is not opaque, the framework behaves as it used to. However, when a view is opaque, the parent marks itself as being dirty because of an opaque view. Its parent then does the same, and so on. When the framework then starts drawing the views, it does not draw views marked as dirty opaque. If a view is dirty opaque and receives an invalidate request from a non-opaque view, it then clears the dirty opaque flag and behaves as before.
/frameworks/base/core/java/android/view/ViewGroup.java
|
8f2d94fd77836dac14319735e40f46b18b04216d |
|
26-Mar-2009 |
Romain Guy <> |
Automated import from //branches/donutburger/...@142820,142820
/frameworks/base/core/java/android/view/ViewGroup.java
|
986003d46add147714ce7e16c9fefa8c18042fc8 |
|
26-Mar-2009 |
Romain Guy <> |
Automated import from //branches/donutburger/...@142790,142790
/frameworks/base/core/java/android/view/ViewGroup.java
|
bb93d5598daa3312318c29401815bddf1df8c4de |
|
25-Mar-2009 |
Romain Guy <> |
Automated import from //branches/donutburger/...@141885,141885
/frameworks/base/core/java/android/view/ViewGroup.java
|
4df2423a947bcd3f024cc3d3a1a315a8dc428598 |
|
05-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@136594
/frameworks/base/core/java/android/view/ViewGroup.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/ViewGroup.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/view/ViewGroup.java
|
3001a035439d8134a7d70d796376d1dfbff3cdcd |
|
19-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@132276
/frameworks/base/core/java/android/view/ViewGroup.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/view/ViewGroup.java
|
f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/core/java/android/view/ViewGroup.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/ViewGroup.java
|