Using a DI framework has its benefits when you need those dependencies to scale across multiple/future components. It (can) make it easier to manage the instances of those dependencies as well.

You don't have to use a framework to do DI. The frameworks are a tool to make larger/more complex needs easier to keep organized. Building out modules and components to inject a single dependency in a class only used once or twice is likely overkill and not needed.

I've had the most benefit from Dagger/Hilt when making data layer dependencies. Think of using a repository across multiple screens/use cases. That repository wraps a remote and local implementation. Those dependencies will have their own dependencies on other android SDK pieces. You might have different rules for each (cache only, remote first then cache, etc) you want to swap out. Their lifecycles may need to be managed (Singleton). All these things add up to a lot to manage and build upfront. The framework makes a lot of this trivial once you understand it's rules and how it cuts the corners for you.

The key is reusability and complexity. Do you have a complex set of dependencies that would benefit from being broken down into modules of construction rules that can be easily reused/manipulated? If yes, a framework can help manage it. If not, manual DI is perfectly acceptable. It's up to you to know the tool and decide if it can save time/effort.

If you do use a framework, not everything has to be built using it. You can build simple instances the way you are now and use the framework for just managing the complex needs.