Los desarrolladores de aplicaciones Android para tabletas ya no podrán ver como son instaladas en la BlackBerry Playbook. RIM ha decidido vetar la compatibilidad acusando a la plataforma de Google de ser un coladero de apps inseguras o maliciosas. La verdad es que el que más pierde es el fabricante canadiense y los usuarios de sus tabletas.
Ni las formas ni el fondo de RIM han sido las más acertadas. Su vicepresidente de relaciones con los desarrolladores, Alec Saunders, se despachó a gusto en Twitter al escribir algo así como que la piratería es un gran problema para los desarrolladores de Android y que ellos no querían repetir la caótica cloaca que es el Android Market.
Es cierto que la ahora llamada Google Play es más insegura que la App Store de Apple o la propia tienda de aplicaciones de RIM. Pero eso se debe a su filosofía más abierta. Esa apertura puede ser una puerta para el malware y los códigos maliciosos ocultos en una app aparentemente inofensiva. Pero también ofrece una mayor libertad para la creación que otras plataformas más cerradas.
Otra de las razones alegadas por RIM para tomar esta decisión es la de la piratería. La firma canadiense asegura que muchos desarrolladores le han mostrado su descontento por ver aplicaciones suyas adaptadas para la BlackBerry Playbook por terceros y sin su autorización.
Pero en el fondo todo puede estar motivado por una defensa de sus propios intereses. Google Play es la plataforma que tiene una mayor relación de aplicaciones gratuitas y si son gratuitas ni los desarrolladores ni en especial RIM ven un euro. La otra posible motivación es que cerrando el paso a las apps Android, creen que incentivarán el desarrollo de programas específicos para su tableta y no meras adaptaciones.
Saunders aseguró que habilitarán mecanismos para que los desarrolladores sigan pensando en su BlackBerry Playbook cuando creen aplicaciones. Pero mientras tanto, sus usuarios tendrán que conformarse con las que hay en el BlackBerry App World. Tienen unas 70.000, la sexta parte de las que hay en Google Play.
Vía ADSLZone.
Compatibilidad con apps de Android: cómo se planteó y qué pedía RIM
Antes del veto, RIM había promovido una vía oficial para aprovechar el ecosistema Android en PlayBook mediante dos “App Players”: uno para apps Android y otro para Java. Estos ejecutores, descargables desde BlackBerry App World, funcionaban como máquinas virtuales en sandbox, aislando las apps del sistema para reducir riesgos. La compatibilidad se centraba en Android 2.3 (Gingerbread), dejando fuera de inicio versiones pensadas para tabletas. RIM insistía en que los desarrolladores podían adaptar sus apps con cambios mínimos y publicarlas oficialmente en su tienda.
PlayBook OS 2.0 y la integración real: lo que se mostró
Con la llegada de PlayBook OS 2.0, RIM activó la ejecución de apps Android dentro del sistema. En demostraciones se apreciaba un arranque rápido y una integración razonable: las aplicaciones aparecían como una más dentro del entorno QNX. Para suplir los botones físicos de Android en la PlayBook, se mapearon a gestos: el menú con “swipe down”, el atrás con una barra virtual inferior y el acceso al inicio mediante un gesto desde el borde. Aunque el “launcher” incluido limitaba funciones del escritorio Android, era posible instalar otros para tener una experiencia más completa.
Proceso de empaquetado y publicación: de .apk a .bar
RIM no permitía instalar directamente archivos .apk. En su lugar, exigía reempaquetar a formato .bar, el contenedor nativo de PlayBook, y enviar la app a revisión en BlackBerry App World. El proceso podía hacerse con el SDK oficial o con utilidades que automatizaban el empaquetado e instalación. El enfoque buscaba mantener control de calidad, evitar duplicidades de tiendas y reforzar la seguridad del catálogo.
Limitaciones técnicas y APIs no soportadas
La compatibilidad no era absoluta. Documentación y pruebas señalaban carencias que impactaban a numerosas apps:
- Sin widgets y sin funciones de telefonía (llamadas, SMS, MMS).
- Restricciones o ausencia de Bluetooth, cámara, NFC y VoIP dentro del runtime.
- Sin soporte para código nativo embebido en el APK ni para FS virtuales de Linux (como /proc o /sys a nivel de app).
- Bibliotecas añadidas mediante el manifiesto, más allá de las de test, no soportadas.
- Servicios de Google como In‑App Billing (com.android.vending), push C2DM y Text‑to‑Speech fuera de alcance.
En cuanto a Google Maps, se reportaba que podía funcionar en ciertos escenarios aunque con inestabilidad atribuida al runtime, lo que ilustra el carácter incompleto de la capa de compatibilidad.
Seguridad, piratería y el enfoque sandbox
El discurso oficial de RIM se apoyaba en seguridad y piratería. El modelo sandbox de los App Players pretendía aislar el comportamiento de las apps, similar a lo que hacen soluciones como Adobe Reader o los modos protegidos al abrir archivos potencialmente maliciosos. Aun así, RIM argumentaba que la apertura de Android podía fomentar la aparición de malware y prácticas de copia no autorizada, y que era preferible impulsar desarrollo nativo y control editorial en su tienda.
Impacto para usuarios y desarrolladores
Para los usuarios, el fin de la compatibilidad supuso perder acceso a un catálogo potencialmente enorme y conformarse con lo disponible en BlackBerry App World. Para los desarrolladores, la retirada cortó una vía rápida para ampliar alcance con reempaquetado. RIM prometió una “tercera vía” para facilitar migraciones y publicó herramientas, pero la renuncia al runtime Android obedecía también a intereses estratégicos: evitar que Android eclipsara su plataforma y orientar recursos hacia apps específicas y de calidad para PlayBook.
RIM pasó de coquetear con el ecosistema Android —con App Players, OS 2.0 y un modelo de publicación moderada— a cerrar la puerta por seguridad, piratería y control de producto. El usuario de PlayBook ganó en coherencia del catálogo, pero perdió variedad; el desarrollador halló un entorno más predecible, aunque menos masivo. La decisión, polémica por las formas y por su impacto, define el equilibrio entre apertura y control que toda plataforma móvil debe gestionar.
