Google+
Cada vez son más los usuarios que han actualizado su XBMC de la versión estable (Dharma) a las nightly-build o versiones de desarrollo (Eden). Esta actualización es especialmente obligada si usas XBMC para iOS, dado que la versión actual de XBMC tiene tantos problemas que muchas veces no queda otra opción.

El aspecto renovado de XBMC Eden
Algunos os habéis encontrado con que después de actualizar XBMC no podéis instalar pelisalacarta, así que escribo esta entrada esperando aclarar dudas y solucionar problemas.
En el repositorio oficial de XBMC no aparece pelisalacarta, dado que hay repositorios separados para Dharma y Eden. El add-on de pelisalacarta sólo está en los repositorios de Dharma y por tanto no aparece si tienes una de las nuevas versiones.
Como no te queda más remedio, intentas instalar el add-on a mano y te aparece el mensaje de error “Dependencies not met” sin más aclaraciones. Ni errores en el log, ni ayuda en Google, ni nada…
Pelisalacarta tiene una dependencia con dos componentes externos, concretamente las librerías “simplejson” y “elementree” de Python. Estos dos componentes se encuentran en el repositorio oficial de XBMC Dharma, y por tanto cuando instalas pelisalacarta en realidad te instalas de forma transparente esos dos componentes ANTES de instalar el add-on.
Pero… en los repositorios de XBMC Eden esos dos componentes no están.
De ahí el error.
En realidad el problema es muy sencillo de resolver, como muchos habréis imaginado leyendo el punto anterior. Aunque confieso que al no tener información en el log y no encontrar más datos buscando en el foro de XBMC me costó algo de tiempo encontrar la forma de hacer la instalación.
Únicamente debes instalar a mano los dos add-ons que faltan, antes de instalar pelisalacarta. El proceso es sencillo:
script.module.simplejson.zip script.module.elementtree


Shared by ianusCanonical, sponsor of the Ubuntu project, has announced that three Asus Eee PC netbooks will now come the Ubuntu 10.10 operating system pre-installed.
Thanks to http://www.zdnet.co.uk/blogs/tech-tech-boom-10017860/asus-preloads-eee-pc-models-with-ubuntu-10022619/
Shared by ianusGoogle has aired its first primetime UK TV advert to promote its Chrome browser, using the prime advertising slot offered during the UEFA Champions League Final.
Thanks to:
http://www.t3.com/news/google-chrome-airs-first-uk-tv-ad-during-champions-league-final?=56949
Over the pond, Google have already used Lady Gaga to advertise their Chrome browser and it has also run ads during the SuperBowl, one of the most expensive advertising slots of the year.
http://www.youtube.com/watch?v=Xfc8j7b9ARM
Shared by ianus
por fin!!!!
Google no para de darnos noticias, es una fuente inagotable de información de un tiempo a esta parte y cada vez que genera una noticia suele ser para ofrecernos una nueva e increíble prestación de Android o una prestación que existe en las plataformas de la competencia y que al fin ha sido adaptado para el sistema de nuestro robotito verde.

Lo que hoy os traigo es una pequeña reflexión sobre una de esas novedades que recibimos hace poco y que fueron acogidas con los brazos abiertos: el alquiler y streaming de películas en el Android Market.
El servicio se encuentra disponible ya para algunos afortunados (aunque como siempre en España tendremos que esperar hasta que llegue el fin del mundo un poco más para poder disfrutarlo). Y además funciona todo lo bien que podríamos esperar con respecto a la competencia, pues presenta unas condiciones similares a las que presenta la iTunes Store para estos mismos servicios (he preferido comparar con este servicio y no otro por seleccionar uno que tenemos disponible en España con características similares).
¿Dónde está el pero? Pues para empezar, la manía de las restricciones geográficas para estas cosas. ¿Por qué no podemos disfrutar todos a la vez de esto? Si vas a tener que llegar a un acuerdo con las distribuidoras de las películas, podrías intentar hacerlo en todo su mercado y listo, aunque aquí podría ocurrir como con otros distribuidores de contenido multimedia online que no han podido establecerse en España porque las cuotas que exigen algunas sociedades de gestión de derechos de autor son simplemente insostenibles. Aún así, si Apple puede es bastante probable que ellos también, por lo que quizá deberían haberlo intentado un poco mejor.
De todas formas, este primer “pero” era algo menor, algo ínfimo, si lo comparamos con el otro bombazo que ha venido adjunto a la activación del servicio: no funciona en móviles rooteados.
Es decir, siempre se aboga por la libertad de Android, por la de cosas que se pueden hacer, por nuestras infinitas posibilidades. Entonces un buen día nos encontramos con que simplemente las cosas no funcionan. Y no funcionan por el mero hecho de querer controlar nuestros dispositivos más allá. Fijaos en que no hemos dicho en ROM personalizadas, o con las Google Apps pirateadas, con un recovery alternativo instalado o algo similar. No, solamente por haber rooteado el dispositivo, Google ha decidido denegar el servicio, uno de los más esperados y atractivos en la plataforma, a miles de usuarios. Personalmente espero que se trate de un error, y que la próxima versión del Market corrija este (a mi modo de ver) tremendo fallo, pero las primeras pruebas con teléfonos y tablets han arrojado un terrible jarro de agua fría sobre toda la comunidad de usuarios de Android que participan de alguna manera en desarrollos, bien probando ROM, bien programándolas, así como para todos aquellos usuarios que simplemente quieren poder usar algunas aplicaciones de Android Market (como Titanium Backup, sin ir más lejos). Quizá piensan que con el root realizado se van a piratear más las películas (cuando puedes descargarla desde tu PC y verla en cualquier reproductor multimedia sin problema alguno), o que sin él van a estar seguros, pero tarde o temprano todas las protecciones acaban cayendo, por lo que esto como mucho supone retrasar lo inevitable.
No obstante, ya ha ocurrido en ocasiones que algún servicio (no necesariamente de Google, aunque también) se ha visto restringido por error en móviles con el root realizado, y ha sido eliminada esa restricción en una pronta actualización, por lo que mientras el servicio llega a España deberemos cruzar los dedos porque los chicos de Mountain View recuperen el sentido común y habiliten un servicio genial en la inmensa mayoría de los móviles de la gente que a la postre son quienes les dan de comer, recomendando Android a amigos y familiares, enseñándoles cómo funciona, y cuántas cosas se pueden hacer y de qué forma tan sencilla.
En suma, un tremendo error de cálculo por parte de Google, que esperamos sea simplemente un bug que quede solucionado en breve, pues es una broma que puede salirles muy cara si pretenden abrir un nuevo frente de negocio. Espero sinceramente que esto no acabe en un facepalm como el de Andy en la imagen que acompaña a estas líneas…
Y vosotros, ¿qué opináis?,¿es un error que Google restrinja el acceso al servicio de alquiler y streaming de películas a dispositivos rooteados? ¿es una medida necesaria contra la piratería? ¿es un bug y será solucionado en breve? Dejamos los comentarios a vuestra disposición para que nos deis vuestra opinión.

[This post is by Justin Mattson, an Android Developer Advocate, and Erik Gilling, an engineer on the Android systems team. — Tim Bray]
Android’s USB port has in the past been curiously inaccessible to programmers. Last week at Google I/O we announced the Android Open Accessory APIs for Android. These APIs allow USB accessories to connect to Android devices running Android 3.1 or Android 2.3.4 without special licensing or fees. The new “accessory mode” does not require the Android device to support USB Host mode. This post will concentrate on accessory mode, but we also announced USB Host mode APIs for devices with hardware capable of supporting it.
To understand why having a USB port is not sufficient to support accessories let’s quickly look at how USB works. USB is an asymmetric protocol in that one participant acts as a USB Host and all other participants are USB Devices. In the PC world, a laptop or desktop acts as Host and your printer, mouse, webcam, etc., is the USB Device. The USB Host has two important tasks. The first is to be the bus master and control which device sends data at what times. The second key task is to provide power, since USB is a powered bus.
The problem with supporting accessories on Android in the traditional way is that relatively few devices support Host mode. Android’s answer is to turn the normal USB relationship on its head. In accessory mode the Android phone or tablet acts as the USB Device and the accessory acts as the USB Host. This means that the accessory is the bus master and provides power.
Building an Open Accessory is simple as long as you include a USB host and can provide power to the Android device. The accessory needs to implement a simple handshake to establish a bi-directional connection with an app running on the Android device.
The handshake starts when the accessory detects that a device has been connected to it. The Android device will identify itself with the VID/PID that is appropriate based on the manufacturer and model of the device. The accessory then sends a control transaction to the Android device asking if it supports accessory mode.
Once the accessory confirms the Android device supports accessory mode, it sends a series of strings to the Android device using control transactions. These strings allow the Android device to identify compatible applications as well as provide a URL that Android will use if a suitable app is not found. Next the accessory sends a control transaction to the Android device telling it to enter accessory mode.
The Android device then drops off the bus and reappears with a new VID/PID combination. The new VID/PID corresponds to a device in accessory mode, which is Google’s VID 0x18D1, and PID 0x2D01 or 0x2D00. Once an appropriate application is started on the Android side, the accessory can now communicate with it using the first Bulk IN and Bulk OUT endpoints.
The protocol is easy to implement on your accessory. If you’re using the ADK or other USB Host Shield compatible Arduino you can use the AndroidAccessory library to implement the protocol. The ADK is one easy way to get started with accessory mode, but any accessory that has the required hardware and speaks the protocol described here and laid out in detail in the documentation can function as an Android Open Accessory.
After the low-level USB connection is negotiated between the Android device and the accessory, control is handed over to an Android application. Any Android application can register to handle communication with any USB accessory. Here is how that would be declared in your AndroidManifest.xml:
<activity android:name=".UsbAccessoryActivity" android:label="@string/app_name">
<intent-filter>
<action android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED" />
</intent-filter>
<meta-data android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED"
android:resource="@xml/accessory_filter" />
</activity>Here's how you define the accessories the Activity supports:
<resources>
<usb-accessory manufacturer="Acme, Inc" model="Whiz Banger" version="7.0" />
</resources>The Android system signals that an accessory is available by issuing an Intent and then the user is presented with a dialog asking what application should be opened. The accessory-mode protocol allows the accessory to specify a URL to present to the user if no application is found which knows how communicate with it. This URL could point to an application in Android Market designed for use with the accessory.
After the application opens it uses the Android Open Accessory APIs in the SDK to communicate with the accessory. This allows the opening of a single FileInputStream and single FileOutputStream to send and receive arbitrary data. The protocol that the application and accessory use is then up to them to define.
Here’s some basic example code you could use to open streams connected to the accessory:
public class UsbAccessoryActivity extends Activity {
private FileInputStream mInput;
private FileOutputStream mOutput;
private void openAccessory() {
UsbManager manager = UsbManager.getInstance(this);
UsbAccessory accessory = UsbManager.getAccessory(getIntent());
ParcelFileDescriptor fd = manager.openAccessory(accessory);
if (fd != null) {
mInput = new FileInputStream(fd);
mOutput = new FileOutputStream(fd);
} else {
// Oh noes, the accessory didn’t open!
}
}
}There are a few ideas we have for the future. One issue we would like to address is the “power problem”. It’s a bit odd for something like a pedometer to provide power to your Nexus S while it’s downloading today’s walking data. We’re investigating ways that we could have the USB Host provide just the bus mastering capabilities, but not power. Storing and listening to music on a phone seems like a popular thing to do so naturally we’d like to support audio over USB. Finally, figuring out a way for phones to support common input devices would allow for users to be more productive. All of these features are exciting and we hope will be supported by a future version of Android.
Accessory mode opens up Android to a world of new possibilities filled with lots of new friends to talk to. We can’t wait to see what people come up with. The docs and samples are online; have at it!
[Android/USB graphic by Roman Nurik.]