Adb

Get versión android

$ adb shell getprop ro.build.version.release

This is really simple if your phone is rooted.

Download a terminal emulator from
<https://en.wikipedia.org/wiki/Google_Play> Google Play (there are lots that
are free). Make sure that your Android device is connected to your Wi-Fi and
get the Wi-Fi IP address. Open the terminal program and type:

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Now go to your computer (assuming that you are using Windows) and create a
shortcut on the desktop for "cmd.exe" (without the quotations).

Right click on the cmd shortcut and choose "Run as Administrator"

Change to your android-sdk-windows\tools folder

Type:

adb connect ***wifi.ip.address***:5555

(example: adb connect 192.168.0.105:5555)

adb should now say that you are connected.

Note: if you are too fast to give the connect command it may fail. So try at
least two times five seconds apart before you say this doesn't work.

Os explico por aquí la forma de conectar a ADB vía TCP/IP, usando la wifi
del móvil. Lo haré para la plataforma Windows ok?

NOTA: Este método sirve para acceder al móvil, no para arreglarlo como
Fastboot. Se da por supuesto que el móvil o cacharro funciona, y está
encendido.

1. Lo primero que hay que hacer es activar desde nuestro cacharro la
conexion por ADB. Yo la encontré en : AJUSTES->USB. Es aquella selección
donde te da a escoger entre ADB o almacenamiento masivo...

2. Activamos el wifi de nuestro trasto. No es lo mismo estar conectados, que
gestionar por adb... Aquí es importante averiguar la IP asignada al trasto.
En AJUSTES->WIFI->AJUSTES WIFI deberíais poder encontrar la ip asignada.

3. Ahora la parte chachi. Desde el PC en el que tengáis instalado el ADB,
iros a un terminal (Menu Inicio->Ejecutar->CMD), y escribid lo siguiente:

set ADBHOST=[mi ip del movil]   //por ejemplo set ADBHOST=192.168.0.103

Por defecto, Android debería usar el puerto 5555 para conexiones ADB, por lo
que  escribiremos seguidamente:

adb kill-server
adb start-server
adb connect 192.168.0.103:5555   //o sea, adb connect [mi ip]:[puerto5555]

Si todo va bien os dirá "device connected to ..blablabla.." y ZAS!!! Ya
tendremos el cacharro conectado por ADB incluso sin cable usb...

A mi me ha salvado la vida, y me ha evitado tener que abrir un server FTP en
el móvil (lo tengo igualmente, pero para otros menesteres...).

Incluso sirve como método para rootearlo. Yo lo probé con un mini-portátil
con Froyo que compré por eBay hace unos días, y ha ido de fábula!

Tenéis mucha más información en este link:

<http://stackoverflow.com/questions/2604727/how-can-i-connect-to-android-wit
h-adb-over-tcp>
http://stackoverflow.com/questions/2604727/how-can-i-connect-to-android-with
-adb-over-tcp

Adb backup

http://android.stackexchange.com/questions/23357/is-there-a-way-to-look-inside-and-modify-an-adb-backup-created-file

The backup logic on the host is entirely contained within https://github.com/android/platform_system_core/blob/master/adb/commandline.c, in the function named backup. The function is very simple: it validates the command line options, sends the command mostly as-is to the adb daemon on the phone, and writes the phone's output to the file. There isn't even error-checking: if, for example, you refuse the backup on the phone, adb just writes out an empty file.

On the phone, the backup logic starts in service_to_fd() in https://github.com/android/platform_system_core/blob/master/adb/services.c. The function identifies that the command from the host is "backup", and passes the unparsed command to backup_service() in https://github.com/android/platform_system_core/blob/master/adb/backup_service.c. That, in turn, is a thin wrapper around /system/bin/bu, which is a trivial shell script to launch com.android.commands.bu.Backup as then main-class of a new Android app process. That calls ServiceManager.getService("backup") to get the backup service as an IBackupManager, and calls IBackupManager.fullBackup(), passing it the still-unused file descriptor (very indirectly) connected to the backup.ab file on the host.

Control passes to fullBackup() in com.android.server.BackupManagerService, which pops up the GUI asking the user to confirm/reject the backup. When the user do so, acknowledgeFullBackupOrRestore() (same file) is called. If the user approved the request, acknowledgeFullBackupOrRestore() figures out if the backup is encrypted, and passes a message to BackupHandler (same file.) BackupHandler then instantiates and kicks off a PerformFullBackupTask (same file, line 2228 as of time of writing)

We finally start generating output there, in PerformFullBackupTask.run(), between line 2367 and line 2453.

First, run() writes a header, which consists of either 4 or 9 ASCII lines:

"ANDROID BACKUP"
the backup format version: currently always "1"
either "0" if the backup is uncompressed or "1" if it is
the encryption method: currently either "none" or "AES-256"
(if encrypted), the "user password salt" encoded in hex, all caps
(if encrypted), the "master key checksum salt" encoded in hex, all caps
(if encrypted), the "number of PBKDF2 rounds used" as a decimal number
(if encrypted), the "IV of the user key" encoded in hex, all caps
(if encrypted), the "master IV + key blob, encrypted by the user key" encoded in hex, all caps
The actual backup data follows, either as (depending on compression and encryption) tar, deflate(tar), encrypt(tar), or encrypt(deflate(tar)).

TODO: write up the code path that generates the tar output -- you can simply use tar as long as entries are in the proper order (see below).

Tar archive format

App data is stored under the app/ directory, starting with a _manifest file, the APK (if requested) in a/, app files in f/, databases in db/ and shared preferences in sp/. If you requested external storage backup (using the -shared option), there will also be a shared/ directory in the archive containing external storage files.

$ tar tvf mybackup.tar
-rw------- 1000/1000      1019 2012-06-04 16:44 apps/org.myapp/_manifest
-rw-r--r-- 1000/1000   1412208 2012-06-02 23:53 apps/org.myapp/a/org.myapp-1.apk
-rw-rw---- 10091/10091     231 2012-06-02 23:41 apps/org.myapp/f/share_history.xml
-rw-rw---- 10091/10091       0 2012-06-02 23:41 apps/org.myapp/db/myapp.db-journal
-rw-rw---- 10091/10091    5120 2012-06-02 23:41 apps/org.myapp/db/myapp.db
-rw-rw---- 10091/10091    1110 2012-06-03 01:29 apps/org.myapp/sp/org.myapp_preferences.xml
Encryption details

An AES 256 key is derived from the backup encryption password using 10000 rounds of PBKDF2 with a randomly generated 512 bit salt.
An AES 256 master key is randomly generated
A master key 'checksum' is generated by running the master key through 10000 rounds of PBKDF2 with a new randomly generated 512 bit salt.
A random backup encryption IV is generated.
The IV, master key, and checksum are concatenated and encrypted with the key derived in 1. The resulting blob is saved in the header as a hex string.
The actual backup data is encrypted with the master key and appended to end of the file.
Sample pack/unpack code implementation (produces/uses) tar archives: https://github.com/nelenkov/android-backup-extractor

Some more details here: http://nelenkov.blogspot.com/2012/06/unpacking-android-backups.html

Perl scripts for packing/unpacking and fixing broken archives:

http://forum.xda-developers.com/showthread.php?p=27840175#post27840175