History log of /frameworks/base/core/java/android/widget/ImageView.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
d739d7bd8aa4dc9f12968f21a8faa3544215092b 30-Oct-2014 Alan Viverette <alanv@google.com> Ensure ImageView.setImageResource() always resolves Drawable

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
/frameworks/base/core/java/android/widget/ImageView.java
d5133792391443521dc15f7da7de5d280e6703dd 28-Oct-2014 Alan Viverette <alanv@google.com> Update drawable state after updating tint list

BUG: 18155988
Change-Id: Ic536027a54c10b2082fbc22476530165b76e2c59
/frameworks/base/core/java/android/widget/ImageView.java
f6c763d6a4c84a576ed0ec99b8c22f3550eb39ba 26-Sep-2014 George Mount <mount@google.com> Protect against ImageView changing to a null Drawable during Transition.

Bug 17600191

Change-Id: I5918866dbb6594725f4712a92acdef23003e8f3e
/frameworks/base/core/java/android/widget/ImageView.java
38f93bcb2155d9af821261f4eff5c2d7ba9234e5 16-Sep-2014 Alan Viverette <alanv@google.com> Always apply ImageView's tint attribute using SRC_ATOP by default

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
/frameworks/base/core/java/android/widget/ImageView.java
b56f5d2ab18f881eb075b698e9ce1b4a4a09ff64 15-Sep-2014 Alan Viverette <alanv@google.com> Clean up view drawable tinting methods, fix default modes

Calling setTint now only modifies the tint. It won't force a mode change.

BUG: 17494736
Change-Id: I91392634869ed23981d8e61a403bb2be42aa7a07
/frameworks/base/core/java/android/widget/ImageView.java
a426445dfdab43886dd894f2ba8a1d55bfcbb278 29-Jul-2014 Alan Viverette <alanv@google.com> Separate tint and tintMode properties

BUG: 16054922
Change-Id: I820fb857b671faf9eb27612e470e820c5c4cd6b5
/frameworks/base/core/java/android/widget/ImageView.java
4f64c048505a432e549ccb756634ecebf28f9e80 22-Jul-2014 Alan Viverette <alanv@google.com> Clean up view tinting APIs, tileModeX/Y attribute docs

BUG: 16400590
BUG: 16403307
Change-Id: Ie924815a39eb0e683d1982b08ec478ed3edbfb7b
/frameworks/base/core/java/android/widget/ImageView.java
990205eada00ad3e575761d19607bb03e12f9aa3 24-Jun-2014 George Mount <mount@google.com> Don't use overlay to transition ImageViews.

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
/frameworks/base/core/java/android/widget/ImageView.java
8de1494557cf1d00c1c3fce439138a28de7fbd61 19-Jun-2014 Alan Viverette <alanv@google.com> Fix switch & slider anim, make View drawable hotspot API public

BUG: 15287810
Change-Id: Ic7a9549dc1ba8afd07e9a196371ed349a54aaf2f
/frameworks/base/core/java/android/widget/ImageView.java
911743652b597057a1bd7ef8a921e9ff8dce0f4a 17-Jun-2014 Alan Viverette <alanv@google.com> Add attributes and accessors for tinting View drawables

Also cleans up handling in setters for managed drawables.

BUG: 15391544
Change-Id: Idc08f7eaea0050feb6403566985a6d58185b81f8
/frameworks/base/core/java/android/widget/ImageView.java
cebc6bab51d9c77db8f346c1390169eabac4f27d 14-Jun-2014 Alan Viverette <alanv@google.com> Support hotspots in View drawables

BUG: 15285217
Change-Id: Iad44454fe16ac27ed20b9c17ae2df69649339eed
/frameworks/base/core/java/android/widget/ImageView.java
6dbe51b50e82057af4d29882889444d22ac19c9c 03-Jun-2014 Alan Viverette <alanv@google.com> Clean up drawable theming APIs

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>
/frameworks/base/core/java/android/widget/ImageView.java
52b999f0721b53e9c6e18a4bd664e89aeb65b2d5 25-Mar-2014 Alan Viverette <alanv@google.com> Implement APIs for obtaining, caching themed Drawables

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
/frameworks/base/core/java/android/widget/ImageView.java
8eea3ea5591e59f55cbb4f6b2b7e9363a285ced3 04-Feb-2014 Alan Viverette <alanv@google.com> Add APIs for obtaining themed Drawable from Theme, Context

BUG: 12611005
Change-Id: Ic0057be4e4c2d0c61ce02a019b3f7d0625e3a016
/frameworks/base/core/java/android/widget/ImageView.java
4803bc1ab732323f907260e3eb89e4498bc75739 03-Feb-2014 Alan Viverette <alanv@google.com> Fix ordering of dimension caching during ImageView.setResource()

BUG: 12876148
Change-Id: I8c27546851f491e229a880307d34e1da8e74e6c2
/frameworks/base/core/java/android/widget/ImageView.java
53a470af6574dea27a2701e763e6c6b10be75af7 03-Feb-2014 John Spurlock <jspurlock@google.com> am be878d87: am b6a4926c: am 647db9fa: am 76ecd66a: am 0196e561: Fix typo in ImageView.java

* commit 'be878d8773cc841e5e144a6332c576c650e88126':
Fix typo in ImageView.java
76ecd66a6d5f8ceaebbe9cd109948f01aff4cd27 03-Feb-2014 John Spurlock <jspurlock@google.com> am 0196e561: Fix typo in ImageView.java

* commit '0196e561f280e6cc361442036da277a630e68558':
Fix typo in ImageView.java
0196e561f280e6cc361442036da277a630e68558 03-Feb-2014 John Spurlock <jspurlock@google.com> Fix typo in ImageView.java

Change-Id: Iaa7b020f09c893a5fe006a8523686dd8b9a8f872
/frameworks/base/core/java/android/widget/ImageView.java
e10dd5389407481f49115b74a95cb4333cd1d63d 13-Dec-2013 Alan Viverette <alanv@google.com> Correctly report isOpaque() from ImageView

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
/frameworks/base/core/java/android/widget/ImageView.java
7117c0c184b02d703f2a8612b2d253e44999cbfb 12-Nov-2013 Jeff Brown <jeffbrown@google.com> am 40c81e4a: am 3105b6d2: am 12c32b4d: Merge "Make quick settings show the standard media router icon." into klp-dev

* commit '40c81e4a5d96f8a3853045b289f6131c44d3155d':
Make quick settings show the standard media router icon.
e2126baf72f007d079efcabd45c7a546db34361a 08-Nov-2013 Jeff Brown <jeffbrown@google.com> Make quick settings show the standard media router icon.

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
/frameworks/base/core/java/android/widget/ImageView.java
80da140cc4ce2df529bae92d379ed8598acf356c 08-Oct-2013 Adam Powell <adamp@google.com> am 266b3026: am 20ba658b: am 31049d76: Use SCREEN Xfermode for keyguard badges; update SeekBar

* commit '266b3026c42ed3ba0feedd9abe3e3bb6932c2f23':
Use SCREEN Xfermode for keyguard badges; update SeekBar
31049d76c55b18a6d9993f0d9687598740b16014 07-Oct-2013 Adam Powell <adamp@google.com> Use SCREEN Xfermode for keyguard badges; update SeekBar

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
/frameworks/base/core/java/android/widget/ImageView.java
617feb99a06e7ffb3894e86a286bf30e085f321a 10-Sep-2013 Alan Viverette <alanv@google.com> Add View constructor that supplies a default style resource

Also updates the constructor of every class that extends View.

BUG: 10676369
Change-Id: Ifaf27bf82028d180afa4931c0e906df88d858ac3
/frameworks/base/core/java/android/widget/ImageView.java
3f5a90b2fbba2a83a8a2c5babd5d466a5e0ad2aa 25-Jun-2013 Fabrice Di Meglio <fdimeglio@google.com> Add automatic Drawable mirroring capability when in RTL layout direction

- 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
/frameworks/base/core/java/android/widget/ImageView.java
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/widget/ImageView.java
0931a8516af8284981bb9d584e57cbc3925db4bc 21-Mar-2013 Michael Jurka <mikejurka@google.com> Make hasOverlappingRendering() method more accurate

Bug: 8439502

Change-Id: I80075eddf6abc7999b70e665e692d88b81d5f087
/frameworks/base/core/java/android/widget/ImageView.java
5370405db2a4413e8fd3e57d2e6664a65bbd514b 31-Jan-2013 Romain Guy <romainguy@google.com> Return a copy of the read-only identity Matrix

An app trying to modify the returned matrix (despite what the
documentation says...) would crash when the matrix is identity.

Change-Id: I8aae06b712907085088fb9f0321352dd2c3462ac
/frameworks/base/core/java/android/widget/ImageView.java
96c2a83cd7bcb2d01338fa29849d5ac42d0cd088 09-Jan-2013 Dake Gu <dake@google.com> am 05d48504: am af6dd103: Merge "fix ImageView.getImageMatrix()" into jb-mr1-aah-dev

* commit '05d485044bc4607759e2b4ca5188858bceb120f8':
fix ImageView.getImageMatrix()
1ee60179bbc06823e1e0f6557ea6afdad0c3db4d 04-Jan-2013 Dake Gu <dake@google.com> fix ImageView.getImageMatrix()

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
/frameworks/base/core/java/android/widget/ImageView.java
2c8cc972c3b03b76a80db517dde1e68895bbdd66 08-Dec-2012 Adam Powell <adamp@google.com> Update documentation to mention compatibility versioning

Mention changes involving MeasureSpec/RelativeLayout/ImageView
behavior changes when apps target SDK > 17.

Change-Id: I232492a76ac048f7b460d28a87bd84cbbec4e4d7
/frameworks/base/core/java/android/widget/ImageView.java
7da4b73a236b7c72d1337696949df7a00776dd06 08-Dec-2012 Adam Powell <adamp@google.com> Compatibility measurement hacks when targetSdkVersion <= JB-MR1

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
/frameworks/base/core/java/android/widget/ImageView.java
3614394c85da011c2899f2a8877573186707e7e4 03-Dec-2012 Romain Guy <romainguy@google.com> Close InputStream after we're done reading from it
External bug #40837

Change-Id: Ic7f3fefb7aabf4d006f9928b6f67d1263f039487
/frameworks/base/core/java/android/widget/ImageView.java
946d05b95f849684b709a3750ef189388d6dc5a9 02-Oct-2012 Adam Powell <adamp@google.com> DO NOT MERGE - Revert fixes for ImageView/MeasureSpec/RelativeLayout

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.
/frameworks/base/core/java/android/widget/ImageView.java
d5edc7721791ad807b9a8fbd923b8d6e73c399cc 27-Sep-2012 Adam Powell <adamp@google.com> Fix adjustViewBounds handling for ImageView

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
/frameworks/base/core/java/android/widget/ImageView.java
68f3eb3b56fcdefa65b2a624af8eda3595f98beb 28-Sep-2012 Adam Powell <adamp@google.com> Revert "Fix adjustViewBounds handling for ImageView"

This reverts commit b1271ac183c36d0e9e3a524bec8908ed5aab9a45

Revert this for now pending further investigation of bug 7248600

Change-Id: Ieb0a279fa2208f2aa575759dd6dd94476b471b8d
/frameworks/base/core/java/android/widget/ImageView.java
b1271ac183c36d0e9e3a524bec8908ed5aab9a45 27-Sep-2012 Adam Powell <adamp@google.com> Fix adjustViewBounds handling for ImageView

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
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.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/widget/ImageView.java
f96ce0261326d1637e0111eaddde725ed94f2163 10-Aug-2012 Adam Powell <adamp@google.com> Some simple skip-layout optimizations for ImageView

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
/frameworks/base/core/java/android/widget/ImageView.java
b03b434089cf2106c467b2827a65e5c589c91d01 04-Jun-2012 Fabrice Di Meglio <fdimeglio@google.com> Revert "Revert "Clean up layout direction APIs for Drawable""

This reverts commit c96132ff53e5c26f5b0170edd85072006fb2bc70
/frameworks/base/core/java/android/widget/ImageView.java
c96132ff53e5c26f5b0170edd85072006fb2bc70 02-Jun-2012 Jean-Baptiste Queru <jbq@google.com> Revert "Clean up layout direction APIs for Drawable"

This reverts commit c1da65187a4b9de8f72bd617ef937030187c0a92.
/frameworks/base/core/java/android/widget/ImageView.java
c1da65187a4b9de8f72bd617ef937030187c0a92 01-Jun-2012 Fabrice Di Meglio <fdimeglio@google.com> Clean up layout direction APIs for Drawable

- see bug #6427629

Change-Id: I3119db3022bba0ee325b6d0d4471bfebd850ec10
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.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/widget/ImageView.java
db8c9a6a4d9bf8c39f834b25611926caf21380f6 22-Mar-2012 Chet Haase <chet@google.com> Optimization of alpha with DisplayList properties

Some views (such as ImageView and TextView) handle non-opaque alpha
values directly. This was originally an optimization, but we can handle it faster
in many cases without this optimization when DisplayList properties are enabled.
Basically, if a view has non-overlapping rendering, we set the alpha value directly
on the renderer (the equivalent of setting it on the Paint object) and draw each
primitive with that alpha value. Doing it this way avoids re-creating DisplayLists
while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties.

Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
/frameworks/base/core/java/android/widget/ImageView.java
aac722a9c0d199c79ae8ce2dd3cce113f01c30b7 26-Mar-2012 Philip Milne <pmilne@google.com> Fixes for bugs: 6104423, 6103563, 6103509, 6103807 & 6103253.

Add properties to Java API so as to better mirror the framework's XML API.

I'm not familiar with many of these areas so this CL is worth some scrutiny.

Change-Id: Iff63c43521305efaad5a2189c1b5556d2353cbd4
/frameworks/base/core/java/android/widget/ImageView.java
06e1ec6462763a2f12ba5fb1c1c826bf393bfacd 10-Mar-2012 Fabrice Di Meglio <fdimeglio@google.com> Make Drawable RTL APIs public

- also optimize imports

Change-Id: I2649a539a5784293d09179981a5d57e900219246
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.java
b241b4c6ab8dc6174375b6f18f83e04f569b299f 11-Nov-2011 Adam Powell <adamp@google.com> Make the overridden ImageView#setVisibility remotable

Change-Id: Idaf061ea8c2a06ec8abaf74cf865446d9092afa2
/frameworks/base/core/java/android/widget/ImageView.java
6a939ae6fd7d130a3dc9b011877eac4e280c0546 10-Nov-2011 Adam Powell <adamp@google.com> Fix access modifiers on ImageView overrides

Change-Id: I64cc10c877ac4adc4b79abcd7c7617480bd82906
/frameworks/base/core/java/android/widget/ImageView.java
37419d7321e71edb179faa0eafd2a2acf12b62c1 10-Nov-2011 Adam Powell <adamp@google.com> Fix bug 5581874 - Animated drawables don't start as expected

Fix a bug that caused animated drawables to not schedule properly when
a view has not yet been attached. Also make ImageViews update their
drawable visibility state properly, which will handle scheduling
concerns as ImageViews are attached and detached from their windows.

This should also fix the bug where animated notification icons in the
status bar do not animate until the posting app posts an update to the
notification.

Change-Id: I24c403182831258d1f251736e920c9efe1d38299
/frameworks/base/core/java/android/widget/ImageView.java
ba1fe8e3cfcf029a9bbd9bc7575e2b5c4f4ad8b0 15-Oct-2011 Chet Haase <chet@google.com> Issue 5432115: Speed up notification scrolling

The NotificationPanel was using views that had non-1 alpha
values set on them (permanently). This is costly in the GL
implementation and caused more rendering overhead, and worse
performance, than simple opaque views would.

The fix is to set the text color and ImageView drawable alpha
directly, without setting the View alpha property.

Change-Id: I381e0bd45bf45784b8e364a27a339e6583189a43
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.java
9e648c44dee1e86e7839292feac9d49b3f3c8ce4 18-Aug-2011 Romain Guy <romainguy@google.com> Invoke requestLayout() when drawables have different sizes.
Bug #5142668

Change-Id: I0d3ae27984e69394e64b8aa0623bc3d6b22bc629
/frameworks/base/core/java/android/widget/ImageView.java
2a0e99da03ae85d18c9f35913e7dd04b94c1cf41 04-Aug-2011 Adam Powell <adamp@google.com> Fix bug 5118908 - ImageView.setImageDrawable always requests layout

Make ImageView a bit more conservative about when it requests a
layout. This improves performance for ListViews where apps
asynchronously load images and replace placeholders outside of the
optimized getView path.

Change-Id: I564a4a343ab9c8c2d5baf907b5f573b5ee02c87a
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.java
c0053223bedf33581b0830fb87be32c1f26e5372 13-Jun-2011 Fabrice Di Meglio <fdimeglio@google.com> Add View.getResolvedLayoutDirection()

- update Callback2 interface
- update Gravity.getAbsoluteGravity() and Gravity.apply() to be more generic
by changing "boolean isRtl" parameter to "int layoutDirection"
- fix BiDiTests for RTL FrameLayout

Change-Id: I97bb456c22d5fd3ecb34f08564ce4dbed37e7459
/frameworks/base/core/java/android/widget/ImageView.java
a98eef8601dfd280f56f7a51495ecd4127eefbb2 27-May-2011 Fabrice Di Meglio <fdimeglio@google.com> Fix overrides of isLayoutRtl(Drawable dr)

Change-Id: I7042805747db134d93e39cbb41773d8d5a1cb370
/frameworks/base/core/java/android/widget/ImageView.java
6a03640539405afbdefe72894759281b98aa6e6f 23-May-2011 Fabrice Di Meglio <fdimeglio@google.com> Add support for Gravity BEFORE and AFTER

- update layouts
- add Callback2 for RTL aware Drawable
- add unit tests

Change-Id: Ic64d0291e262170aff7297c6580b0b422eaa8d89
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.java
189ee18d6c6483ad63cc864267328259e2e00b95 03-Dec-2010 Dianne Hackborn <hackbod@google.com> Implement smarter sizing of WRAP_CONTENT windows.

This extends the view hierarchy's measure pass to allow view to
propagate up to their parent additional information besides just
their measured size. They can now report that their measured width
and/or height should be larger than the size their parent is
limiting them to (even though by definition they need to contrain
their reported measurements to the limits imposed by the parent).

ViewRoot uses this information to determine if it should remeasure
the window with a larger size limit to try to make it fit.

Change-Id: I90af3b7a8ec45d0a5c003fb009857025209d83eb
/frameworks/base/core/java/android/widget/ImageView.java
fd52b18d9bf3cd62c7a07058536e9f97db65beea 11-Nov-2010 Joe Onorato <joeo@google.com> The beginnings of the new status bar.

There is a lot of rough stuff still, but most of the functionality is here again.

Change-Id: I4b1241e61270f1434e798481afa83634233ee670
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.java
e5ebcb0107a939395e03592fd44c746cd09e311d 15-Oct-2010 Romain Guy <romainguy@google.com> Fix clipping issue in StackView.

Change-Id: I7ec28f25c3993a2bd7ef6399ba1923839d239905
/frameworks/base/core/java/android/widget/ImageView.java
c6b0b7755c7932136c3bcdadfb56657f1f611465 27-Aug-2010 Brad Fitzpatrick <bradfitz@android.com> Document blocking behavior of ImageView setImageURI and setImageResource

Change-Id: I3b0633321229cad80ebf32e052c0db170a56de21
/frameworks/base/core/java/android/widget/ImageView.java
b4938201bad1050a5e3821d60ea43e71861cc733 16-Mar-2010 Romain Guy <romainguy@android.com> Round up ImageView translations to avoid nasty surprises.
Bug #2499812

Change-Id: If90acb7e13aa30e5a0a4e73782d033a5bb4e3264
/frameworks/base/core/java/android/widget/ImageView.java
42c79880b0c19dfbcd8589d89d35fcedb1a7c9da 02-Mar-2010 Romain Guy <romainguy@android.com> Apply alpha animations on ImageView instances.
Bug #2479570
/frameworks/base/core/java/android/widget/ImageView.java
2b95c2413838c2e2b127ebab8fb4fead7d52e460 09-Feb-2010 Jeff Sharkey <jsharkey@android.com> Added more @RemotableViewMethod methods, mutate ImageView.

Catch some View methods missed during the first pass of
marking with @RemotableViewMethod annotation. Also adds new
ImageView.setColorFilter(int) to match the android:tint XML
attribute.

When ImageView touches ColorFilter or alpha, mutate the
underlying Drawable. Fix NPE in StateListDrawable.mutate().
/frameworks/base/core/java/android/widget/ImageView.java
9d8d9c22bb98e656cb2e42673c4ba801821c4e5d 06-Jan-2010 Bjorn Bringert <bringert@android.com> Get correct density info when using resource URIs in ImageView

Before, when an android.resource URI was passed to
ImageView.setImageURI(), it was loaded through an InputStream.
This didn't get the density information correctly.

Instead, we use Resources to load the Drawable, which fixes
the denisty problem.

Change-Id: Ie8427ea04da43f414b49014d012671fc0aa27a30
/frameworks/base/core/java/android/widget/ImageView.java
0f8555b72861b7b9a233ab65b14055c98b145c91 27-Nov-2009 Bjorn Bringert <bringert@android.com> Allow resource and file URIs in ImageView.setImageURI()

Before, if you passed an android.resource URI, e.g.
"android.resource://com.android.browser/2130837550"
to ImageView.setImageURI(), it failed with:

I/System.out( 1730): resolveUri failed on bad bitmap uri: android.resource://com.android.browser/2130837550

This change allows android.resource: and file: URIs in addition to the
existing support for content: URIs.

Fixes: http://b/issue?id=2289441

Change-Id: I98819b183c29eb60a70708d373d2199cdc0ea017
/frameworks/base/core/java/android/widget/ImageView.java
f88872655e85570f3b9bfebe78647ed36916b3f4 30-Jul-2009 Chih-Chung Chang <chihchung@google.com> Fix a bug in ImageView: The drawing matrix is not updated when setImageMatrix is called.

The drawing matrix used in onDraw() is mDrawMatrix, but in setImageMatrix()
only mMatrix is updated. We need to call configureBounds() to update
mDrawMatrix if it was null. The is found in bug 2023281.
/frameworks/base/core/java/android/widget/ImageView.java
11ea33471e1a14a8594f0b2cd012d86340dd3bd8 23-Jul-2009 Dianne Hackborn <hackbod@google.com> Allow for screen density drawables in compatibility mode.

This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.

This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).

As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.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/widget/ImageView.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/widget/ImageView.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/widget/ImageView.java
076357b8567458d4b6dfdcf839ef751634cd2bfb 03-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@132589
/frameworks/base/core/java/android/widget/ImageView.java
3dec7d563a2f3e1eb967ce2054a00b6620e3558c 03-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@137055
/frameworks/base/core/java/android/widget/ImageView.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/widget/ImageView.java
da996f390e17e16f2dfa60e972e7ebc4f868f37e 13-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@131421
/frameworks/base/core/java/android/widget/ImageView.java
54b6cfa9a9e5b861a9930af873580d6dc20f773c 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/frameworks/base/core/java/android/widget/ImageView.java