You have to evaluate those same deliverables that are downloaded to the user.
To be able to infer properties of the build application from the source code review, it has to be shown that the two correspond; the shipped, built version comes from the code that was reviewed.
Poring over someone's source code is a fool's errand. You will never catch everything; people find 25 year old bugs in code that have evaded all previous pairs of eyes.
Google's approach here is poor though; they created these API's and permission model and now have to backpedal on it randomly.
If you want untrusted applications to have access to Contacts, it should be done with abstract tokens that do not reveal any contact details. Each contact is represented by an object handle that provides every imaginable operation you might want to do to, with or by-means-of a contact.
It's possible to design a system whereby some contact properties (e.g. mobilePhoneNumber) are accessible, but the result of the access is an abstract object that doesn't actually reveal the content, only represents its existence. The user interface could be priviled so that, say, a text field widget can be given one of these opaque objects, and then display the actual phone number. The only way to get at it would be to have permission to take a screenshot, and then OCR it.