Do not expect Google to implement it anytime soon, due to the massive app breakage potential.
Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis.
On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.
Do not expect Google to implement it anytime soon, due to the massive app breakage potential.
I run AppOps 4.3/4.4 rooted (so I use the "App Ops X" version internally), and I must say, I've restricted most of my non-system apps and I've never seen a single broken app.
I think this potential is vastly overblown.
EDIT: for example, in the official twitter app, I turn off these:
There is almost zero app breakage potential. Because the implementation shouldn't be refusing permissions, it should simply be mocking them. Ask for a location? Mock it to an arbitrary location. Asking for contacts? Return an empty list, or a list with joe.smith@example.org. Etc.
AFAIK, AppOps doesn't do this, it throws a java exception when the app code attempts to use a permission that has been disabled. Depending on how the code is structured, you may or may not have your app break/crash.
This is somewhere where android fragmentation is truly an issue. iOS didn't have granular switchable permissions a couple of versions ago but as the OS moved forward so did the apps.
Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis.
On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.