Hi, Gabor Varadi. Thank you for your comment and sorry, that I could not deliver my thoughts properly for you. I would like to try clarify them in order to avoid different expectations:

1. I don’t try to sold this approach over Dagger DI framework. Yes, personally I don’t much like Dagger, since it is sharpened for Java, not for Kotlin. But still, my main point is to use simple DI container, when you have only couple of screen to present the prototype or MVP of application. Then you can easily change that on Dagger Modules or, for example, Kodein modules.
2. I assume that we as professionals, must solve task and problems by their appearance and try remain a window of flexibility to enhance or completely change our solution. That’s why, I don’t understand, when people starts to import complex libraries at the very beginning of a project. We should delay decisions making on that stuff, until we really need that. That’s we I wrote that Locator approach is good at the beginning. It concise and very simple, but you also remain a window to convert it to dagger module and the split it between components and subcomponents when time will come. This does not mean, that you have to do that. If you 100% know, that you will use fully potential of Dagger, then use it from the beginning. But from my small experience, I’ve saw completely opposite.
3. If I understood you correct, then yes, you can use getSystemService approach, which I wrote at the beginning of article. But the point is not to have absolute minimum amount of strings, but the point is in simplicity. When you have generic way to retrieve services, you can look at creation of it to see all services it will provide, but still you need to remember that every time you calling getSystemService function. When you have each field for its own service, with help of IDE you can easily know, what services you need. It is just more clear, obvioius and thus simple solution. Simple not only in terms of code length but also in terms of usage and maintenance.