I had different responses for the exceptions but then an Android dev
complained that he needed to do some manual checks because of that.
This is more important than any of the answer here.
If you know the audience to whom the API is addressed you should hear them first. If they have different opinions, sit with them and allow them to expose their concerns. It's likely the resulting model will be the one that takes less time to implement for everybody and yet covers the needs for data transfer. If I'm allowed to opinion, I'm sure that teams programming with strong-typed languages will ask for different models. To my experience, to design web APIs thinking in the most constrained or limited client has led me to more consistent and robust APIs. That said, I have to confes that I use to design APIs for mobile apps. However, when I have had to support web applications (SPAs mostly) I have never had problems at all.
It's different when we don't know the audience which could be the case of Stack Exchange API. When we make an API public we are forced to make decisions thinking in the best scenario possible for everybody. Since it's impossible to make happy everybody, whatever we choose is going to be ok as soon as it doesn't make our job harder unnecessarily.
One way or another, it's important to be consistent with the decision. Don't mix up both solutions here and there.
Finally, as @CormacMulhall says, use the HTTP mechanisms to communicate intention, data and errors. Try not ignoring the HTTP semantics either or you will find no value in building Web APIs.