Copia de seguridad/restauración de Android: ¿cómo hacer una copia de seguridad de una base de datos interna?

Después de revisar mi pregunta, pude hacerla funcionar después de ver cómo lo hace ConnectBot. Gracias Kenny y Jeffrey!

En realidad es tan fácil como agregar:

FileBackupHelper hosts = new FileBackupHelper(this,
    "../databases/" + HostDatabase.DB_NAME);
addHelper(HostDatabase.DB_NAME, hosts);

A su BackupAgentHelper.

El punto que me faltaba era el hecho de que tendrías que usar una ruta relativa con "../databases/".

Aún así, esto no es de ninguna manera una solución perfecta. Los documentos de FileBackupHelper mencionan por ejemplo: "FileBackupHelper debe usarse solo con archivos de configuración pequeños, no grandes archivos binarios.", siendo este último el caso con las bases de datos SQLite.

Me gustaría obtener más sugerencias, ideas sobre lo que se espera de nosotros (cuál es la solución adecuada) y consejos sobre cómo esto podría romperse.

Aquí hay una forma más limpia de hacer copias de seguridad de bases de datos como archivos. No hay rutas codificadas.

class MyBackupAgent extends BackupAgentHelper{
   private static final String DB_NAME = "my_db";

   @Override
   public void onCreate(){
      FileBackupHelper dbs = new FileBackupHelper(this, DB_NAME);
      addHelper("dbs", dbs);
   }

   @Override
   public File getFilesDir(){
      File path = getDatabasePath(DB_NAME);
      return path.getParentFile();
   }
}

Nota: reemplaza getFilesDir para que FileBackupHelper funcione en el directorio de bases de datos, no en el directorio de archivos.

Otra sugerencia: también puede usar databaseList para obtener todos los nombres de sus bases de datos y fuentes de esta lista (sin ruta principal) en FileBackupHelper. Entonces todos los DB de la aplicación se guardarían en la copia de seguridad.

Usar FileBackupHelper para respaldar / restaurar sqlite db plantea algunas preguntas serias:
1. ¿Qué sucede si la aplicación utiliza el cursor recuperado de ContentProvider.query() y el agente de copia de seguridad intenta anular todo el archivo?
2. El link es un buen ejemplo de prueba perfecta (baja entrofia;). Desinstala la aplicación, instálela de nuevo y se restaura la copia de seguridad. Sin embargo la vida puede ser brutal. Echa un vistazo a link . Imaginemos el escenario cuando un usuario compra un nuevo dispositivo. Dado que no tiene su propio conjunto, el el agente de copia de seguridad utiliza el conjunto de otros dispositivos. La aplicación está instalada y su backupHelper recupera el archivo antiguo con el esquema de versión de la base de datos más bajo que el actual. SQLiteOpenHelper llama a onDowngrade con la implementación predeterminada:

public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {
    throw new SQLiteException("Can't downgrade database from version " +
            oldVersion + " to " + newVersion);
}

No importa lo que haga el usuario, no puede usar su aplicación en el nuevo dispositivo.

Sugiero usar ContentResolverpara obtener datos -> serializar (sin _id s) para la copia de seguridad y deserializar -> insertar datos para restaurar.

Nota: obtener/insertar datos se realiza a través de ContentResolver evitando así problemas de moneda corriente. La serialización se realiza en el BackupAgent. Si hace su propio cursorobject mapping serializar un elemento puede ser tan simple como implementar Serializable con transient field _id en la clase que representa su entidad.

También usaría bulk insert i. e.ContentProviderOperation ejemplo y CursorLoader.setUpdateThrottle para que la aplicación no se atasque con el reinicio del cargador en el cambio de datos durante el proceso de restauración de copia de seguridad.

Si sucede que estás en una situación de degradación, puede elegir entre cancelar la restauración de datos o restaurar y actualizar ContentResolver con campos relevantes para la versión degradada.

Estoy de acuerdo en que el tema no es fácil, no está bien explicado en los documentos y todavía quedan algunas preguntas como el tamaño de los datos masivos, etc.

Espero que esto ayude.

A partir de Android M, ahora hay una API de copia de seguridad/restauración de datos completos disponible para las aplicaciones. Esta nueva API incluye una especificación basada en XML en el manifiesto de la aplicación que permite al desarrollador describir qué archivos hacer una copia de seguridad de una manera semántica directa: "copia de seguridad de la base de datos llamada" mydata.db"'. Esta nueva API es mucho más fácil de usar para los desarrolladores: no tiene que realizar un seguimiento de las diferencias o solicitar un pase de copia de seguridad explícitamente, y la descripción XML de qué archivos hacer una copia de seguridad significa que a menudo no necesita escribir cualquier código.

(Usted puede involucrarse incluso en una operación de copia de seguridad/restauración de datos completos para obtener una devolución de llamada cuando se realiza la restauración, por ejemplo. Es flexible de esa manera.)

Consulte la sección Configuración de Copia de seguridad automática para aplicaciones en developer.android.com para una descripción de cómo usar la nueva API.

Una opción será construirlo en la lógica de la aplicación sobre la base de datos. En realidad grita por tal Levell, creo. No estoy seguro de si ya lo estás haciendo, pero la mayoría de la gente (a pesar del enfoque del cursor del administrador de contenido de Android) introducirá algún mapeo OR, ya sea personalizado o un enfoque lite - lite. Y lo que preferiría hacer en este caso es:

1. para asegurarse de que su aplicación funciona bien cuando la aplicación/datos se agrega en el fondo con nuevos datos añadido / eliminado mientras el aplicación ya iniciado
2. para hacer algunos Java - > protobuf o simplemente java serialización mapeo y escribir su BackupHelper propio para leer los datos desde la corriente y simplemente añadirlo a base....

Así que en este caso, en lugar de hacerlo a nivel de bd, hazlo a nivel de aplicación.