Резервне копіювання / відновлення Android: як зробити резервну копію внутрішньої бази даних?

Question 1

Я BackupAgentHelperзастосував надане FileBackupHelperдля резервного копіювання та відновлення власної бази даних, яку маю. Це база даних, якою ти зазвичай користуєшся ContentProvidersі яка знаходиться /data/data/yourpackage/databases/.

Можна подумати, що це звичайний випадок. Однак у документах незрозуміло, що робити: http://developer.android.com/guide/topics/data/backup.html . Там немає BackupHelperспеціально для цих типових баз даних. Тому я використавFileBackupHelper , вказав його на мій файл .db у " /databases/", ввів замки навколо будь-якої операції з db (наприклад, db.insert) у моїй ContentProvidersі навіть спробував створити /databases/каталог " " раніше, onRestore()оскільки він не існує після встановлення.

SharedPreferencesРаніше я впроваджував подібне рішення для успішного використання в іншому додатку. Однак, коли я тестую свою нову реалізацію в емуляторі-2.2, я бачу, як виконується резервне копіювання LocalTransportз журналів, а також виконується (і onRestore()викликається) відновлення . Проте сам файл db ніколи не створюється.

Зверніть увагу, що це все після встановлення та до першого запуску програми, після відновлення. Окрім цього, моя стратегія тестування базувалася на http://developer.android.com/guide/topics/data/backup.html#Testing .

Зауважте також, що я не кажу про якусь базу даних sqlite, якою я сам керую, а також про резервне копіювання на SDcard, власний сервер чи деінде.

Я бачив у документах згадування про бази даних, які радять використовувати спеціальний, BackupAgentале, схоже, це не пов’язано:

Однак, можливо, ви захочете розширити програму BackupAgent безпосередньо, якщо вам потрібно: * Резервне копіювання даних у базі даних. Якщо у вас є база даних SQLite, яку ви хочете відновити, коли користувач переінсталює вашу програму, вам потрібно створити власний BackupAgent, який зчитує відповідні дані під час операції резервного копіювання, а потім створіть таблицю та вставте дані під час операції відновлення.

Будь ласка, ясність.

Якщо мені справді потрібно зробити це до рівня SQL, то мене турбують такі теми:

Відкриті бази даних та транзакції. Я не уявляю, як закрити їх із такого однокласного класу поза робочим процесом мого додатка.
Як повідомити користувача про те, що виконується резервне копіювання, а база даних заблокована. Це може зайняти багато часу, тому, можливо, мені доведеться показати індикатор прогресу.
Як зробити те ж саме при відновленні. Як я розумію, відновлення може відбутися саме тоді, коли користувач вже почав користуватися програмою (і вводити дані в базу даних). Тому ви не можете припустити, що просто відновите резервні копії даних на місці (видаливши порожні або старі дані). Вам доведеться якось приєднатися до цього, що для будь-якої нетривіальної бази даних неможливо через ідентифікатори.
Як оновити програму після відновлення, не застрягаючи користувача в якійсь - зараз - недосяжній точці.
Чи можу я бути впевненим, що базу даних вже оновлено при резервному копіюванні чи відновленні? В іншому випадку очікувана схема може не збігатися.

Question 2

Більш чистим підходом було б створити власний BackupHelper:

public class DbBackupHelper extends FileBackupHelper {

    public DbBackupHelper(Context ctx, String dbName) {
        super(ctx, ctx.getDatabasePath(dbName).getAbsolutePath());
    }
}

а потім додайте його до BackupAgentHelper:

public void onCreate() {
    addHelper(DATABASE, new DbBackupHelper(this, DB.FILE));
}

Question 3

Переглянувши своє запитання, я зміг змусити його працювати, подивившись, як це робить ConnectBot . Дякую Кенні та Джеффрі!

Насправді це так само просто, як додати:

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

до вашого BackupAgentHelper.

Суть, якого мені не вистачало, полягає в тому, що вам доведеться використовувати відносний шлях із " ../databases/".

Проте це далеко не ідеальне рішення. Документи для FileBackupHelperзгадування, наприклад: " FileBackupHelperслід використовувати лише з малими файлами конфігурації, а не великими двійковими файлами. ", Останнє стосується баз даних SQLite.

Я хотів би отримати більше пропозицій, розуміння того, що від нас очікують (яке є правильне рішення), та поради щодо того, як це може зламатися.

Question 4

Ось ще більш чистий спосіб резервного копіювання баз даних у вигляді файлів. Жодних закодованих шляхів.

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();
   }
}

Примітка: він перевизначає getFilesDir, так що FileBackupHelper працює в директорії баз даних, а не в директорії файлів.

Ще одна підказка: ви також можете використовувати databaseList, щоб отримати усі ваші БД та імена стрічок із цього списку (без батьківського шляху) у FileBackupHelper. Тоді всі бази даних програми будуть збережені у резервній копії.

Question 5

Використання FileBackupHelperдля резервного копіювання / відновлення sqlite db викликає кілька серйозних питань:
1. Що трапиться, якщо програма використовує курсор, отриманий з, ContentProvider.query()і агент резервного копіювання намагається замінити весь файл?
2. Посилання є гарним прикладом досконалого (низька ентрофія;) тестування. Ви видаляєте програму, встановлюєте її знову, і резервна копія відновлюється. Однак життя може бути жорстоким. Погляньте на посилання . Уявімо сценарій, коли користувач купує новий пристрій. Оскільки у нього немає власного набору, агент резервного копіювання використовує набір іншого пристрою. Додаток встановлено, і ваш backupHelper отримує старий файл із схемою версії db, нижчою від поточної. SQLiteOpenHelperвиклики onDowngradeіз реалізацією за замовчуванням:

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

Незалежно від того, що робить користувач, він / вона не може використовувати ваш додаток на новому пристрої.

Я б запропонував використовувати ContentResolverдля отримання даних -> серіалізувати (без _ids) для резервного копіювання та десеріалізувати -> вставити дані для відновлення.

Примітка: отримання / вставка даних здійснюється через ContentResolver, таким чином уникаючи проблем з валютою. Серіалізація виконується у вашому резервному агенті. Якщо ви робите свій власний курсор <->, відображення об'єкта серіалізацією елемента може бути таким самим простим, як реалізаціяSerializable допомогою transientполя _id у класі, що представляє вашу сутність.

Я б також використав об'ємну вставку, тобто ContentProviderOperation приклад, і CursorLoader.setUpdateThrottleщоб програма не застрягла при перезавантаженні завантажувача при зміні даних під час процесу відновлення резервної копії.

Якщо трапилося, що ви потрапили в ситуацію зниження версії, ви можете вибрати або скасувати відновлення даних, або відновити та оновити ContentResolver за допомогою полів, що стосуються пониженої версії.

Я погоджуюсь, що тема непроста, недостатньо добре пояснена в документах, і деякі питання все ще залишаються, як-от об'ємний обсяг даних тощо.

Сподіваюся, це допомагає.

Question 6

Що стосується Android M, то тепер для програм доступний API для резервного копіювання та відновлення даних. Цей новий API включає специфікацію на основі XML в маніфесті програми, яка дозволяє розробнику безпосередньо семантично описувати файли для резервного копіювання: 'резервне копіювання бази даних з назвою "mydata.db"'. Цей новий API набагато простіший у використанні для розробників - вам не потрібно відстежувати відмінності або явно вимагати проходження резервної копії, а опис XML файлів для резервного копіювання означає, що вам часто не потрібно писати код зовсім.

(Ви можете взяти участь навіть у операції повного резервного копіювання / відновлення даних, щоб отримати зворотний виклик, коли відбудеться відновлення, наприклад. Це гнучко.)

Див. Розділ Налаштування автоматичного резервного копіювання для програм на developer.android.com, щоб отримати опис використання нового API.

Question 7

Одним із варіантів буде його побудова в логіці програми над базою даних. Я думаю, це насправді кричить про такий рівень. Не впевнений, що ви вже це робите, але більшість людей (незважаючи на підхід до курсора управління вмістом android) запровадять певне зіставлення ORM - або користувальницький, або якийсь підхід orm-lite. І що я волів би зробити в цьому випадку, це:

щоб переконатися, що ваша програма працює нормально, коли додаток / дані додаються у фоновому режимі та додають / видаляють нові дані, коли програма вже запущена
зробити якесь Java-> protobuf або навіть просто відображення серіалізації Java та написати свій власний BackupHelper, щоб прочитати дані з потоку та просто додати їх до бази даних ....

Тож у цьому випадку замість того, щоб робити це на рівні db, робіть це на рівні програми.