Las sospechas de muchos entre la comunidad de desarrolladores del iPhone se han visto confirmadas por Google: una portavoz de la compañía confirmó a CNet que su última actualización para Google Mobile utiliza una API indocumentada para leer el sensor de proximidad del iPhone, lo que permite activar la función de voz cuando un usuario está listo para hablar.
La nueva herramienta de búsquedas por voz de Google Mobile despertó mucho interés por su capacidad para activar las búsquedas por voz en el momento apropiado. Basta simplemente con llevar el iPhone a la altura de la cabeza, como cuando respondemos a una llamada, y hablar. El sensor de proximidad del iPhone permite que la aplicación sepa que es el momento de empezar a recibir órdenes por voz. El único problema es que, hasta donde todos sabían, no había ninguna API oficial en el SDK del iPhone que permitiera el acceso al sensor de proximidad del teléfono. Tras sonsacar un poco, Erica Sadun determinó que Google estaba utilizando un método indocumentado, aunque no desconocido, para saber cuándo se activaba el sensor de proximidad.
Aunque Google admite estar usando una API indocumentada, la portavoz negó con firmeza que se esté utilizando un marco privado. Google ha corrido un riesgo, el mismo que corre cualquier desarrollador que utilice una API indocumentada, y espera que Apple (a) no rechace la aplicación por haber violado el acuerdo del SDK del iPhone, y (b) no modifique posteriormente la API de acceso al sensor. Si Apple rescinde su aprobación o modifica la API, Google se vería obligado a cambiar su código o quizá incluso cambiar la interfaz de usuario para evitar utilizar el sensor de proximidad.
No es la primera vez que Google se arriesga a utilizar una API indocumentada. Un análisis del código de su navegador open-source Chrome revela que llama a APIs indocumentadas en ciertas de versiones de Windows para ofrecer una mayor seguridad frente a sitios Web maliciosos. Descubrir estas APIs indocumentadas realmente requiere alguna ingeniería inversa del propio Windows, lo cual está expresamente prohibido según el CLUF de Windows. No obstante, es evidente que el objetivo de Google –lograr una mayor seguridad que la que permiten las APIs documentadas– merece la pena.
Al igual que con Chrome, puede haber algo positivo en que Google Mobile utilice la API indocumentada; Apple podría documentar esta API o crear algún tipo de API oficial y proporcionársela a los desarrolladores en una futura actualización del SDK. Y los beneficios para los usuarios son evidentes: la nueva interfaz de usuario es innovadora e intuitiva, justo lo que Apple esperaba que los desarrolladores aportaran a la plataforma.
Fuente: ArsTechnica
