Should one whorldwind#read on main thread?

[oldergod]

Right now, read on a worker thread because we assumed this didn't have to run on the main thread:

whorlwind.read(name)
  .subscribeOn(Schedulers.io())
  .observeOn(AndroidSchedulers.mainThread())
  .subscribe()

On the other hand, we have a lot of crashes for Samsung devices, for it looks like they do stuff that has to run on the main thread:

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
        at android.os.Handler.<init>(Handler.java:200)
        at android.os.Handler.<init>(Handler.java:114)
        at com.samsung.android.camera.iris.SemIrisManager$GetterHandler.<init>(SemIrisManager.java:948)
        at com.samsung.android.camera.iris.SemIrisManager.<init>(SemIrisManager.java:456)
        at com.samsung.android.camera.iris.SemIrisManager.getSemIrisManager(SemIrisManager.java:1898)
        at android.security.keystore.KeymasterUtils.addUserAuthArgs(KeymasterUtils.java:120)
        at android.security.keystore.AndroidKeyStoreKeyPairGeneratorSpi.initialize(AndroidKeyStoreKeyPairGeneratorSpi.java:380)
        at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:669)
        at java.security.KeyPairGenerator.initialize(KeyPairGenerator.java:418)
        at com.squareup.whorlwind.RealWhorlwind.prepareKeyStore(RealWhorlwind.java:143)
        at com.squareup.whorlwind.RealWhorlwind$1.run(RealWhorlwind.java:105)

I'm not sure what's the right path is but

1. Should one, as a consumer of the lib, not need to care about the work whorlwind is doing and run whatever on the main thread? So no crash.
2. If the lib considers its work heavy, should it manage threads internally?
3. What else is there?

[oldergod]

The only version we get those crash is 7.1.1 so maybe they fixed it? Anyway.