Análisis y disertaciones técnicas sobre Android, SDK y Linux

[katxan]

Pedazo de curro que te estás tomando . Yo no entiendo nada de estas cosas, pero si necesitas ayuda para organizar todo esto o lo que sea, no tienes más que decirlo.

[j0534ng31]

Pedazo de curro que te estás tomando . Yo no entiendo nada de estas cosas, pero si necesitas ayuda para organizar todo esto o lo que sea, no tienes más que decirlo.

Pues, la verdad, yo de foros no entiendo mucho... He participado en muchos, pero sólo una vez abrí un hilo (para un tema de una ROM, algo mucho menos ambicioso y menos farragoso)...

A mi se me ocurrió que con el índice y un post por cada "tema" podría organizar esto casi como si fuese un sistema de micro-fichas... pero no sé si será practico.

Si crees que hay un modo mejor, sólo tienes que decirlo... Estoy abierto a sugerencias.

Por otra parte, cuando busco información (de la de verdad, no la misma noticia o dato banal repetido en 20.000 sitios) sobre estos temas, especialmente en español, nunca encuentro nada grande y serio... Así que me dije: "¡hazlo tú mismo!..." y en ello estamos.

Y ahora hablo para todos: ¡Quiero críticas!

Si no las recibo pensaré que no lo leéis, que no os importa, que no entendéis un carajo (lo que viola la declaración de intenciones), que aún no he acertado con un tema útil,...

Lo que no voy a pensar es que yo sea tan, tan, tan, tan bueno , que lo estéis entendiendo todo todos...

[dark_hunter]

Yo me lo reservo para después de exámenes que por ahora voy servido de cosas para leer xD.


Saludos

[jotam]

¡Hola! Te lo podía decir por un mp, pero bueno, revitalizar este hilo, que debería estar fijado en el apartado de rooteo. Por lo menos me serviría para localizarlo de forma rápida.
Varias cosas:

1. Con respecto al tema de ad-hoc, en vez de poner todo ese código, encuentro que se podría hacer de forma más sencilla, poniendo el archivo 'wpa_supplicant' en un rooteo. De esa forma, para mi es más rápido, y supongo que tb. lo será para otros. Funcionar funciona pero no sé si necesitaría algún código añadido.
   
   
   
2. Supongo que conoces el funcionamiento del fichero hosts, para las dns locales. Bueno pues en Android al parecer ese fichero se coloca en '/system/etc/host'. Vale, pues le quería poner los de este sitio, pero no consigo que me funcionen. Por si conoces algo más sobre el tema.
   
   
   
3. Y me gustaría saber si sería posible montar las particiones data y system en linux, retocarlas con los ficheros que se deseen; una vez hechas generar unos archivos de imagen, y con esos archivos, restaurar el T1 para así tener la configuración deseada, sin rooteos posteriores, y sin ficheros basura, como el LiveWallpaper y similares y con los añadidos que se deseen.
   O por el contrario las particiones tienen un tamaño x que está definido en algún sitio (fs.. x, etc.) y eso no funcionaría de ninguna manera.
   
   
   
4. Con respecto al último de Rupor, he visto que añaden en varios ejecutables, a nivel de su: busybox (actualizado), fix_permissions, capturescr y uno que se llama dexopt-wrapper que no sé para que sirve. Pensaba que sería para generar de un apk el archivo odex, pero no lo sé. ¿Sabes para qué sirve?
   Tampoco entiendo bien para que sirve lo de poner el odex. Leí, pero no sé si es correcto, que el odex, no es más que el archivo classes.dex que se encuentra en un archivo apk; se extrae del apk, y se coloca con el mismo nombre y extensión odex. Y tendría su lógica "out dex" -> odex. Pero quizá sean milongas mías. Así el archivo apk es más pequeño, ya que esa parte se quitaría. Pero no entiendo el motivo aunque así sea, ni si dexopt-wrapper ayuda, ni cómo, a llevarlo a cabo.
   Y en cuanto al capturador, ¿sería posible llamarlo (invocarlo) con una configuración básica (por ejemplo en 10 segundos, estés donde estés, saco captura) desde una aplicación con entorno gráfico? Quizá ya esté hecho, pero si no, quizá sería un buen añadido para el rootset de Rupor u otros como el de Morkl.

Bueno, saludos otra vez. Que ya hacía un tiempo.

[Terisa]

Hala, el señorito ya sabe dónde encontrarlo

[jotam]

Hala, el señorito ya sabe dónde encontrarlo

Gracias, señorita.

La verdad es que me he quedao un poco traspuesto., no sabía ni dónde me encontraba. O si había pasado algo.
Estaba editando el comentario, y ¡pluf! Pasó algo. ¿Qué? ¿Cómo?

Para otra vez ¿debería pedirlo educadamente por mp en vez de hacer comentarios insidiosos sin insidia implícita?

No tenía intención de ofender.

Pero ya que estamos, a mi parecer no estaría mal cambiar tb. el de Aplicaciones, y Coolreader traducido, ya que sólo sirven para el T1, si éste está rooteado, o en todo caso personalizado.

Y mejor que "Rooteo", aunque no esté nada mal, sería poner "Rooteo y personalización" o algo así. Por ejemplo en mobileread distinguen "Sony Reader Dev Corner". Aunque no me parece nada mal dejarlo como está. Escueto y sencillo.
También había que pasar otros hilos, como:
"MORKL alternativa a RUPOR,.fb2 en el Home del Sony, 3ª pagina, control refresco.."
"Ver EBOOK's en formato .FB2 y .FB2.ZIP en el HOME del Sony Prst-1"
Y supongo que otros.

Y en el general del T1, fijar el de "Fundas Sony PRS-T1". Ya que es un tema recurrente.

En todo caso es mi parecer. No te lo tomes a mal. No te estoy haciendo una crítica porque moderes mal, ni nada por estilo. Y si he molestado, te pido perdón. Si es que eso sirve para algo.

Sólo que lo veía un poco extraño. Y que me perdone j0534ng31 por ensuciar su hilo con estas cosas que no tienen que ver con el tema.

[Terisa]

No era una crítica hombre, era un trozondeo, pero me explico como un libro cerrado Además me ha servido para aprender cómo mover un tema en el tapatalk El resto de las cosas se harán.... O no, ya se verá

[j0534ng31]

¡Hola! Te lo podía decir por un mp, pero bueno, revitalizar este hilo, ...

Debería revitalizarlo yo, pero esta temporada se me han complicado un poco las cosas.

Con respecto al tema de ad-hoc, en vez de poner todo ese código, encuentro que se podría hacer de forma más sencilla, poniendo el archivo 'wpa_supplicant' en un rooteo. De esa forma, para mi es más rápido, y supongo que tb. lo será para otros. Funcionar funciona pero no sé si necesitaría algún código añadido.

Si, por supuesto que se puede y es más fácil, tendrías que:

- Poner en /system/bin el nuevo ejecutable wpa_supplicant,

- Darle los permisos de ejecución, y

- Cambiar los permisos/propietario del archivo del configuración de 'wpa_supplicant'

Aún no he acabado, pero casi, mi paquete de 'rooteo y modificaciónes' (muchas)... ahí podrás ver todo el código.

La diferencia de este rooteo con los actuales, es que todo se hace desde un batch de windows, sin reiniciar el T1 hasta el final. Tendrá un menú para seleccionar lo que quieras hacerle al T1 y un procedimiento automático para hacer un 'rooteo habitual' sin zarandajas raras (de esas que, en principio, sólo nos interesan a cuatro gatos)

Estoy intentando ahora añadir la modificación de tamaño de las particiones y ya tengo hecho, pero sin añadir, el código que hace y restaura copias de seguridad de las particiones originales...

Pero hace muchas más cosas como, por ejemplo, descargar varias listas de hosts, y unificarlas en un archivo hosts actualizado (ese por el que me preguntas... )

Supongo que conoces el funcionamiento del fichero hosts, para las dns locales. Bueno pues en Android al parecer ese fichero se coloca en '/system/etc/host'. Vale, pues le quería poner los de este sitio, pero no consigo que me funcionen. Por si conoces algo más sobre el tema.

Ya te he contestado, pero añado un detalle: El archivo es '/system/etc/hosts'

Puede que no te funcione sólo por eso.

Y me gustaría saber si sería posible montar las particiones data y system en linux, retocarlas con los ficheros que se deseen; una vez hechas generar unos archivos de imagen, y con esos archivos, restaurar el T1 para así tener la configuración deseada, sin rooteos posteriores, y sin ficheros basura, como el LiveWallpaper y similares y con los añadidos que se deseen.

Si, se puede, pero yo lo haría en el propio T1:

1- Creas la imagen con 'dd' y la montas en un directorio nuevo

2- La modificas como te apetezca (si lo hicieses en un linux, "creo" que tendrías problemas para cambiar permisos al añadir archivos, ya que los 'usuarios' y 'grupos' de tu linux no se corresponden con los del T1)

3- Desmontas la imagen y la guardas en tu PC

4- (OPCIONAL) Modificas el 'SD recue' de Boroda para eliminar SUS imágenes de 'system' y 'data' y, en su lugar, poner las TUYAS.

O por el contrario las particiones tienen un tamaño x que está definido en algún sitio (fs.. x, etc.) y eso no funcionaría de ninguna manera.

Funcionaría. Creo que te lías mezclando conceptos diferentes:

- Las "particiones" (/sys/block/mmcblk2**) SI tienen un tamaño fijo definido 'en alguna parte' y, ALGUNAS (todas excepto p1 y p2), SI se pueden variar de tamaño... (por ejemplo, usando 'fdisk' o 'parted')
Pero no es obvio (no vale cualquier tamaño ni, tampoco, cualquier posición), es peligroso, hay que seguir unas reglas y puede que haya que deshacer el proceso antes de hacer una actualización de firmware oficial...
O sea, que no es recomendable para un usuario normal y, preferiblemente, se hará usando un procedimiento automático que impida 'errores tontos' y 'errores por pasarse de listo'.

- Los "sistemas de ficheros" (el 'formato', o 'formateo', como 'fat32' o 'ext4') TAMBIÉN tienen un tamaño (y otras cosas) definido para la partición (o particiones) en la/s que residen...
Sin embargo, su tamaño se puede variar más fácilmente que el de las particiones.
Si, a modo de ejemplo, haces una imagen de una 'partición' con 'dd', podrías variar el tamaño del 'sistema de ficheros' usando 'resize2fs'... Eso sí, el archivo 'img' mantendría su tamaño original (porque la partición no habría variado de tamaño)

- Y, por último, el caso de copiar una 'partición' con 'dd', montarla y añadir o borrar archivos:
Pues eso... que borras archivos o los añades (¡si caben!)...
NO varía el tamaño del 'sistema de ficheros'
NO varía el tamaño de la 'partición'

- Usando un símil comprensible, tonto y técnicamente nada acertado:
Un 'disco' (continente) se divide, para organizarlo mejor, en una o mas 'particiones' (cajones) que llevan asociado un 'sistema de ficheros' (forma del cajón), más o menos adaptado a los ficheros (objetos) que va a almacenar (contenido).

Con respecto al último de Rupor, he visto que añaden en varios ejecutables, a nivel de su: busybox (actualizado), fix_permissions, capturescr y uno que se llama dexopt-wrapper que no sé para que sirve. Pensaba que sería para generar de un apk el archivo odex, pero no lo sé. ¿Sabes para qué sirve?

Si, para eso... y el odex es, en parte, una optimización del código de la aplicación que ayuda a que el T1 la ejecute más rápido

Tampoco entiendo bien para que sirve lo de poner el odex. Leí, pero no sé si es correcto, que el odex, no es más que el archivo classes.dex que se encuentra en un archivo apk; se extrae del apk, y se coloca con el mismo nombre y extensión odex. Y tendría su lógica "out dex" -> odex. Pero quizá sean milongas mías. Así el archivo apk es más pequeño, ya que esa parte se quitaría. Pero no entiendo el motivo aunque así sea, ni si dexopt-wrapper ayuda, ni cómo, a llevarlo a cabo.

Si la aplicación es más pequeña y lleva asociado un odex:

- Al arrancar el T1 se lee el odex

- El sistema ocupa más, o sea, que hay menos hueco para modificaciones de los desarrolladores.

- Modificar las aplicaciones cuesta un h**v* de trabajo más (entre comillas).

Si la aplicación es más grande (con classes.dex dentro del apk) y no existe el odex:

- Al arrancar el T1 se construye el 'odex' (la máquina dalvik procesa el apk y genera un dex en dalvik-cache)

- El T1 (al hacer lo anterior para cada aplicación) tarda un h**v* en arrancar.

- Modificar las aplicaciones es una chorrada.

Y en cuanto al capturador, ¿sería posible llamarlo (invocarlo) con una configuración básica (por ejemplo en 10 segundos, estés donde estés, saco captura) desde una aplicación con entorno gráfico? Quizá ya esté hecho, pero si no, quizá sería un buen añadido para el rootset de Rupor u otros como el de Morkl.

Se invoca con una sola llamada desde el terminal y crea un archivo jpg...

Sólo hace falta algo que lo pase al PC...

Rupor usa un script desde Windows que se basa en adb para pasar la imagen al PC:

@echo off 
SET ADK="C:\Program Files (x86)\Android\android-sdk" 
SET RES=/data/local/tmp/screen.png 
IF .%1. == .-1. GOTO PARAM 
IF .%1. == ..   GOTO CONT 
SET RES=%1 
SET PARAM=%2 
GOTO CONT 
:PARAM 
SET PARAM=%1 
:CONT 
%ADK%\platform-tools\adb shell /system/bin/capturescr %PARAM% %RES% 
%ADK%\platform-tools\adb pull %RES% 
%ADK%\platform-tools\adb shell rm %RES%

[jotam]

Lo de revitalizarlo era independiente a que hicieras más o menos. Lo que hay, tiene un gran valor en sí mismo. Sirve y no hay tanta documentación al respecto, o no en castellano al menos.


Como te dije, lo del wpa_supplicant, me funcionaba, y encuentro interesante incluirlo en el futuro.

Me alegro que sigas en la brecha, pese a que estés más liado.

En cuanto al hosts, no fallé en eso de cambiar el nombre de archivo, pero probaba alguno de los enlaces bloqueados, y en vez de salirme un error de página no encontrada, me salía la página en sí. Por lo que llegué a la conclusión de que no funcionaba bien lo del hosts.
Y llegué a pensar que quizá no hubiera que poner 127.0.0.1 como localhost, sino 127.0.0.2 como vi en algunas webs. Pero eso aún no lo he probado.

Gracias tb por el comentario de las particiones. No me veo creando esos output con dd. No me manejo bien. Y no estoy seguro de lo que hago. Salvo para mis propisa pruebas. Pero si es posible, no entiendo cómo todavía nadie halla sacado ningún restore set (data y system) rooteado que sirva como alternativa a una restauración de particiones.

Lo de los odex, está muy bien. Osea, que sirven para evitar procesos que serían repetitivos. Ahora bien, si haces un rooteo, tb. se deberían crear los odex de esas aplicaciones añadidas, por ejemplo, superuser o PackageInstaller. Y si añades ivona (por ejemplo junto al PicoTTS en system) pues tb. podrías poner los odex. Y así con todo lo que pongas en system. Pero por ejemplo Rupor, no lo hace.
Y si se hiciera con las aplicaciones de data, ¿funcionarían igual?
He probado a generar el odex de ivona, y parece que lo genera.
Después está el tema de los nombres: ¿si al apk lo llamo RootExplorer2.19.apk, el odex resultante tendría que ser RootExplorer2.19.odex, pese a que su nombre real a la hora de instalar o crear datos sea otro? Quiero decir mismo nombre y lo que cambia es la extensión y a funcionar ¿es correcto?
Y como broche final, ¿se tendría que eliminar del apk el archivo classes.dex con 7zip, por ejemplo? Entiendo que es eso.

Lo del capture no me refería a cómo se hacía o cómo lo hacía Rupor, sino si desde una aplicación como la de configuración del Sony, se podría llamar a una función para que en 10 segundos hiciera una captura. Desde el gestor gráfico, generar captura. Me parecía una idea buena.

Tb. he estado pensando en si es posible eliminar otras aplicaciones que no le veo sentido dentro de system. Algunas que no elimina Rupor. Por ejemplo:
Bluetooth, Phone, QuickSearchBox o TelephonyProvider.
Por el momento he eliminado Buetooth apk+odex. Y no parece haber problemas. Creo que el widget de búsqueda de google, tampoco tiene demasiada importancia en el T1. Y quizá siga el mismo camino.
Los otros no sé qué hacer, porque desconozco completamente qué dependencias podrían romper.

Y por último, decir que en la última de Rupor, en la carpeta bin, he visto que ha añadido "sqlite3". Por el momento no lo he puesto, ni he visto para qué se puede usar (sólo entiendo que debe ser para gestionar bases de datos).

Ya veré que voy viendo...

[j0534ng31]

JeJe... Siempre me lías a una explicación laaaarga... Que sepas que me caes muy bien, eres muy curioso y eso me gusta

Un día de estos acabaré el puñetero rooteo y, como el código está explicado, creo que vas a ser de los pocos que lo lean entero.

Como te dije, lo del wpa_supplicant, me funcionaba, y encuentro interesante incluirlo en el futuro.

Sip... mi rooteo también lo hace por defecto. No hace más que mejorar el original y no produce ningún efecto adverso.

En cuanto al hosts, no fallé en eso de cambiar el nombre de archivo, pero probaba alguno de los enlaces bloqueados, y en vez de salirme un error de página no encontrada, me salía la página en sí. Por lo que llegué a la conclusión de que no funcionaba bien lo del hosts.
Y llegué a pensar que quizá no hubiera que poner 127.0.0.1 como localhost, sino 127.0.0.2 como vi en algunas webs. Pero eso aún no lo he probado.

Lo normal es que si hay un archivo hosts el sistema lo lea y se atenga a él, pero no lo he comprobado... Yo sólo preparé un script que lo crea y lo actualiza... Quizás tengas razón y no funcione aunque esté ahí. Y 127.0.0.1 es correcta.

Gracias tb por el comentario de las particiones. No me veo creando esos output con dd. No me manejo bien. Y no estoy seguro de lo que hago. Salvo para mis propisa pruebas. Pero si es posible, no entiendo cómo todavía nadie halla sacado ningún restore set (data y system) rooteado que sirva como alternativa a una restauración de particiones.

Pues me imagino por qué... ¿No has leido a Boroda (varias veces) decir que NO es SU firmware? Por ejemplo, aquí... Todos temen una reacción agresiva por parte de Sony...

Una cosa es un paquete de rooteo (que sólo lleva cosas, por poner un ejemplo, mías)... Es legal y aceptable.

Otra cosa es hacer una herramienta de restauración (que sólo lleva cosas de Sony que son de "dominio público", como el firmware original del T1)... Probablemente no es legal, pero también es aceptable.

Otra distinta es hacer la misma herramienta de restauración con imágenes del firmware actual (que Sony distribuye sólo a sus clientes y bajo determinadas condiciones de uso... Boroda no lo hace, pero Amutin se atreve)... No es legal y si a Sony no le hace gracia, te buscará las cosquillas.

No se si me estoy explicando bien... lo que pides está ahí (nos lo facilitó Boroda) para que cualquiera con unos pocos conocimientos lo haga realidad para su uso privado... Pero nadie se atreve a excederse publicándolo, por si acaso.

De hecho, ya lo he dicho al principio del hilo, todos DEBERÍAMOS hacer una copia de seguridad de NUESTRO T1... ¿Por qué? Para hacernos nuestro 'rooteo', nuestro 'recovery', nuestro 'restore' y nuestras 'mods'... con la información original de nuestros T1, bajo nuestra responsabilidad y ateniéndonos (o desoyendo) las leyes de nuestros respectivos paises. La nuestra es bastante tolerante, la de Boroda menos...

Las aplicaciones, en cambio, son harina de otro costal... Rupor y otra gente se atreven modificarlas porque su código fuente (al basarse en Android) es, o debería de ser, open source... Si las modifican (por ingeniería inversa) y alguien se queja sólo hay que contestar "¿Y donde está el código fuente que nos debéis? ¿No cumplís vuestra propia licencia y os atrevéis a criticarnos? Llévalo a un juez, ¡a ver quién pierde más!"

Ahora bien, si haces un rooteo, tb. se deberían crear los odex de esas aplicaciones añadidas, por ejemplo, superuser o PackageInstaller. Y si añades ivona (por ejemplo junto al PicoTTS en system) pues tb. podrías poner los odex. Y así con todo lo que pongas en system. Pero por ejemplo Rupor, no lo hace.

Realmente no sé si lo hace o no, pero se puede hacer... Mantener mi versión de firmware me impide comprobarlo.

Eso sí, recuerda que la partición system es de sólo lectura, hay que remontarla en modo rw... si no lo haces (tu directamente o desde un script), los odex no se podrán guardar en system.

El proceso a seguir para deodexar cada aplicación (asumiendo que el framework ya está deodexado previamente) sería:

#
# Se copia la aplicación en un directorio temporal del T1 (para no estropear el original)
mkdir  DirectorioTemporal
cp  DirectorioOrigen/Nombre_App.apk  DirectorioTemporal
#
# Se deodexa
dexopt-wrapper  DirectorioTemporal/Nombre_App.apk  DirectorioTemporal/Nombre_App.odex
#
# Se borra 'classes.dex' del archivo 'apk' (paso OPCIONAL, pero imprescindible por falta de espacio)
# Si lo hacemos, la aplicación ya NO podrá actualizarse (habrá que desinstalar la vieja y reinstalar la nueva)
zip -d  DirectorioTemporal/Nombre_App.apk  classes.dex
#
# Se INSTALA la aplicación en system:
cp  DirectorioTemporal/Nombre_App.*  /system/app

En data creo que también podría hacerse, pero de un modo más complicado (además de dificultar las actualizaciones):

#
# Se INSTALA el 'apk' original (para que se coloquen en su sitio las librerías y los datos)
pm install  DirectorioOrigen/Nombre_App.apk
#
# Se borra el archivo recien instalado (OPCIONAL, si no, lo pisaremos más tarde con la versión deodexada)
rm /data/app/Nombre_App.apk
#
# Se copia la aplicación en un directorio temporal del T1 (para no estropear el original)
mkdir  DirectorioTemporal
cp  DirectorioOrigen/Nombre_App.apk  DirectorioTemporal
#
# Se deodexa
dexopt-wrapper  DirectorioTemporal/Nombre_App.apk  DirectorioTemporal/Nombre_App.odex
#
# Se borra 'classes.dex' del archivo 'apk' (paso OPCIONAL)
# Si lo hacemos, la aplicación ya NO podrá actualizarse (habrá que desinstalar la vieja y reinstalar la nueva)
zip -d  DirectorioTemporal/Nombre_App.apk  classes.dex
#
# Aquí tengo una duda: Si hacemos el paso anterior, es posible que debamos refirmar la aplicación
# (Y si no disponemos de la firma original, no funcionará... porque la instalamos con la firma original)
# Aunque creo que no hace falta...
#
# Se COPIA la aplicación deodexada en data:
cp  DirectorioTemporal/Nombre_App.*  /data/app

Por último, tras instalarlas todas, no estaría de más ejecutar el fix_permissions (por si acaso).

Y respecto a esto último: Rupor dice usar un fix-permissions muy reciente... yo creo que está equivocado... el que yo uso (sacado de CyanogenMOD (Gracias, Cyanogen ) es varias versiones más moderno, admite reparar system, admite deshabilitar el log (para ganar velocidad) y, tras una pequeña modificación, también repara las app de la partición linux de la tarjeta externa (la que usa Link2SD)

Hacer esto automáticamente con un paquete de rooteo no es posible. Deberías ejecutar un script en el primer arranque que lo hiciera todo... O, más fácil, deodexar todo previamente en tu T1 y meter luego las aplicaciones deodexadas en tu nuevo paquete de rooteo

Y si se hiciera con las aplicaciones de data, ¿funcionarían igual?
He probado a generar el odex de ivona, y parece que lo genera.

Lo dicho... creo que sí. Pero no lo sabrás a ciencia cierta si no borras el 'classes.dex' (si, tras borrarlo y reiniciar, IVONA aun funciona... es que si sirve para las aplicaciones de data)

Después está el tema de los nombres: ¿si al apk lo llamo RootExplorer2.19.apk, el odex resultante tendría que ser RootExplorer2.19.odex, pese a que su nombre real a la hora de instalar o crear datos sea otro? Quiero decir mismo nombre y lo que cambia es la extensión y a funcionar ¿es correcto?

Sip... El nombre del 'apk' que coloques en el T1 ha de ser el mismo que el de su 'odex' correspondiente.

Si intentas hacer lo de data, tendrás que buscar el nombre con el que ha sido efectivamente instalada la aplicación (no tiene porque conservar el que tu hayas puesto: Si lo considera una actualización suele añadir un guión y un número de versión.)

Y como broche final, ¿se tendría que eliminar del apk el archivo classes.dex con 7zip, por ejemplo? Entiendo que es eso.

Es realmente para que la aplicación ocupe menos (porque el nuevo apk sin classes.dex junto con el odex ya ocupan más que el apk original... y no sobra sitio). Pero ya sabes, la aplicación deja de ser actualizable.

Lo del capture no me refería a cómo se hacía o cómo lo hacía Rupor, sino si desde una aplicación como la de configuración del Sony, se podría llamar a una función para que en 10 segundos hiciera una captura. Desde el gestor gráfico, generar captura. Me parecía una idea buena.

Si, eso tal vez se podría hacer, pero me parece más complicado.

Se diseño para poder hacer capturas para desarrollo (usando adb), porque en nuestro T1 no funciona directamente el método estandar de Android.

Eso quiere decir que esa aplicación sólo interesa a los usuarios del T1. De hecho, sólo a los que no quieren usar adb (lo que excluye a todos los desarrolladores) y, por tanto, es muy improbable que alguien la desarrolle.

Tb. he estado pensando en si es posible eliminar otras aplicaciones que no le veo sentido dentro de system. Algunas que no elimina Rupor. Por ejemplo:
Bluetooth, Phone, QuickSearchBox o TelephonyProvider.
Por el momento he eliminado Buetooth apk+odex. Y no parece haber problemas. Creo que el widget de búsqueda de google, tampoco tiene demasiada importancia en el T1. Y quizá siga el mismo camino.
Los otros no sé qué hacer, porque desconozco completamente qué dependencias podrían romper.

En general, salvo las dos de telefonía, no tendrían que dar problemas.

En mi rooteo yo borro varias (incluidas las de telefonía):

EbookDemoService
EbookDemo
LiveWallpapersPicker
LiveWallpapers
MagicSmokeWallpapers
VisualizationWallpapers
Bluetooth
Phone
TelephonyProvider

Pero no basta con borrar los archivos...

• Se deberían desinstalar correctamente con "pm uninstall" (desde un rooteo no puedes) y/o borrar toda referencia a esas aplicaciones del archivo '/data/system/packages.xml'
• Hay que borrar los datos almacenados en la subcarpeta de '/data/data' correspondiente a la aplicación.
• Y además, en algunas aplicaciones, hay que borrar de '/system/etc' la configuración remanente (es el caso de 'bluetooth', por ejemplo)

Y por último, decir que en la última de Rupor, en la carpeta bin, he visto que ha añadido "sqlite3". Por el momento no lo he puesto, ni he visto para qué se puede usar (sólo entiendo que debe ser para gestionar bases de datos).

Para eso sirve... Imagino que lo use para poder regenerar las listas de libros en el home (pero no lo se)

Yo, en mi rooteo, lo uso para optimizar las bases de datos que el T1 ha ido almacenando (porque yo no asumo que el rooteo se aplica 'en vacío', inmediatamente tras un restore)


Saludos