intive Argentina Blog

Los 4 “Easter Eggs” del SDK de Android

Desde hace varias décadas, y en distintos medios interactivos, podemos encontrar mensajes ocultos, bromas para entendidos y todo tipo de funciones secretas relacionadas con diferentes juegos o aplicaciones. Conocemos a estas sorpresas escondidas como «Easter Eggs» (Huevos de Pascua), y el primer caso del que se tiene registro es de 1976. Esa primera vez sucedió con «Colossal Cave Adventure», un juego de aventura textual que incluía una frase secreta («Xyzzy»), que comunicaba dos habitaciones.

Sin embargo, el término “Easter Eggs” se acuñó posteriormente. Alrededor del año 1979 surgió una injusticia: Atari no permitía incluir los nombres de los creadores en sus juegos. Joseph Warren Robinett, Jr. (diseñador y programador), decidió hacer justicia por mano propia y en su juego «Adventure», una aventura gráfica inspirada en su predecesor de 1976, escondió un objeto casi invisible, un pequeño píxel gris, que al ser activado llevaba a una habitación secreta donde se anunciaba: «Creado por Warren Robinett».

Adventure

Al descubrir el secreto, los ejecutivos de Atari quisieron en un primer momento detener la distribución de “Adventure” e incluso cambiar los cartuchos a los compradores. Pero se trataba de un juego bastante popular y esa solución no resultó viable. Entonces decidieron hacer uso del viejo «it’s not a bug, it’s a feature», comenzando a incorporar otras sorpresas en sus juegos, e invitando a los jugadores a participar de una «búsqueda de huevos de pascua» colectiva.

Así se inició una costumbre que muchos creadores de juegos, aplicaciones y software mantienen vigente hoy en día. Y los desarrolladores del SDK de Android no son una excepción. Por eso, hoy comparto con ustedes una pequeña lista de algunos de los “Easter Eggs” que encontré a lo largo de mis años como desarrolladora Android.

Qué terrible nivel

El nombre de este grupo de métodos contiene una broma. La clase Log se utiliza para enviar mensajes de depuración, que luego pueden revisarse por consola mediante el comando adb logcat o en el Android Monitor. Para ayudar a filtrar los mensajes, la clase permite seleccionar el nivel de prioridad de cada mensaje, ya sea por medio de sus métodos específicos o utilizando una constante de prioridad en el método base println.

Los métodos que más suelen utilizarse son los d(…) (para el nivel DEBUG) y e(…) (para ERROR), aunque w(…) (WARNING), e i(…) (INFO) también son muy comunes. Existen otros grupos de métodos, quizás no tan utilizados: v(…) (VERBOSE, el nivel más bajo de prioridad) y el que nos importa hoy: wtf.

La sigla «WTF» tiene un significado muy reconocible para los angloparlantes, pero en la documentación de Android, significa «What a Terrible Failure» (“Qué falla terrible”). Está destinado a ser utilizado solo en errores muy graves, esos que nunca deberían ocurrir. En versiones de Android menores a la API 23 (Lollipop o anteriores), al emitir un mensaje utilizando estos métodos se lo enviaba con nivel ASSERT, que causaba que la aplicación se cerrara con error. A partir de Marshmallow es un simple ERROR.

Screen Shot 2017-10-20 at 11.15.51 AM

#kthanksbye

La interfaz Advanceable puede ser implementada en vistas que se comporten como una colección y quieran dar posibilidad de control por parte del App Widget Host, el controlador que permite embeber widgets dentro de otra aplicación (por ejemplo en una app creada para reemplazar la Home Screen).

Advanceable tiene solo dos métodos: advance, que le indica a la vista que debe moverse dentro de su colección, y un método que avisa que se está por llamar a advance, y permite hacer tareas de inicialización en caso de ser necesarias.

Acostumbrados a ciertos estándares en las nomenclaturas, los desarrolladores podríamos esperar que un método así tuviera un nombre como «onPrepareAdvance» o algo igual de neutro e informativo. Pero no… Google nos da: fyiWillBeAdvancedByHostKThx.

«Para tu información: vas a ser avanzado por el host. ¿Okey? Gracias.»

kthx

No todos los usuarios son humanos

Los desarrolladores de Android parecen saber que un dispositivo puede estar en posesión de animales, en lugar de humanos. Hay dos métodos que nos permiten saber si el usuario actual es un mono, o una cabra.

El primer método es isUserAMonkey, «¿es el usuario un mono?» y se encuentra en ActivityManager. La descripción es llamativa:

isUserAMonkey

«Devuelve verdadero si la interfaz de usuario está siendo manipulada por un mono.»

Aunque suene gracioso, tiene una utilidad real: permite diferenciar entre las interacciones de un usuario real y las provocadas por el entorno de testing MonkeyRunner.

Ese no es el caso del siguiente método: isUserAGoat, «¿es el usuario una cabra?» en UserManager. Este método tiene su origen en una decisión tomada por Google, que anunció en 2009 que había dejado de usar los servicios de paisajistas para eliminar el exceso de arbustos en los terrenos que rodean sus oficinas, y las había cambiado por cabras, ya que las consideraba más amistosas con la ecología.

Eso llevó, al parecer, a varias bromas internas relacionadas con las cabras. Una de las que salieron a la luz fue realizada por desarrolladores de Chrome, que habían incluido una columna en su administrador de tareas indicando, para cada tarea en ejecución, la cantidad de «cabras teleportadas» («Goats teleported»).

El método del que hablamos apareció por primera vez en Android API 17, y su primera versión simplemente daba siempre «falso» como resultado. Sin embargo, a partir de Android Lollipop, el método revisa en el Package Manager si está instalado el paquete «com.coffeestainstudios.goatsimulator». En otras palabras, devuelve «verdadero» si el usuario instaló en su dispositivo el juego «Goat Simulator», el reconocido simulador de cabras.

Constantes locas al por mayor

UserManager también esconde un detalle (para nada) divertido: entre la lista de constantes que se pueden utilizar para deshabilitar funciones a los usuarios con el método addUserRestriction en el DevicePoliceManager, podemos encontrar la restrictiva «DISALLOW_FUN«, que inhibe la posibilidad de experimentar diversión y disfrutar de la alegría.

Otra constante con un nombre interesante, pero una utilidad real, es FEATURE_TOUCHSCREEN_MULTITOUCH_JAZZHAND. «Jazz Hand» es el nombre del gesto utilizado en baile que muestra la mano abierta, con los dedos muy extendidos, y muchas veces con movimientos rápidos.

Esta constante, que se encuentra en PackageManager para su uso con  hasSystemFeature, permite detectar si el dispositivo puede registrar al menos cinco puntos de presión al mismo tiempo.

En las primeras versiones de la API de Android SensorManager, podíamos encontrar una constante para describir un sensor de tipo «tricorder», el famoso artefacto de la serie Star Trek. Sin embargo, al trasladar las constantes relacionadas con sensores a la clase Sensor, este valor se dejó de lado.

Sin embargo, en SensorManager aún persisten otras dos constantes graciosas: GRAVITY_DEATH_STAR_I, que indica la gravedad estimada en la primera Estrella de la Muerte, y GRAVITY_THE_ISLAND, que incluye un guiño a la serie «Lost» y tiene un valor reconocible para sus seguidores.

Y ustedes, ¿conocen algún otro secreto oculto en el SDK de Android?

Marina Cuello

Marina Cuello es Senior Android Developer en intive – FDV. Recibida de Analista en Sistemas de Información en la Universidad Nacional de la Matanza, además estudió en el programa “Universidad Virtual” en Ciencias Sociales y Humanidades de la Universidad Nacional de Quilmes. Ávida lectora y cinéfila, en su tiempo libre Marina escribe literatura infantil y juvenil, hace muñecos de trapo y juega un poco de todo (videojuegos y juegos de mesa, también) con su hijo, su novio y sus amigos.

2 comentarios