Screenshot scaling

[dkorobtsov]

As per request in: https://github.com/allure-framework/allure-android/issues/40 Adding FailshotRule option to define screenshots size/quality.

Changes summary:

• Default behavior for FailshotRule() stays same.
• If maxWidth is defined, screenshot will be resized to defined width in pixels.
• If scale is defined, screenshot will be rescaled to defined % of original size.
• if both maxWidth and scale are defined, scale will be ignored.
• If quality is defined, screenshot will be saved with defined quality. Default - 90%. Practice shows that it more or less safe to reduce it to 60% without significant quality losses.

Side effect:

• Had to up min sdk version to 18 (Android 4.3 or later)

In local testing did not notice any performance impact, while images with adjusted quality/size consume way less space on Allure Server. Positive side - can keep way more launches before clean up.

[viclovsky]

Hello, @dkorobtsov

Thanks a lot for your PR. Is it possible NOT to increase min sdk version? It definitely will produce problems for users (we know that some of them uses sdk 16: https://github.com/allure-framework/allure-android/issues/42) If not, maybe it is possible to resolve the problem with FailshotRule somehow else?

[dkorobtsov]

@viclovsky Not sure. Will research if it's possible to workaround api level increase. Btw, I afraid that adding proper support for sdk 29 will be breaking change anyway.

[Badya]

I still think that scaling on device might be not the best solution in terms of tests performance. CI/CD can do it easier, faster, batched way with singe line of bash.

[dkorobtsov]

@Badya it depends. I actually just spent some time to measure impact. In my particular case, total test suite execution time with resizing on average is 4.5% faster. Problem is - when tests are executed remotely, for example on Firebase, results first saved from devices external storage to gcloud bucket. It's possible to use bash command to scale all screenshots in batch, but first you need to download those from remote bucket. Scaling on devices makes tests a bit slower, but in the end win is pretty significant. You save on gcloud storage + results download speed.

• I don't see any problem in adding that feature, default behavior stays as is, but if needed - it should be possible to override it. In certain cases it's way more effective. Let users decide :-)