StrictMode Violations

[GPryan]

We have the following StrictMode settings:

StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
    .detectDiskReads()
    .detectDiskWrites()
    .detectNetwork()
    .penaltyLog()
    .penaltyDeath()
    .build()
)

• File Explorer, Shared Preferences, and Screen Recorder all violate the detectDiskReads() policy
• Screen Recorder also violates the detectDiskWrites() policy

[ToxicBakery]

Those aren't violations they are detections. All of these write to disk and read from disk, they have to.

Implement Hyperion as one of your build variants that does not enable detections on the main thread.

[GPryan]

Thanks @ToxicBakery , unfortunately that's not an option for us. It's still a possibility though that this library could be updated to do disk IO on a thread other than the main thread, is that right?

[ToxicBakery]

Looking at it more closely, not really. These plugins are meant to be used in dev and shifting everything to background threads isn't all that trivial. For instance, even attempting to load the plugins is a disk read violation if the thread policy is set in the application class. To support this requirement, a lot of rework would need to be done in the plugins that violate strict mode moving everything to a worker queue style implementation such as with pools or RX neither of which brings many benefits to end users and would impose requirements down on other 3rd party plugins that likely also do not concern themselves with disk reads/writes.

I understand the goals for using strict mode; however, Hyperion isn't meant to be shipped to production and StrictMode isn't meant to be law. StrictMode's only goal is to help you find potential problems. I would recommend you remove penaltyDeath() as that's rather excessive.

Lastly, why is a build variant not an option for you? This isn't the first time that claim has come up but I can't come up with a situation that would make variants not an option.