Before it used to output the violations all one one line. Now it looks
like:
```
MozillaStrictModeSuppression:
'import mozilla.components.support.ktx.android.os.resetAfter' at
(17,1) in /StrictModeManager.kt
Please use `components.strictMode.resetAfter` instead because it has
performance improvements and additional code to monitor for performance
regressions.
MozillaStrictModeSuppression:
'setThreadPolicy(threadPolicy.build())' at (56,24) in
/StrictModeManager.kt
Please use `components.strictMode.resetAfter` instead because it has
performance improvements and additional code to monitor for performance
regressions.
MozillaStrictModeSuppression:
'setVmPolicy(builder.build())' at (71,24) in /StrictModeManager.kt
NOT YET IMPLEMENTED: please consult the perf team about
implementing`StrictModeManager.resetAfter`: we want to understand the
performance implications of suppressing setVmPolicy before allowing it.
```
This is more correct, faster, and results in less copy-paste duplication
than the current behavior:
homeScreen { }.dismissOnboarding()
Which opens settings to dismiss onboarding.
set save button state by calling invalidateOptionsMenu, causing onPrepareOptionsMenu to be called which will enable/disable the save button depending on if changes have been made or not
detekt still passes after I make this change.
afaik, there isn't a good reason not to run it on unit tests and it can
be valuable to add custom rules for them. Also, detekt is already
running on our androidTest directory.
Currently, push-apk fails to verify its chain of trust if github tagging
is done before it runs. Until this is fixed, we need to make sure
tagging is blocked on pushing.
In a followup PR, we need to add state to strictModeManager (the
number of suppressions). This is much simpler to do when this is defined
as a class rather than an object. However, when this is defined as a
class, `resetAfter` needs access to the strictModeManager. Instead of
passing it in as an argument, it made sense to move this function onto
the strictModeManager instead.
Since folks are used to calling:
```
StrictMode.ThreadPolicy.allowThreadDiskReads().resetAfter
```
We're going to have to add a lint check to prevent them from doing that.
I originally tried to create this PR leaving this as an object to keep
the change simple but it wasn't worth it - once the object started to
keep state, we'd need to manually reset the state between runs. Also,
the tests were already getting hacky with static mocking so it was
easier to address some of those issues this way too.