RUM-1012 Fix RippleDrawables

[jonathanmos]

What does this PR do?

Fixes RippleDrawables not converting correctly to base64 (caused by it's dimensions being -1, and RippleDrawable not being the actual drawable from which we can create a bitmap). In this fix, the InsetDrawable is extracted from the RippleDrawable, and the GradientDrawable is extracted from that - we then use the dimensions of the view as the dimensions of the drawable (this doesn't affect the created bitmap so much, since the bitmap is rescaled to 10kbs or less before caching).

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[mariusc83]

nice ;)

[mariusc83]

why do you create a new drawable here ? isn't this costly for each view ?

[jonathanmos]

preferably we wouldn't need to do this, however if the drawable is not moved to a new instance before we create the bitmap, then modifying the drawable to draw the bitmap modifies the view in the app itself.

[mariusc83]

ok I see so you need to take a copy ...hmmm...I wonder how expensive this is for each view. Sorry for asking but why do you need to modify the Drawable to create the bitmap from it ?

[jonathanmos]

I need to set the bounds before I can draw to the canvas

[mariusc83]

I'd say that if profiling it shows decent number we can go with this like that. @0xnm, @xgouchet waiting for your thoughts on this one. I searched for a way to go around it, but apparently there's not, the only other way is to setBounds when before drawing and try to put the drawable back into its previous state after. Not sure how reliable this is and honestly I think I would rather go with the copy.

[codecov-commenter]

Codecov Report

Merging #1600 (ffb98cd) into develop (aa1c2e1) will decrease coverage by 0.11%.
Report is 20 commits behind head on develop.
The diff coverage is 73.48%.

@@             Coverage Diff             @@
##           develop    #1600      +/-   ##
===========================================
- Coverage    83.67%   83.55%   -0.11%     
===========================================
  Files          451      452       +1     
  Lines        15563    15625      +62     
  Branches      2318     2321       +3     
===========================================
+ Hits         13021    13055      +34     
- Misses        1928     1948      +20     
- Partials       614      622       +8     

Files Changed	Coverage Δ
...replay/internal/recorder/wrappers/BitmapWrapper.kt	14.29% <17.65%> (-5.71%)	⬇️
...replay/internal/recorder/wrappers/CanvasWrapper.kt	15.79% <23.08%> (+1.50%)	⬆️
...ay/internal/recorder/mapper/BaseWireframeMapper.kt	84.06% <33.33%> (-2.71%)	⬇️
...replay/internal/recorder/wrappers/Base64Wrapper.kt	25.00% <37.50%> (+5.00%)	⬆️
...y/internal/recorder/base64/ImageWireframeHelper.kt	96.70% <89.47%> (-0.77%)	⬇️
...eplay/internal/recorder/base64/Base64Serializer.kt	94.59% <95.92%> (+10.07%)	⬆️
...essionreplay/internal/recorder/LayerDrawableExt.kt	100.00% <100.00%> (ø)
...nreplay/internal/recorder/base64/Base64LRUCache.kt	75.61% <100.00%> (-1.13%)	⬇️
...ssionreplay/internal/recorder/base64/BitmapPool.kt	87.50% <100.00%> (+0.23%)	⬆️
...roid/sessionreplay/internal/utils/DrawableUtils.kt	96.00% <100.00%> (+0.26%)	⬆️

... and 18 files with indirect coverage changes

[xgouchet]

I'm not sure I understand the need to have the ripple drawables converted to base64?
By definition a RippleDrawable is an animated drawable used to show feedback when tapping on interactive views (e.g. buttons).
Saving those as bitmaps means we'll either have to save the whole animation because everytime we draw them the animation state will be different, or it's going to only store a single ripple state which will look weird in the replay.
Either way, should'n we instead save them as a solid background for now, and wait for a better solution to record/replay the ripple effect?