1. Remove unused modes - makes the class more manageable, and missing
modes can always be readded from the git history.
2. Reuse the existing BlendComposite instances where possible.
3. Fix incorrect alpha computation for multiply mode.
4. Change the alpha computation for all blend modes to compenstate for
the fact that the color filter image that we create extends beyond the
image it is inteded to be applied to.
Change-Id: Iedebf289a23325ee4c6d406dcad46a9edb1855c7
Throw a better error message when resolving a hexadecimal color value
but the user gave a Color State List. The two are easy to confuse since
the only way to distinguish between the two is to look at the
definition.
Bug: http://b.android.com/70110
Change-Id: Ic78962bd0674a92296a0fdd0de184cfe4d85a8e4
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
1. Some dynamic ids weren't created and resulted in ResourceNotFound
exceptions.
2. Prevent NPE if a style attribute (eg. style="?attr/foo"), which
cannot be resolved, is resolved. This effectively, also results in
making it harder to catch misconfigured themes. However, support
library does it, and we don't want to throw errors when the library is
working as intended.
Change-Id: I731d8fb9209eb72b464d235d1072d416e132970b
The tests search for a built sdk using some heuristics. The default path
of the built sdk has changed now, and this updates the search
accordingly.
Change-Id: I36d465d8c5f6cfd971bbdf95878fb144de233c6c
When the tests are run on the build server, they are run from the jar,
as opposed to the extracted build, which is default when run from an
IDE. Thus, when class.getResourceAsStream() is called with ".." in the
path, it is not resolved properly. This change explicitly resolves the
relative path, so that the test is run properly on the server.
Change-Id: Ib5fabd617dca4052220e5173a8bf4fb4234254ff
