Wednesday, August 29, 2012

Introducing the .ABEX File Format

As I have said in my last post, Droid Explorer will support the Android Backup (.ab) file format. But I also mentioned that Droid Explorer will extend the Android Backup file format so a backup can be tied to a specific device. This file format will be ABEX (Enhanced Android Backup). The file format is simple and just adds an additional header block to store the information.

	ENHANCED ANDROID BACKUP\n
[DEVICE ID]\n
[Droid Explorer Version]\n
[ABEX Version]\n
$$$ ENHANCED ANDROID BACKUP $$$\n

The first line is the Magic line. Next is the Device ID that the backup is tied to. This is value is a string. If the device is not connected, then an error message should be displayed notifying the user that the backup is tied to a specific device and that device could not be found. Next is the version of Droid Explorer (or the application that created the ABEX). This value is a string. Next is the Specification Version of ABEX (Current = 1). This value is an integer. The final line is an indicator showing the end of the ABEX header.


Following the ABEX Header should be the normal Android Backup content starting with the Android Backup Magic line.


I have a modified version of ABE that Droid Explorer will use to unpack these files and forked it on github.


Visually, these files will (at least for now) look just like a normal Android Backup. The difference will be the file extension and how Droid Explorer will handle them. If it is a “Basic” Android Backup, then the user will be prompted with a device selection when attempting to restore. Also, there will be an option to convert a “Basic” Android Backup to an “Enhanced” version. Also, Droid Explorer will allow the conversion of an “Enhanced” version to a “Basic” version.

Droid Explorer 0.8.8.7 Backup Feature

Droid Explorer 0.8.8.7 will be released in just a few days and will have some new features that you may find useful if you have a 4.x device.

The biggest feature is the ability to backup your device (does not require root). If you do not have a 4.x device connected, you will not be able to take advantage of this method of backup.

image

Along with that feature comes some additional features on top of it. A central location for your Android Backup files (*.ab). They will be stored in a folder in your user profile called “Android Backups”. This folder has a special folder applied to it so it is easy to tell where your backups are located.

image

Inside this folder there will be a folder for each device you use with Droid Explorer to create backups. The folder name is the “ID” of the device or the “Name” of the device if you changed it in the settings. Here you will see I have a couple backups in the folder Killik (the name I gave one of my devices).

image

But what can you do with these backups? Well, you can restore your device with them, of course. Just double click on one of the Android Backup (.ab) files and select the device you want to restore to. Make sure you restore to the correct device. I am not responsible for any disasters restoring may cause, including, but not limited to bricking your device, cat jumping of a cliff, house burning down. I may look in to extending the backups a bit, so Droid Explorer knows what device they came from, but that is not in this version.

If you right click on the Android Backup, you will also be given the option to restore the backup to a device. But, look closer at the picture below… There is also an option to unpack the backup file. This will turn the Android Backup in to a TAR Archive. Then you can get to the inner contents of the backup, like the Application Files if you choose to include those in your Backup.

image 

Another feature that will be added in the future is the ability to view backups from within Droid Explorer. If you have Droid Explorer v0.8.8.6, you will get a notification when you open Droid Explorer after the new version has been released. Keep your eye out for this version and future versions.

As always, if you have ideas for Droid Explorer, submit a Feature Request.

Introducing the .ABEX File Format

As I have said in my last post, Droid Explorer will support the Android Backup (.ab) file format. But I also mentioned that Droid Explorer will extend the Android Backup file format so a backup can be tied to a specific device. This file format will be ABEX (Enhanced Android Backup). The file format is simple and just adds an additional header block to store the information.

	ENHANCED ANDROID BACKUP\n
[DEVICE ID]\n
[Droid Explorer Version]\n
[ABEX Version]\n
$$$ ENHANCED ANDROID BACKUP $$$\n

The first line is the Magic line. Next is the Device ID that the backup is tied to. This is value is a string. If the device is not connected, then an error message should be displayed notifying the user that the backup is tied to a specific device and that device could not be found. Next is the version of Droid Explorer (or the application that created the ABEX). This value is a string. Next is the Specification Version of ABEX (Current = 1). This value is an integer. The final line is an indicator showing the end of the ABEX header.


Following the ABEX Header should be the normal Android Backup content starting with the Android Backup Magic line.


I have a modified version of ABE that Droid Explorer will use to unpack these files and forked it on github.


Visually, these files will (at least for now) look just like a normal Android Backup. The difference will be the file extension and how Droid Explorer will handle them. If it is a “Basic” Android Backup, then the user will be prompted with a device selection when attempting to restore. Also, there will be an option to convert a “Basic” Android Backup to an “Enhanced” version. Also, Droid Explorer will allow the conversion of an “Enhanced” version to a “Basic” version.

Droid Explorer 0.8.8.7 Backup Feature

Droid Explorer 0.8.8.7 will be released in just a few days and will have some new features that you may find useful if you have a 4.x device.

The biggest feature is the ability to backup your device (does not require root). If you do not have a 4.x device connected, you will not be able to take advantage of this method of backup.

image

Along with that feature comes some additional features on top of it. A central location for your Android Backup files (*.ab). They will be stored in a folder in your user profile called “Android Backups”. This folder has a special folder applied to it so it is easy to tell where your backups are located.

image

Inside this folder there will be a folder for each device you use with Droid Explorer to create backups. The folder name is the “ID” of the device or the “Name” of the device if you changed it in the settings. Here you will see I have a couple backups in the folder Killik (the name I gave one of my devices).

image

But what can you do with these backups? Well, you can restore your device with them, of course. Just double click on one of the Android Backup (.ab) files and select the device you want to restore to. Make sure you restore to the correct device. I am not responsible for any disasters restoring may cause, including, but not limited to bricking your device, cat jumping of a cliff, house burning down. I may look in to extending the backups a bit, so Droid Explorer knows what device they came from, but that is not in this version.

If you right click on the Android Backup, you will also be given the option to restore the backup to a device. But, look closer at the picture below… There is also an option to unpack the backup file. This will turn the Android Backup in to a TAR Archive. Then you can get to the inner contents of the backup, like the Application Files if you choose to include those in your Backup.

image 

Another feature that will be added in the future is the ability to view backups from within Droid Explorer. If you have Droid Explorer v0.8.8.6, you will get a notification when you open Droid Explorer after the new version has been released. Keep your eye out for this version and future versions.

As always, if you have ideas for Droid Explorer, submit a Feature Request.