Let me just throw this final thought out there as far as architecture, ViewModel, and android resources goes. Yes, R classes are "pure java". Some are framework specific. And some are application specific. Things like string resources are application specific. When your view model depends on application specific details like resources, it becomes coupled to the application. Not only that, now we have a higher level module depending on low level details which breaks DIP. To fix that, we use an abstraction, we'll call it State, that contains no details. It's just a semantic way of representing some condition. Now both high level and low level modules rely on the same abstraction and DIP is restored.
Then, any interactions between ViewModel and View need to happen elsewhere. Depending on complexity, it can be in some other abstraction or, for simpler applications, right in the view. At that point, we have decoupled both the presentation logic and the details (resources). That ViewModel would work for any application with the same state and data requirements. And when I say state, I'm talking about the "shape" of the data. Not details like actual values.
Not long ago, I was thinking about that stuff and how it ties together with architecture, MVVM, and ViewModel. So I threw together a short blog post on my thoughts. It's just my take on things so your mileage may vary.
https://ntxdroid.com/we-are-in-flight