First, decide how much time you have to spend on the problem and whether it should be tractable or not.
If it's very urgent, and you can hack around it, hack around it. If it's very urgent and important, hack around it now to unblock and then dig into it deeper later (more in a bit). If it's not urgent, you can treat it as a learning experience and dig in deeper if you want to or not. (Basically make sure you don't fall into a rabbit hole while attempting to solve one specific error and make sure you're achieving what you actually need to).
For digging in deeper (because it's just that important, or maybe you just want to learn): make sure you RTFM, figure out where your understanding of the system and the actual system differ – what did you expect to happen, what's happening and then tweak one thing at a time to make sure things are behaving as you would expect them to till you find the reason. There's a lot I could keep writing about this, and I'm fairly certain much better engineers and authors than me have – an example error would have made this easier.
For Android in particular, we're more lucky than iOS engineers because you have access to the underlying code (for the large part) so you can dig into the android source and even debug the part of the framework that runs within your application.
Of course, sometimes it's just frustration and exhaustion in which case you should follow the advice already posted and just take a fresh look at it the next day.
PS. I haven't completed reading this but https://www.amazon.com/dp/B00PDDKQV2/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1 was recommended to me and has been good so far.
Agan's book on debugging:Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (I like it because it changed how I think about troubleshooting)
Bentley's Programming Pearls (2nd ed) (a short book, I like it because it is short and full of problem framing perspective - reminds me of Alan Kay's quote, "Perspective is worth 80 IQ points.")