summaryrefslogtreecommitdiffstats
path: root/core/java/android/widget/ImageView.java
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused imports in frameworks/base.John Spurlock2015-02-281-1/+0
| | | | Change-Id: I031443de83f93eb57a98863001826671b18f3b17
* Add @ResourceInt annotations on APIsTor Norbye2015-02-181-1/+2
| | | | Change-Id: I119cc059c2f8bd98fd585fc84ac2b1b7d5892a08
* Add @Nullable to AttributeSet in a couple constructorsScott Kennedy2015-02-101-3/+4
| | | | Change-Id: I184113680c5dc867b353df81961e93523b91bbc5
* First quick implementation of auto assist data.Dianne Hackborn2015-02-061-11/+2
| | | | | | | | | | | | | | Introduce new AssistData class that contains all data the framework automatically generates for assist. Currently populated with a very simple tree structure representing the app's view hierarchy. Reworked how we populate the class name for accessibility info, so this is provided through a new method call on View that subclasses can override. This method is also used to populate the class name in AssistData. Change-Id: Ibd0acdc8354727d4291473283b5e4b70894905dc
* Fix accessibility delegationAlan Viverette2015-01-071-6/+9
| | | | | | | | | | | | | | | Ensures that delegate code is run last. Previously, calling the super method from an accessibility delegate set on a widget would only run code in the widget's parent. Next, the delegate code would run. Finally, the widget's code would run. As a result, the widget code would override any data supplied by the delegate. By moving all overridden code to internal methods, we ensure that the call chain for super includes the widget's parent code followed by the widget's code. The delegate code will always run last. BUG: 17641433 Change-Id: Ib9d403156c1fc4fb04f65f3c126d1277a44b3740
* Ensure ImageView.setImageResource() always resolves DrawableAlan Viverette2014-10-291-11/+11
| | | | | | | | Fixes no-op on method call after configuration change at the expense of removing a micro-optimization that wasn't really needed. BUG: 18178233 Change-Id: I36eccf91b138e4bed34be96d9b87200edeb66938
* Update drawable state after updating tint listAlan Viverette2014-10-291-0/+7
| | | | | BUG: 18155988 Change-Id: Ic536027a54c10b2082fbc22476530165b76e2c59
* Protect against ImageView changing to a null Drawable during Transition.George Mount2014-10-071-0/+3
| | | | | | Bug 17600191 Change-Id: I5918866dbb6594725f4712a92acdef23003e8f3e
* Always apply ImageView's tint attribute using SRC_ATOP by defaultAlan Viverette2014-09-151-5/+4
| | | | | | | | Preserves pre-L behavior and avoids requiring developers to manually set the tintMode to SRC_ATOP when targeting SDK 21+. BUG: 17507827 Change-Id: I43f86cbcb9662172254f46700441ca85a54428f6
* Clean up view drawable tinting methods, fix default modesAlan Viverette2014-09-141-14/+31
| | | | | | | Calling setTint now only modifies the tint. It won't force a mode change. BUG: 17494736 Change-Id: I91392634869ed23981d8e61a403bb2be42aa7a07
* Separate tint and tintMode propertiesAlan Viverette2014-08-061-18/+19
| | | | | BUG: 16054922 Change-Id: I820fb857b671faf9eb27612e470e820c5c4cd6b5
* Clean up view tinting APIs, tileModeX/Y attribute docsAlan Viverette2014-07-221-30/+14
| | | | | | BUG: 16400590 BUG: 16403307 Change-Id: Ie924815a39eb0e683d1982b08ec478ed3edbfb7b
* Don't use overlay to transition ImageViews.George Mount2014-06-251-0/+14
| | | | | | | | | | | Bug 15744992 MoveImage used an overlay to transition ImageViews. This caused strange problems when ImageViews were contained in other Views. The new ChangeImageTransform does a smooth transition for changes in scale type and bounds. Change-Id: Ia5021f4828f8f818a8699b3bdd38437aeba1cfc8
* Fix switch & slider anim, make View drawable hotspot API publicAlan Viverette2014-06-181-4/+2
| | | | | BUG: 15287810 Change-Id: Ic7a9549dc1ba8afd07e9a196371ed349a54aaf2f
* Add attributes and accessors for tinting View drawablesAlan Viverette2014-06-171-10/+112
| | | | | | | Also cleans up handling in setters for managed drawables. BUG: 15391544 Change-Id: Idc08f7eaea0050feb6403566985a6d58185b81f8
* Support hotspots in View drawablesAlan Viverette2014-06-131-1/+11
| | | | | BUG: 15285217 Change-Id: Iad44454fe16ac27ed20b9c17ae2df69649339eed
* Clean up drawable theming APIsAlan Viverette2014-06-021-1/+1
| | | | | | | | | | Removes APIs for themed creation of a drawable from a stream, since that doesn't involve any inflation. Also cleans up tinting methods left over from previous clean up. BUG: 15089957 Change-Id: I2af7aa9a6d351ae61b33ee1216c674fae1bffe11 Signed-off-by: Alan Viverette <alanv@google.com>
* Implement APIs for obtaining, caching themed DrawablesAlan Viverette2014-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When Drawables are inflated during preload (or otherwise without a theme) they cache their themeable attributes in their constant state as an array keyed on attribute index. Drawables inflated with a theme will simply resolve theme attributes as part of normal inflation, and they will not cache any themeable attributes. Drawables obtained from Resources are pulled from theme-specific cache when possible. If an unthemed Drawable exists in the preload cache, a new constant state will be obtained for the Drawable and the theme will be applied by resolving the cached themeable attributes and overwriting their respective constant state properties. If no cached version exists, a new Drawable is inflated against the desired theme. Constant states from themed drawables may be cached if the applied theme is "pure" and was loaded from a style resource without any subsequent modifications. This CL does not handle applying themes to several Drawable types, but it fully supports BitmapDrawable, GradientDrawable, NinePatchDrawable, ColorDrawable, and TouchFeedbackDrawable. BUG: 12611005 Change-Id: I4e794fbb62f7a371715f4ebdf946ee5f9a5ad1c9
* Add APIs for obtaining themed Drawable from Theme, ContextAlan Viverette2014-02-031-2/+2
| | | | | BUG: 12611005 Change-Id: Ic0057be4e4c2d0c61ce02a019b3f7d0625e3a016
* Fix ordering of dimension caching during ImageView.setResource()Alan Viverette2014-02-031-3/+3
| | | | | BUG: 12876148 Change-Id: I8c27546851f491e229a880307d34e1da8e74e6c2
* am be878d87: am b6a4926c: am 647db9fa: am 76ecd66a: am 0196e561: Fix typo in ↵John Spurlock2014-02-031-1/+1
|\ | | | | | | | | | | | | ImageView.java * commit 'be878d8773cc841e5e144a6332c576c650e88126': Fix typo in ImageView.java
| * am 0196e561: Fix typo in ImageView.javaJohn Spurlock2014-02-031-1/+1
| |\ | | | | | | | | | | | | * commit '0196e561f280e6cc361442036da277a630e68558': Fix typo in ImageView.java
| | * Fix typo in ImageView.javaJohn Spurlock2014-02-031-1/+1
| | | | | | | | | | | | Change-Id: Iaa7b020f09c893a5fe006a8523686dd8b9a8f872
* | | Correctly report isOpaque() from ImageViewAlan Viverette2013-12-121-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | Includes special handling for attributes that can affect the image's drawing opacity and bounds, e.g. xfermode, alpha, and matrix transform. BUG: 12120109 Change-Id: Ieeec11ff35af899c4e6fcf6364633c15ec94241e
* | | am 40c81e4a: am 3105b6d2: am 12c32b4d: Merge "Make quick settings show the ↵Jeff Brown2013-11-111-0/+1
|\ \ \ | |/ / | | | | | | | | | | | | | | | standard media router icon." into klp-dev * commit '40c81e4a5d96f8a3853045b289f6131c44d3155d': Make quick settings show the standard media router icon.
| * | Make quick settings show the standard media router icon.Jeff Brown2013-11-091-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | Fixed a bug in ImageView where we failed to inform a newly updated Drawable about the visibility state. This caused AnimationDrawables to not animate when attached to an existing ImageView *unless* that ImageView happened to be attached to the window *later* or have its visibility toggled for some other reason. Bug: 11257292 Change-Id: Iba9e0db5ba0db2b022950aec0c6f60a435da8ad2
* | am 266b3026: am 20ba658b: am 31049d76: Use SCREEN Xfermode for keyguard ↵Adam Powell2013-10-071-0/+15
|\ \ | |/ | | | | | | | | | | badges; update SeekBar * commit '266b3026c42ed3ba0feedd9abe3e3bb6932c2f23': Use SCREEN Xfermode for keyguard badges; update SeekBar
| * Use SCREEN Xfermode for keyguard badges; update SeekBarAdam Powell2013-10-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Plumb through the necessary API features through Drawables and ImageView but leave it hidden for now pending future API review and plumbing through the rest of the framework Drawable implementations. Update SeekBar assets used for keyguard transport control. Set selected status directly instead of finding views by id. Bug 10531608 Bug 10784913 Change-Id: Ia38bd04ad1bc26e9e6da1dda8a374c9ba3ceccb3
* | Add View constructor that supplies a default style resourceAlan Viverette2013-09-091-4/+9
|/ | | | | | | Also updates the constructor of every class that extends View. BUG: 10676369 Change-Id: Ifaf27bf82028d180afa4931c0e906df88d858ac3
* Add automatic Drawable mirroring capability when in RTL layout directionFabrice Di Meglio2013-08-011-0/+9
| | | | | | | | | | | | | | - default value is "no mirroring" - introduce android:autoMirrored as a new attribute for Drawable, BitmapDrawable, LayerDrawable, StateListDrawable and NinePatchDrawable - setting android:autoMirrored="true" means that the drawable will be mirrored when the layout direction is RTL (right-to-left) - also fix an issue with ImageView drawable layout direction not updated correctly when RTL properties were changed See bug #7034321 Need Drawable RTL support Change-Id: If595ee5106c786f38e786d3a032e182f784a9d97
* API and doc cleanup, plus small animation/UI featuresChet Haase2013-04-121-1/+1
| | | | | | | | | 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
* Make hasOverlappingRendering() method more accurateMichael Jurka2013-03-211-1/+1
| | | | | Bug: 8439502 Change-Id: I80075eddf6abc7999b70e665e692d88b81d5f087
* Return a copy of the read-only identity MatrixRomain Guy2013-01-301-4/+5
| | | | | | | An app trying to modify the returned matrix (despite what the documentation says...) would crash when the matrix is identity. Change-Id: I8aae06b712907085088fb9f0321352dd2c3462ac
* am 05d48504: am af6dd103: Merge "fix ImageView.getImageMatrix()" into ↵Dake Gu2013-01-091-1/+4
|\ | | | | | | | | | | | | jb-mr1-aah-dev * commit '05d485044bc4607759e2b4ca5188858bceb120f8': fix ImageView.getImageMatrix()
| * fix ImageView.getImageMatrix()Dake Gu2013-01-031-1/+4
| | | | | | | | | | | | | | | | | | getImageMatrix() does not return "mDrawMatrix", instead it returns mMatrix. This is not reflecting the matrix used in drawing when Bitmap is changed and mDrawMatrix is set to null while mMatrix still holds old invalid data. Change-Id: If24c3118068eca70cfe15786f9715d95c4499f3b
| * DO NOT MERGE - Revert fixes for ImageView/MeasureSpec/RelativeLayoutAdam Powell2012-10-011-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MeasureSpec.makeMeasureSpec has a bug where a negative or very large size parameter will cause the resulting MeasureSpec value to overflow. RelativeLayout partially relies on this when measuring children with mode UNSPECIFIED; a default value of -1 in a local variable ends up being passed to makeMeasureSpec, overflowing a mode value to create a measurespec that is very large in size, with AT_MOST as the mode. The correct behavior is for RelativeLayout to propagate the UNSPECIFIED mode. Unfortunately a number of custom view implementations in apps rely on the buggy behavior as they do not implement their own onMeasure method. This makes them fall back to View's default onMeasure implementation, which accepts the spec's size unconditionally for AT_MOST or EXACTLY modes, but falls back on getSuggestedMinimum[Width|Height] for UNSPECIFIED. If the view had no background drawable with dimensions and no minWidth field set, this fix for RelativeLayout causes some views to measure with a size of 0 rather than a size of the 30-bit version of 0xFF... Revert these fixes in the interests of compatibility. The next version will conditionally use the new behavior if targetSdk > JB-MR1. This also required reverting a fix for ImageView's adjustViewBounds functionality, as it cannot be implemented reliably if this RelativeLayout fix is not also in place. Revert "Fix UNSPECIFIED measurement in RelativeLayout" This reverts commit 132a742b94b9716451ddef30cec20548b346f1b9. Revert "Fix adjustViewBounds handling for ImageView" This reverts commit d5edc7721791ad807b9a8fbd923b8d6e73c399cc.
* | Update documentation to mention compatibility versioningAdam Powell2012-12-101-1/+8
| | | | | | | | | | | | | | Mention changes involving MeasureSpec/RelativeLayout/ImageView behavior changes when apps target SDK > 17. Change-Id: I232492a76ac048f7b460d28a87bd84cbbec4e4d7
* | Compatibility measurement hacks when targetSdkVersion <= JB-MR1Adam Powell2012-12-071-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All three of these are interrelated! * Allow broken MeasureSpec values. The long-standing implementation of MeasureSpec.makeMeasureSpec has been to add both values rather than masking/or-ing the values together. Some old code relied on this, such as if it mixed up size/mode params. * Disable ImageView adjustViewBounds allowing the view to grow beyond its initial size. A bug in RelativeLayout in the presence of the above MeasureSpec fix causes this not to work properly in apps. * Allow RelativeLayout to send overflowed/bogus MeasureSpec values when measured with MeasureSpec.UNSPECIFIED mode. Some apps have custom child views that do not properly handle UNSPECIFIED measurements, but the exact overflow semantics caused this to generate AT_MOST $REALLYBIG MeasureSpecs for those views instead if they were placed inside a RelativeLayout in a scrolling container. Change-Id: I977a5f1ba5637f0cba3d26a70139e2bcd021fc9c
* | Close InputStream after we're done reading from itRomain Guy2012-12-031-6/+16
|/ | | | | | External bug #40837 Change-Id: Ic7f3fefb7aabf4d006f9928b6f67d1263f039487
* Fix adjustViewBounds handling for ImageViewAdam Powell2012-09-281-0/+13
| | | | | | | | | | | | | | When computing the adjusted view bounds, don't constrain the dimensions by the original estimate if the opposite dimension has a fixed size. This can result in the view never getting properly enlarged. Also fix a long-standing bug in MeasureSpec.makeMeasureSpec where oversized or negative values could result in broken packed values. Bug 7240251 Change-Id: I359d108ff52b6f3b5c4bf393d2271d28999c0127
* Revert "Fix adjustViewBounds handling for ImageView"Adam Powell2012-09-271-2/+0
| | | | | | | | This reverts commit b1271ac183c36d0e9e3a524bec8908ed5aab9a45 Revert this for now pending further investigation of bug 7248600 Change-Id: Ieb0a279fa2208f2aa575759dd6dd94476b471b8d
* Fix adjustViewBounds handling for ImageViewAdam Powell2012-09-261-0/+2
| | | | | | | | | | When computing the adjusted view bounds, don't constrain the dimensions by the original estimate. This can result in the view never getting properly enlarged. Bug 7240251 Change-Id: I44fc017f8b661121f0042fcd59a4efde70be6bbe
* Fix bug #6427629 Clean up layout direction APIsFabrice Di Meglio2012-09-231-1/+1
| | | | | | - rename getResolvedLayoutDirection() to getLayoutDirection() Change-Id: I3afe56c0db0751952f5056c23893cb7455531d29
* Fix bug #6427629 Clean up layout direction APIsFabrice Di Meglio2012-09-231-1/+1
| | | | | | | | | | | - 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
* Some simple skip-layout optimizations for ImageViewAdam Powell2012-08-091-4/+18
| | | | | | | | | | Mirror the optimization from setImageDrawable into setImageResource and setImageURI where we won't requestLayout() if the drawable's size didn't change. Bug 6359116 Change-Id: Iaae2100f3bddb2737628e31483b471c9e22d945f
* Revert "Revert "Clean up layout direction APIs for Drawable""Fabrice Di Meglio2012-06-041-6/+1
| | | This reverts commit c96132ff53e5c26f5b0170edd85072006fb2bc70
* Revert "Clean up layout direction APIs for Drawable"Jean-Baptiste Queru2012-06-021-1/+6
| | | | This reverts commit c1da65187a4b9de8f72bd617ef937030187c0a92.
* Clean up layout direction APIs for DrawableFabrice Di Meglio2012-06-011-6/+1
| | | | | | - see bug #6427629 Change-Id: I3119db3022bba0ee325b6d0d4471bfebd850ec10
* Remove USE_DISPLAY_LIST_PROPERTIES flagChet Haase2012-04-231-19/+1
| | | | | | | | | | | | | | | | 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
* Accessibility focus - frameworkSvetoslav Ganov2012-04-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.1 at 2024-08-12 14:00:15 +0000