-
Notifications
You must be signed in to change notification settings - Fork 1.3k
StrictMode.resetPoliciesAfter – strict number of checks, and add performance team as code owners for the file #13959
Comments
We don't use penalty death for the VM policy so we theoretically don't need to disable this check if penalty death is enabled.
Additional branching introduces complexity so we should avoid it when possible. This branch was also unused so it's more likely to have bugs if we tried to use it after some refactor.
…plicating functionality.
…nabled; fix tests. I don't like the implicit dependencies from using `object` but making this a `class`/Component makes it inconvenient to access. If we continue to add functionality like this, we should consider switching its access pattern.
…er in certain build modes.
…er in certain build modes.
…tMode. I had to drop a commit that addressed the issue because it was too hard to fix.
We don't use penalty death for the VM policy so we theoretically don't need to disable this check if penalty death is enabled.
Additional branching introduces complexity so we should avoid it when possible. This branch was also unused so it's more likely to have bugs if we tried to use it after some refactor.
I had to drop a commit that addressed the issue because it was too hard to fix.
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.
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.
The `context` member function returns null in attachBaseContext so we need to use the Context that's being attached instead.
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.
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.
This is more correct, faster, and results in less copy-paste duplication than the current behavior: homeScreen { }.dismissOnboarding() Which opens settings to dismiss onboarding.
…uppression count.
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.
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. ```
Running locally, I get the same error: I think that there legitimately was an reduction in the number of StrictMode suppressions on start up.
This is more correct, faster, and results in less copy-paste duplication than the current behavior: homeScreen { }.dismissOnboarding() Which opens settings to dismiss onboarding.
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. ```
Running locally, I get the same error: I think that there legitimately was an reduction in the number of StrictMode suppressions on start up.
Addressed in #15570 |
I think this causes the app to crash when changing orientation with the following log:
the problem seemingly stemming from components.core.engine.profiler?.addMarker(..) |
Thanks. I confirmed that I see the same behavior so I opened https://github.com/mozilla-mobile/fenix/issues/15751 |
There are currently two versions
We want to restrict the number of calls to these methods to prevent regressions.
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: