23e282d297193655ce5a4b716312f0a985b27d50 |
|
20-Apr-2016 |
Oren Blasberg <orenb@google.com> |
Accommodate NaN in new context menu methods. Bug: 28296401 Change-Id: I0ae6067e1ae01c342c1b39d6f64db5dcd02492d5
/frameworks/base/core/java/android/view/ViewParent.java
|
2af189a0a7962501b808cd50499d978a7cd10d81 |
|
06-Feb-2016 |
Adam Powell <adamp@google.com> |
Preserve compatibility for ViewGroup#showContextMenuForChild Have the new showContextMenuForChild(View, float, float) call through to the old showContextMenuForChild(View) before recursing up to its parent. This ensures that existing apps with custom views that override the old method still get called as expected if they implement custom behavior. Unlike some other similar circumstances we aren't implementing this to be bidirectional as the new behavior doesn't need to be triggered by invoking the old. If the older method is invoked explicitly we will still show old-style dialog context menus instead of the newer popup style since we won't have a good place to visually anchor a popup. Bug 26919262 Change-Id: Ie09f922d322b5a24789c7867820c4bc43824c385 (cherry picked from commit 759a4c54004af6ac9f42c9c42496a5eb73c461ff)
/frameworks/base/core/java/android/view/ViewParent.java
|
d62d5e9accc76952d737f9c58a97f898807713e5 |
|
20-Jan-2016 |
Yigit Boyar <yboyar@google.com> |
Fix requestRectangleOnScreen This CL fixes a bug in View#requestRectangleOnScreen where the position was not being moved from child's coordinate space to the parent's coordinate space properly. I've also added more documentation to clarify the API. Bug: 25787435 Change-Id: Id821fa178e04016f6fb830d0bd2abde046581465
/frameworks/base/core/java/android/view/ViewParent.java
|
4610eeff9c6c4789705b6550a57333150d39e970 |
|
03-Dec-2015 |
Chet Haase <chet@google.com> |
Revert "Add support for partial view layouts" This reverts commit c55d5072ac52cee1811b52406419228fa81119ce. There were several bugs related to incorrect handling of various layout issues (layout not being run on containers/views that needed it), reverting to take another run at it outside of master. Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
/frameworks/base/core/java/android/view/ViewParent.java
|
021627eb5875372dea57ba91fa782fffbfbbc559 |
|
25-Nov-2015 |
Alan Viverette <alanv@google.com> |
Ensure only one context menu is shown at a time Refactors the menu helper classes. Both classes now implement a common MenuHelper interface, which eliminates the need to keep separate helpers on PhoneWindow and unifies the DecorView showContextMenuForChild() implementations. We now explicitly dismiss any previously shown context menu before showing a new context menu. Previously we relied on the modal nature of the dialog context menu to prevent multiple menus from being opened at once, but this is no longer reliable with popup context menus. Bug: 25656520 Change-Id: Idab3daa6d6888f803f2e33660fe1dd488e4c28d1
/frameworks/base/core/java/android/view/ViewParent.java
|
c55d5072ac52cee1811b52406419228fa81119ce |
|
19-Dec-2014 |
Adam Powell <adamp@google.com> |
Add support for partial view layouts Traditionally, when a view called requestLayout it would force recursive requestLayout calls for all parent views up the hierarchy. This meant that there was no way to determine at traversal time whether a parent view itself needed layout, or if just one of its descendants did. Add a ViewParent method requestPartialLayoutForChild(View). This lets a caller state that a particular child of a given parent needs a remeasure and relayout at its current measured size and position within that parent. This can help prevent the full-tree relayout often caused by otherwise trivial changes. Partial layouts are processed after any pending "full" relayout during ViewRoot traversals, but before drawing. Add a ViewGroup method requestLayoutForChild(View). This lets a ViewGroup decide whether it is more appropriate to request a traditional relayout or a partial layout for itself or just the child that changed. Add a ViewParent method findDependentLayoutAxes. This allows a caller to check if the ViewParent's layout is dependent on a specific direct child view along one or both axes. Called recursively, this can be used to determine if a change in a child view can be isolated to a partial layout, even if its direct parent's own layout is tied to its other ancestors. (e.g. MATCH_PARENT, LinearLayout weights) Implement ViewGroup#requestPartialLayoutForChild to call new ViewParent method findDependentLayoutAxes and based on the result, either request a full layout for itself or a partial layout for the child in question. Implement findDependentLayoutAxes for common framework ViewGroups. A private implementation in ViewGroup is available for use by framework classes that will deal with basic LayoutParams. These implementations specifically check for derived LayoutParams classes and abort the optimization if they find something beyond their expected parameter types. Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
/frameworks/base/core/java/android/view/ViewParent.java
|
ed3912692f0ba8a647d795462e20fcdb67adbacb |
|
01-Sep-2015 |
Oren Blasberg <orenb@google.com> |
Make context menus show as popup menus. This means that right-clicking/long pressing on a view that is registered for context menu will show the context menu as a popup menu instead. Bug: 20016398 Change-Id: I96fea60435fff2f981d288521f490f8ff24ada15
/frameworks/base/core/java/android/view/ViewParent.java
|
4423d91de5300d3fd318bf5bc2d4d7e5bb856abf |
|
02-Mar-2015 |
Clara Bayarri <clarabayarri@google.com> |
Add a type parameter to startActionMode() calls. This requires adding a new method to View and Window.Callback to pass down the type as a parameter. For compatibility purposes, the new method implementations keep the type and call the old method, in case clients have subclassed it. Change-Id: If5d857f131e33be8cc6a8814f2e9c4e85ad2da25
/frameworks/base/core/java/android/view/ViewParent.java
|
b6ab098bad4b126eaaaa3aaa5a512fefc4e0749b |
|
08-Jan-2015 |
Adam Powell <adamp@google.com> |
Add API for nested pre-processing of a11y events; fix ResolverDrawerLayout Add API for handling nested pre-processing of accessibility events similar to nested pre-scroll or pre-fling. This allows custom views to delegate a nested scroll to a parent via the accessibility system. Use this functionality to allow opening the ResolverDrawerLayout via accessibility commands. Bug 18827274 Change-Id: Icd5a502605b78a861bb03e7b11923841a72eb9ab
/frameworks/base/core/java/android/view/ViewParent.java
|
b72be59a6a5ca5fae3ede2470f1662598098b666 |
|
17-Jul-2014 |
Adam Powell <adamp@google.com> |
Add nested pre-fling for nested scrolling Nested pre-fling allows a nested scrolling parent to consume a fling operation before the child view does. If a parent has been consuming nested pre-scroll events in a particular direction, this is generally a good indication that it should also consume the resulting fling at the end. Bug 15538504 Change-Id: I88e8753a96c9b41815c3be530cafab8345164e64
/frameworks/base/core/java/android/view/ViewParent.java
|
b36e4f944fe28ce68182f9ec91e5341866b49084 |
|
01-May-2014 |
Adam Powell <adamp@google.com> |
Add support for hiding action bars on scroll. Also tweak the nested scrolling API around nested flings and fix a bug where recursive nested scrolling would stop prematurely. Change-Id: I561226db878b2493970440a6af3e2332c56a1913
/frameworks/base/core/java/android/view/ViewParent.java
|
10ba27734ee6274a772be8d6b1faa703ee3a3d6b |
|
15-Apr-2014 |
Adam Powell <adamp@google.com> |
Nested scrolling! or, "Excuse me, Egon, you said crossing the streams was bad." Add API for driving a nested scroll from the most deeply nested applicable scrolling view. The deepest scrolling view dispatches high-level scrolling events up to cooperative parent views. Augment ScrollView to support nested scrolling. Next up, more public framework scrolling views. Change-Id: I53b5e207fcdece796e08c8592ddb4496b96f600e
/frameworks/base/core/java/android/view/ViewParent.java
|
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/ViewParent.java
|
e8222dddaf2e3da14380101e818d4254899e0c0d |
|
05-Sep-2013 |
Chet Haase <chet@google.com> |
Change build version from KEY_LIME_PIE to KITKAT Issue #10631619 Change build version to KitKat Change-Id: I6ad13f6169ad74204078d36929479998b498ad8b
/frameworks/base/core/java/android/view/ViewParent.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/ViewParent.java
|
0da4a282eec40364d54f9e658632c5aab85142b7 |
|
26-Aug-2013 |
Adam Powell <adamp@google.com> |
Expand documentation around ViewParent#childHasTransientStateChanged Bug 10461020 Change-Id: Id27df5de171b01effae949bcb1ce69bd4101b5ee
/frameworks/base/core/java/android/view/ViewParent.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/ViewParent.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/ViewParent.java
|
0187a5d424c8618709b8f11dd7200caa0178c40e |
|
23-Apr-2013 |
Chet Haase <chet@google.com> |
Document behavior and usage of ViewGroup.bringChildToFront() A call to ViewGroup.bringChildToFront() or View.bringToFront() (which delegates to the parent's bringChildToFront() method) needs to be followed by a call to requestLayout() and invalidate() on the parent container in order for the changes to actually happen. That is, the order of the child views would change, but the parent container would not run layout or even invalidation without being told to, so there would be no visible change until something else caused a layout and invalidation to occur. This change clarifies this requirement in the javadocs. Issue #8667065 bringtoTop does not work Change-Id: Ibe41a6318dddf9fb79382e1c9fd1d21ab4510976
/frameworks/base/core/java/android/view/ViewParent.java
|
9dd4c5c6867f8b6de19096d2d68365dccb744c19 |
|
09-Feb-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7381967 Add RTL APIs to ViewParent - add RTL apis to ViewParent - remove awful and performance bottleneck casts in View during LayoutDirection, TextDirection and TextAlignment resolutions. Change-Id: I92a56b16382e13c28c1dad35f6f205620eb01bfe
/frameworks/base/core/java/android/view/ViewParent.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/ViewParent.java
|
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/ViewParent.java
|
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/ViewParent.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/ViewParent.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/ViewParent.java
|
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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.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/ViewParent.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/view/ViewParent.java
|