Rooted Android: Suspend and warn user when any App accesses Contacts List, Microphone or Camera?

I have Users with rooted Android 2.2+ smartphone devices. Whenever any on-device App accesses the device's Contacts List, Microphone or Camera resource, I want to Suspend that App, pop up a warning message to the User, and let the User decide whether to Abort or Continue.

Even though at App install-time the User might have (blindly) granted those Apps permission to access those Resources.

So, I want to write an Android System Service to continuously scan the File Descriptors (or whatever) representing the Contacts List, Microphone and Camera. If any other application or service/process/thread attempts to open any of the above file descriptors, I suspend it and pop up a Toast message to the User, something like: "Application "CHESS" is trying to access the CAMERA!!! Close the开发者_如何转开发 app, or Continue?";

I could find absolutely nothing on the Android SDK or NDK which would help me achieve my above goal.

Not even a quick-and-dirty-and-dangerous Linux command approach like "./data/lsof -w | grep audio" inserted and run on the device was of any help whatsoever -- I don't know what precise Android resource names to grep for, and moreover the Resources' file descriptors seem to be open all the time whether they are being accessed or not!

Thank you, any advice would be greatly appreciated.

I would agree with the previous posts saying it might not be possible. But if you were deploying your own kernel, then this has a good suggestion thread here: Android Kernel modifying

also this thread here is along similar low level hooking that you want: http://groups.google.com/group/android-developers/browse_thread/thread/821e5a413f0014d9

Here is how to write a driver for android: http://www.kandroid.org/online-pdk/guide/display_drivers.html. Possibly you need to write a driver that is generic and just replaces the existing drivers that you want. that driver would then point to a backed up location of the old drivers, effectively wrapping the old driver. This way you should hopefully keep a generic driver that you write, and the same behavior and nice abstraction the manufacturer drivers provide.