Closed odbol closed 12 months ago
You should only have a single cache pointing at a directory. Generally this type of issue is most likely threading issues by either multiple threads, or multiple client instances.
You should lift your OkHttpClient and Cache up to a singleton.
But if you can give me a set of steps to reproduce the crash, I can try running your Wear app to confirm.
I tried running the app, but even with an API key, it's taking 3 seconds per request and timing out. I'm almost certain, it's just having two clients pointing at the same Cache directory.
You should lift that up to the Application.
Re-open if it is still happening with a single Cache.
Yep, making the cache a singleton worked. Thanks Yuri! (Didn't know you frequented this repo as well haha)
My OkHttp involvement predates Wear :) I'm not stalking Wear developers across the internet.
Similar to https://github.com/square/okhttp/issues/3938 and https://github.com/square/okhttp/issues/6280:
I don't even understand how index could be negative at that point. There seems to be tons of bounds checking happening at all the entrypoints, so perhaps there's some check that is wrong, or the long overflowing into an int or something?
Source code is here: https://github.com/odbol/air-quality-complication/blob/master/app/src/main/java/com/odbol/wear/airquality/purpleair/CachingClient.kt#L61
Happens running on a Pixel Watch 1.