)]}'
{
  "log": [
    {
      "commit": "a23b343299783e5990370579cfc7d93e62dacb8d",
      "tree": "e0050572e321d7b3bbf1ac22e0e84a93bc13bfb0",
      "parents": [
        "9492947a5970325c494872324078b898868b9403"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Thu Apr 12 16:38:02 2012 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Thu Apr 12 17:52:03 2012 -0700"
      },
      "message": "Fix full backup/restore detection of encrypted devices\n\nThe confirmation UI did not request the needed permission, so was failing\nto communicate with the mount service; as a \"safe\" failure mode, it was\nassuming the device was encrypted.  Fixed; now it presents the correct\nprompt text for the device\u0027s encryption state.\n\nBug 5958195\n\nChange-Id: Ic03db16673b89d3377e0362a09cf51bfb572d78b\n"
    },
    {
      "commit": "c58cf7dd02ad227a68d62a0204152cee62c13182",
      "tree": "5e73b0f770f20d60a7a12a7b959cff289c0fb1b4",
      "parents": [
        "651cdfcbac6245f570475991588ddc2d30265e8d"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue Sep 13 17:51:18 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue Sep 13 17:51:18 2011 -0700"
      },
      "message": "Give backup/restore confirmation a proper window title\n\nSince the confirmation uses the same Activity but different layouts\nfor the backup vs restore cases, we have to do the title in code.\n\nAlong the way, fix the restore layout\u0027s padding [the backup layout\nwas already right].\n\nFixes bug 5164470\n\nChange-Id: I4d636f666d97fc377e9cf36abf08d1625a05577f\n"
    },
    {
      "commit": "a858cb075d0c87e2965d401656ff2d5bc16406da",
      "tree": "a184d02d871a906a5b3192bcec5f3495a2a97f21",
      "parents": [
        "507fc54924af53635e8d5520e5836c046af00775"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Fri Jun 03 12:27:51 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Fri Jun 03 14:06:46 2011 -0700"
      },
      "message": "Respect android:allowBackup\u003d\"false\" during full backup \u0026 restore\n\nPackages with this manifest attribute set \u0027false\u0027 will not be backed\nup even through the \"full device backup\" infrastructure.  If someone\nproduces an apparent restore file with data for such an application,\nit will not actually be restored onto the device.\n\nWhen an apk is installed during the course of a restore operation,\nit is validated against the manifest contents and deleted if there\nis a mismatch.  Also, if the newly-installed app is found to\ndisallow backups, no file content will be processed for that app.\n\nBug 4532159\n\nChange-Id: I59630054584b1394e567de939192e22e597044ee\n"
    },
    {
      "commit": "4a627c71ff53a4fca1f961f4b1dcc0461df18a06",
      "tree": "270190b1e030424210b6375ca886c45db10c4fb6",
      "parents": [
        "2bb51bb203c117649db10ad8bd497f199ca797b0"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Fri Apr 01 14:43:32 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue May 10 17:52:51 2011 -0700"
      },
      "message": "Full local backup infrastructure\n\nThis is the basic infrastructure for pulling a full(*) backup of the\ndevice\u0027s data over an adb(**) connection to the local device.  The\nbasic process consists of these interacting pieces:\n\n1. The framework\u0027s BackupManagerService, which coordinates the\n   collection of app data and routing to the destination.\n\n2. A new framework-provided BackupAgent implementation called\n   FullBackupAgent, which is instantiated in the target applications\u0027\n   processes in turn, and knows how to emit a datastream that contains\n   all of the app\u0027s saved data files.\n\n3. A new shell-level program called \"bu\" that is used to bridge from\n   adb to the framework\u0027s Backup Manager.\n\n4. adb itself, which now knows how to use \u0027bu\u0027 to kick off a backup\n   operation and pull the resulting data stream to the desktop host.\n\n5. A system-provided application that verifies with the user that\n   an attempted backup/restore operation is in fact expected and to\n   be allowed.\n\nThe full agent implementation is not used during normal operation of\nthe delta-based app-customized remote backup process.  Instead it\u0027s\nused during user-confirmed *full* backup of applications and all their\ndata to a local destination, e.g. via the adb connection.\n\nThe output format is \u0027tar\u0027.  This makes it very easy for the end\nuser to examine the resulting dataset, e.g. for purpose of extracting\nfiles for debug purposes; as well as making it easy to contemplate\nadding things like a direct gzip stage to the data pipeline during\nbackup/restore.  It also makes it convenient to construct and maintain\nsynthetic backup datasets for testing purposes.\n\nWithin the tar format, certain artificial conventions are used.\nAll files are stored within top-level directories according to\ntheir semantic origin:\n\napps/pkgname/a/  : Application .apk file itself\napps/pkgname/obb/: The application\u0027s associated .obb containers\napps/pkgname/f/  : The subtree rooted at the getFilesDir() location\napps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent\napps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent\napps/pkgname/r/  : Files stored relative to the root of the app\u0027s file tree\napps/pkgname/c/  : Reserved for the app\u0027s getCacheDir() tree; not stored.\n\nFor each package, the first entry in the tar stream is a file called\n\"_manifest\", nominally rooted at apps/pkgname.  This file contains some\nmetadata about the package whose data is stored in the archive.\n\nThe contents of shared storage can optionally be included in the tar\nstream. It is placed in the synthetic location:\n\nshared/...\n\nuid/gid are ignored; app uids are assigned at install time, and the\napp\u0027s data is handled from within its own execution environment, so\nwill automatically have the app\u0027s correct uid.\n\nForward-locked .apk files are never backed up.  System-partition\n.apk files are not backed up unless they have been overridden by a\npost-factory upgrade, in which case the current .apk *is* backed up --\ni.e. the .apk that matches the on-disk data.  The manifest preceding\neach application\u0027s portion of the tar stream provides version numbers\nand signature blocks for version checking, as well as an indication\nof whether the restore logic should expect to install the .apk before\nextracting the data.\n\nSystem packages can designate their own full backup agents.  This is\nto manage things like the settings provider which (a) cannot be shut\ndown on the fly in order to do a clean snapshot of their file trees,\nand (b) manage data that is not only irrelevant but actively hostile\nto non-identical devices -- CDMA telephony settings would seriously\nmess up a GSM device if emplaced there blind, for example.\n\nWhen a full backup or restore is initiated from adb, the system will\npresent a confirmation UI that the user must explicitly respond to\nwithin a short [~ 30 seconds] timeout.  This is to avoid the\npossibility of malicious desktop-side software secretly grabbing a copy\nof all the user\u0027s data for nefarious purposes.\n\n(*) The backup is not strictly a full mirror.  In particular, the\n    settings database is not cloned; it is handled the same way that\n    it is in cloud backup/restore.  This is because some settings\n    are actively destructive if cloned onto a different (or\n    especially a different-model) device: telephony settings and\n    AndroidID are good examples of this.\n\n(**) On the framework side it doesn\u0027t care that it\u0027s adb; it just\n    sends the tar stream to a file descriptor.  This can easily be\n    retargeted around whatever transport we might decide to use\n    in the future.\n\nKNOWN ISSUES:\n\n* the security UI is desperately ugly; no proper designs have yet\n  been done for it\n* restore is not yet implemented\n* shared storage backup is not yet implemented\n* symlinks aren\u0027t yet handled, though some infrastructure for\n  dealing with them has been put in place.\n\nChange-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91\n"
    }
  ]
}