These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
Bug: 154628299
Test: ColorStateListDrawableTest, DefaultFocusHighlightTest
The system needs this to show keyboard focus. Apps may want to do
something for keyboard focus, and they may also want to write custom
drawables that handle keyboard focus. Making this API public allows them
to do this.
Change-Id: Id6b2df3a14f15db5b7f8ca664362be0b78c3e2c4
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I4bc8c9482e4bb1af21363f951affff7ee3fefeab
Added null checks around usages of drawable child layers
within the constructor as well as the isProjected method
Test: Added cts tests to LayerDrawableTest
Bug: 134902243
Change-Id: I94a5fbc896ab53e29f4db4dcd04daf0bf9dd66dc
variants
Updated various framework Views to have equivalent BlendMode APIs
to replace the deprecated PorterDuff equivalents.
Updated InspectableProperty annotations to refer to the same
xml attributes as the original tintmode APIs
Bug: 126726419
Test: Added CTS tests to verify new BlendMode APIs
Change-Id: Id9ab36d3d4d29f351250723e9d13d49bc6062c83
Merged-In: Id9ab36d3d4d29f351250723e9d13d49bc6062c83
Updated various framework APIs to leverage the new BlendMode API
that parallels the corresponding porterduff mode equivalent.
Added new Drawable#onApplyBlendMode API that provides a backward
compatible solution for Drawable implementations that leverage
the new BlendMode API as well as fall back on the traditional
setTintMode(PorterDuff.Mode) API for instances where it is not
implemented
Bug:126726419
Test: Re-ran CTS graphics test cases
Change-Id: I119a7f57dce0a095c0a73cf83dc50b82beff5e32
For packages:
android.graphics
android.graphics.drawable
android.graphics.drawable.shapes
android.graphics.fonts
android.graphics.pdf
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I7fc1162d2c63df8751a4660607e8ce72070efed8
Also warns when LayerDrawable is created with an invalid child. This
is not guaranteed to fail, but it's usually a bad sign.
Bug: 33124798
Test: LayerDrawableTest, DrawableContainerTest
Change-Id: Ie3e4200b27a9814cee7f5711d7df9710db513953
This reverts commit 1eda069f7c.
Reason to revert:
The setup wizard started throwing android.view.InflateException due to
I89f6d804fb025f426aefdee67559778cf03015bb. Temporarily reverting that
change until we figure out what is going on.
Change-Id: I9344a3402f2fab02f4fe49a6a8ad91970b2d3b3e
Test: Manually verified that the setup wizard no longer crashes.
Bug: 33124798
Bug: 36870685
A View uses a Drawable as its background, which changes
its appearance according to the View's state. This commit
adds an algorithm to detect undefined state_focused in
state specs for those Drawables.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsGraphicsTestCases
-t android.graphics.drawable.cts.DefaultFocusHighlightTest
Bug: 35096940
Change-Id: I5e9f07141679881fe88f9040aa116ea2f9d537c9
Some initial cleanup before making changes to either class.
Test: n/a, refactoring only
Bug: 33124798
Change-Id: Idf0328bcc6de72b694ca7b35122ecad845cf1c4b
NOTE: Linear blending is currently disabled in this CL as the
feature is still a work in progress
Android currently performs all blending (any kind of linear math
on colors really) on gamma-encoded colors. Since Android assumes
that the default color space is sRGB, all bitmaps and colors
are encoded with the sRGB Opto-Electronic Conversion Function
(OECF, which can be approximated with a power function). Since
the power curve is not linear, our linear math is incorrect.
The result is that we generate colors that tend to be too dark;
this affects blending but also anti-aliasing, gradients, blurs,
etc.
The solution is to convert gamma-encoded colors back to linear
space before doing any math on them, using the sRGB Electo-Optical
Conversion Function (EOCF). This is achieved in different
ways in different parts of the pipeline:
- Using hardware conversions when sampling from OpenGL textures
or writing into OpenGL frame buffers
- Using software conversion functions, to translate app-supplied
colors to and from sRGB
- Using Skia's color spaces
Any type of processing on colors must roughly ollow these steps:
[sRGB input]->EOCF->[linear data]->[processing]->OECF->[sRGB output]
For the sRGB color space, the conversion functions are defined as
follows:
OECF(linear) :=
linear <= 0.0031308 ? linear * 12.92 : (pow(linear, 1/2.4) * 1.055) - 0.055
EOCF(srgb) :=
srgb <= 0.04045 ? srgb / 12.92 : pow((srgb + 0.055) / 1.055, 2.4)
The EOCF is simply the reciprocal of the OECF.
While it is highly recommended to use the exact sRGB conversion
functions everywhere possible, it is sometimes useful or beneficial
to rely on approximations:
- pow(x,2.2) and pow(x,1/2.2)
- x^2 and sqrt(x)
The latter is particularly useful in fragment shaders (for instance
to apply dithering in sRGB space), especially if the sqrt() can be
replaced with an inversesqrt().
Here is a fairly exhaustive list of modifications implemented
in this CL:
- Set TARGET_ENABLE_LINEAR_BLENDING := false in BoardConfig.mk
to disable linear blending. This is only for GLES 2.0 GPUs
with no hardware sRGB support. This flag is currently assumed
to be false (see note above)
- sRGB writes are disabled when entering a functor (WebView).
This will need to be fixed at some point
- Skia bitmaps are created with the sRGB color space
- Bitmaps using a 565 config are expanded to 888
- Linear blending is disabled when entering a functor
- External textures are not properly sampled (see below)
- Gradients are interpolated in linear space
- Texture-based dithering was replaced with analytical dithering
- Dithering is done in the quantization color space, which is
why we must do EOCF(OECF(color)+dither)
- Text is now gamma corrected differently depending on the luminance
of the source pixel. The asumption is that a bright pixel will be
blended on a dark background and the other way around. The source
alpha is gamma corrected to thicken dark on bright and thin
bright on dark to match the intended design of fonts. This also
matches the behavior of popular design/drawing applications
- Removed the asset atlas. It did not contain anything useful and
could not be sampled in sRGB without a yet-to-be-defined GL
extension
- The last column of color matrices is converted to linear space
because its value are added to linear colors
Missing features:
- Resource qualifier?
- Regeneration of goldeng images for automated tests
- Handle alpha8/grey8 properly
- Disable sRGB write for layers with external textures
Test: Manual testing while work in progress
Bug: 29940137
Change-Id: I6a07b15ab49b554377cd33a36b6d9971a15e9a0b
Previously we would skip setting the changing configurations and callback
if the drawable had been loaded post-inflation from a theme attribute.
Bug: 30756548
Change-Id: Ia5457723ae8a62506a7562299d3fe78ec21f8030
Collect child invalidations during layer bounds change, then dispatch a
single invalidation if any children requested invalidation. This prevents
re-entrance from, for example, a LayerDrawable.updateLayerBounds() call
invoking setBounds() on a child, which necessarily calls invalidateSelf()
and immediately propagates up to ImageView.invalidateDrawable(), which
then calls configureBounds() and puts us back in updateLayerBounds().
Bug: 28636072
Change-Id: I36c9eefc18904d493292d51b37e4b05cfddcf794
Previously we were using native config flags in some places that expected
Java flags, and vice-versa. All usages of config flags are now annotated
to ensure we're using the right type.
Cleans up annotations on most methods that were touched.
Bug: 21161798
Change-Id: Ifd87dfb12199fc8258915d8a510e03ddb681ca89
Uses consistent naming and ordering for padding and inset calculations.
Updates documentation to include UNDEFINED_INSET as public API, since we
return the value and will accept the value as a valid param. Flattens
out RTL logic for readability.
Change-Id: Ie704e2e5fc7f5763500ebe1217ddbbf4d0c5ef86
If a child drawable has no intrinsic width or height, don't attempt to
apply padding and insets to the child during the parent layer drawable's
intrinsic width and height calculations.
Bug: 25461370
Change-Id: Idf616bde0449231f38156da53feb858e1ae41c47
Avoid NPE if mutate() is called on a LayerDrawable with a child that
doesn't support constant state.
Bug: 25438651
Change-Id: I6bf5a90484fda44a7b5fd10ce7b798eaa799b68e
Refactors density resolution and offset/size scaling into static
helper methods.
Also fixes VectorDrawbale insets to be treated as offset-type pixels
rather than size-type.
Bug: 25081461
Change-Id: I10fcb9ebb6c67f853a27ca0ee008c31af4b85da0
This allows us to run fine-grained level animations.
Backwards compatibility:
Another CL will add DrawableCompat.setLevel(float) to forward calls to
the existing integer-based method. For callbacks, developers can override
onLevelChanged(int) and use DrawableCompat.getLevelFloat() to obtain the
floating-point level. Overriding onLevelChanged(float) will only work on
current API.
Bug: 23566299
Change-Id: I431fe6f3679c8f23f9cf3c2bb1f92a4059ee68e3
Also clears DrawableContainer's futures list when it's no longer needed,
correctly sets deep copy of state set in StateListDrawable, makes some
private methods into package-protected to avoid thunk, and propagates
state to StateListDrawable's super class so that getState() has correct
information.
Bug: 21840003
Change-Id: I0d4232807f280d663c03b4a80e4aab8626806440
The developer used to be responsible for this and automatically
propagating the values breaks some use cases (ex. in Camera).
Bug: 20696311
Change-Id: Ia8ddc132c6d629bcc27d66f654baf30d9f078568
Addresses a regression in Calendar where a custom drawable that doesn't
implement intrinsic bounds is laid out incorrectly. Also fixes an issue
where ColorDrawable would be laid out incorrectly.
Bug: 20643614
Change-Id: I796f0d3e189e482cf6fa169a5dd13f654d72653c
Adds explicit padding attributes to LayerDrawable, constrains the ripple
to fit within the container to avoid projection.
Bug: 19359934
Bug: 20083467
Change-Id: I46da941fba37552adeb2c1fe617b799f576df0c6
Ensures changing configurations mask is propagated to the host drawable
so that it can be properly cleared from cache on configuration changes.
Also fixes constant state handling of the mask in the Inset and Rotate
drawables.
Hides new ColorStateList methods related to theming, since they should
only be used during preloading or internally by framework drawables.
Fixes bug where the cached versions of themeable ColorStateLists were
modified by calling applyTheme() on the host drawable.
Also cleans up some docs and naming in GradientDrawable.
Bug: 19966397
Change-Id: I8c8d3cabbaf94b488c2b8fe9fd423e07d824c19c
Always update layer bounds if the contained drawable changed in any
way. Also adds null annotations in LayerDrawable and throws a more
useful exception when the layers argument is null.
Change-Id: Iae0cba68257e48b6a45fe081c3d4b0509d2dedd5
Ensures LayerDrawable copies out the correct layer properties during
"tileification". This really needs to be deprecated or replaced in a
future CL, though, because it is potentially lossy (e.g. for
RippleDrawable, which is an instanceof LayerDrawable).
Bug: 19448441
Change-Id: I483e9c34fd781e280c13eb5951f96bc71a252819
Fixes several issues with constant state and propagation of drawable
property changes to wrapped drawables. Also un-hides the layout
direction accessors and hotspot getter.
Change-Id: Iff19db6a95059cbcfcbde7af0ac33871ccd41615
