Senor Gruber has uncovered a trick inside Google’s Mobile app that uses an undocumented method to access the iPhones proximity sensor. In normal situations, the iPhone proximity sensor – the little thing in the top of the iPhone that knows when you have it up to your face – can be turned on or off. When it’s on and you place the phone up to your ear the screen stops responding. When it’s off, the sensor does nothing. This is key because no information is passed during this on or off toggle. There is no way to tell if the proximity sensor has been triggered.
Google, however, used a secret call, proximityStateChanged. This call can tell if the proximity sensor has been tripped. This mean the app can sense upward motion to your ear and then wait for input when it’s next to your ear. Why is this important? It’s not in any documented feature set and Google is essentially violating the Terms of Use. Will they get in trouble and was this why the Google app was held back? There’s no telling. Gruber posits:
1. Whoever at Apple approved this Google Mobile update did not realize that it was using the private proximyStateChanged method.
2. Whoever at Apple approved it knew that it used a private API, but approved it anyway.
3. Google sought and obtained permission from Apple to use this method.
We all know Apple wouldn’t allow Google to use an unsupported call. It’s not in their DNA. So 1 and 2 are obvious culprits and probably why the app was held back.
Note: Erica Sadun also told Gruber that she, too, is an SDK pirate:
Based on some of the email I’ve gotten this morning, I think the occasional use of undocumented methods in public iPhone frameworks is actually pretty common in third-party iPhone apps.
Obviously this matters little to us, the mere mortals. But that Google can change the rules while Apple lets it get away with it is an unnerving prospect for developers. There is enough arbitrary secrecy in the iPhone app process and adding a little more doesn’t make things more exciting – it makes app developers look elsewhere.
Normally the iPhone knows when it’s near your face by using the Force. Since Google lacks a Jedi Master like Emperor Steve we had to let them use a secret call.
Whoa, I’m having trouble figuring out the conclusion that this is Google changing the rules and not Apple. Google is at fault in only one of your three imagined scenarios.
For those of us who haven’t developed an iPhone app– are undisclosed (but operable) api calls discovered by essentially “throwing the kitchen sink” of different queries at the interface and figuring out what works? I’m curious how one discovers these, and what sort faith you could even have that the call would continue to be accepted on behalf of your app. Couldn’t apple cripple the feature (for google) by no longer permitting the viability of that call from them?
You basically read the strings in a library to find undocumented calls.
I don’t see how this is a big deal – as you mentioned: many people have used undocumented APIs in their apps. Having someone mainstream like Google use it may encourage Apple to release more documented APIs. Surely that would be a good thing?
I don’t understand. Maybe since I haven’t delved into the iPhone development framework I may be unqualified to ask this question, but I’m going to ask it anyways since I do plenty of other development outside the iPhone.
If the proximity sensor can be turned on, and movement can be tested, why couldn’t Google have just said that when the phone senses movement, turn the proximity sensor on for X amount of seconds, and then turn it back off when audio-input stops or isn’t found? You’ll notice that if you just move your phone in your hand then cover the sensor it goes into “listen” mode so its simply the sequence of move-then-cover.
I also see how Google could have used these private APIs, but just was curious why it’s not feasible that they just simply turn on the proximity sensor after sensing movement?
Actually you never mentioned in this entire article why I should care (as your TC title declared I would). How does accessing proximityStateChanged violate my privacy or anything that I would care about in any way?
If the iphone platform is not an even playing field, developers may look elsewhere (Android?) and you might not have as many cool iphone apps to choose from. It’s 3:00 AM here, and when I saw the title of this post I thought it was saying that the Google app secretly uses GPS and reports your location to the mothership. I need some sleep.
Daaaammmnnn, it must be a slow news day. Figured you guys would try and manufacture some controversy?
First, this makes no sense:
“We all know Apple wouldn’t allow Google to use an unsupported call. It’s not in their DNA. So 1 and 2 are obvious culprits and probably why the app was held back.”
Theory #1 is that Apple didn’t know what was going on, so why would the app being held back have anything to do with this?
Second, does using an undocumented feature violate the TOS? It may, but it makes little sense from a technical perspective to expose API methods to developers and then forbid them from using them through legal channels. Why not just make those methods unavailable? It seems more likely that this is NOT a violation, just an undocumented feature.
Third, isn’t Google a preferred partner on the iPhone already? I mean, they power the search and Gmaps is included by default, and has some integration capabilities not extended to other apps, correct? So why is hard to believe that Apple would have allowed them to use other restricted functionality as well?
Finally, I would bet that virtually no serious developers are going to leave the iPhone platform because of this. Google is a preferred partner with Apple and has received special treatment in numerous places as a result. You guys can wave your arms and cry foul all you want, but special treatment is kind of the point of partnerships and business relationships.
Sounds like an oversight in the documentation and no big woop.
Other apps have made use of the proximity sensor, The free app “Fake Calls” is one of them. Just seems like a clever combination of the accelerometer and proximity, no funny business.
Personally, I find it silly that Apple is so elusive about the process for authorizing and releasing apps for the iPhone. Judging by articles such as this one, and many others written by developers who have had really difficult times getting apps released vs. apps that seem to slip through the cracks, the whole thing seems to be setting itself up for failure.
I’m an iPod Touch user, and I love my device, so I wish no ill-will on any parties involved. I just don’t get a good feeling about this.
Wow interesting… Google hacked the iPhone… that or a strategic relationship with Google and Apple that leaves other developers in the dust.
Undocumented and private Apis are a totally different thing. It’s sad that such experienced apple developers can’t make that distinction.
Yep, not sure how built-in motion sensors impact the physical and/or neurological senses. Looks like Apple and Google are in a very close relationship, though Google’s Android seem to tell a different story.
You write “Note: Erica Sadun also told Gruber that she, too, is an SDK pirate:”
I did no such thing. The quote that follows this has nothing to do with me.
Uhm, fring and Truphone (both have to do with voip) also use this method to turn off the screen when you’re making a call, no big deal…