)]}'
{
  "log": [
    {
      "commit": "9ff53a7100b1a40f5d2df3eb19a2f3f2fff39a46",
      "tree": "162c23a51e116f9506e7d6801236dd2e2c8f3788",
      "parents": [
        "ad60891a6ecaf2a5815677b33e96afe7f49ee113"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue Jun 03 17:20:07 2014 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Sun Jun 15 17:35:33 2014 -0700"
      },
      "message": "Implement full data backup through transport\n\nCurrently no timed/scheduled full-data backup operations are\nperformed by the OS, but the plumbing is now in place and can\nbe tested using \u0027adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]\u0027.\n\nThe LocalTransport test transport implementation has been augmented\nto support the new full-data backup API as well.\n\nIn addition, \u0027adb backup\u0027 now takes the -compress/-nocompress\ncommand line options to control whether the resulting archive is\ncompressed before leaving the device.  Previously the archive was\nalways compressed.  (The default is still to compress, as it will\nusually reduce the archive size considerably.)\n\nInternally, the core implementation of gathering the full backup\ndata stream from the target application has been refactored into\nan \"engine\" component that is shared by both \u0027adb backup\u0027 and the\ntransport-oriented full backup task.  The archive file header\ngeneration, encryption, and compression logic are now factored out\nof the engine itself instead of being hardwired into the data\nhandling.\n\nBug 15329632\n\nChange-Id: I4a044faa4070d684ef457bd3e11771198cdf557c\n"
    },
    {
      "commit": "a312c03fd830c489ffc81fad0812826b093b73ee",
      "tree": "7562a82de9ab19ffa0f1f5a2f9c9b83f91b81257",
      "parents": [
        "05ad48206a082057e17723d32493c153faa6881e"
      ],
      "author": {
        "name": "Jeff Sharkey",
        "email": "jsharkey@android.com",
        "time": "Thu May 29 18:03:22 2014 -0700"
      },
      "committer": {
        "name": "Jeff Sharkey",
        "email": "jsharkey@android.com",
        "time": "Thu May 29 18:03:22 2014 -0700"
      },
      "message": "Read data from stdin/stdout to follow adb change.\n\nChange-Id: I29ee5e05a538c6836f18b9cc9331c74f41936b29\n"
    },
    {
      "commit": "adfe8b86e9178a553b6db9722340fa4ff5201cf1",
      "tree": "2054d99dc17b0ada61693b97d9f3e306b4fe4d4a",
      "parents": [
        "aef4f6ebc8f8eb1f9fbfbe4ae2556c9f1a26a63c"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue Feb 04 16:23:32 2014 -0800"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Thu Mar 20 12:30:51 2014 -0700"
      },
      "message": "App widget backup/restore infrastructure\n\nBackup/restore now supports app widgets.\n\nAn application involved with app widgets, either hosting or publishing,\nnow has associated data in its backup dataset related to the state of\nwidget instantiation on the ancestral device.  That data is processed\nby the OS during restore so that the matching widget instances can be\n\"automatically\" regenerated.\n\nTo take advantage of this facility, widget-using apps need to do two\nthings:  first, implement a backup agent and store whatever widget\nstate they need to properly deal with them post-restore (e.g. the\nwidget instance size \u0026 location, for a host); and second, implement\nhandlers for new AppWidgetManager broadcasts that describe how to\ntranslate ancestral-dataset widget id numbers to the post-restore\nworld.  Note that a host or provider doesn\u0027t technically need to\nstore *any* data on its own via its agent; it just needs to opt in\nto the backup/restore process by publishing an agent.  The OS will\nthen store a small amount of data on behalf of each widget-savvy\napp within the backup dataset, and act on that data at restore time.\n\nThe broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and\nACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:\n\n    EXTRA_APPWIDGET_OLD_IDS\n    EXTRA_APPWIDGET_IDS\n    EXTRA_HOST_ID [for the host-side broadcast]\n\nThe first two are same-sized arrays of integer widget IDs.  The\n_OLD_IDS values are the widget IDs as known to the ancestral device.\nThe _IDS array holds the corresponding widget IDs in the new post-\nrestore environment.  The app should simply update the stored\nwidget IDs in its bookkeeping to the new values, and things are\noff and running.  The HOST_ID extra, as one might expect, is the\napp-defined host ID value of the particular host instance which\nhas just been restored.\n\nThe broadcasts are sent following the conclusion of the overall\nrestore pass.  This is because the restore might have occurred in a\ntightly restricted lifecycle environment without content providers\nor the package\u0027s custom Application class.  The _RESTORED broadcast,\nhowever, is always delivered into a normal application environment,\nso that the app can use its content provider etc as expected.\n\n*All* widget instances that were processed over the course of the\nsystem restore are indicated in the _RESTORED broadcast, even if\nthe backing provider or host is not yet installed.  The widget\nparticipant is responsible for understanding that these are\npromises that might be fulfilled later rather than necessarily\nreflecting the immediate presentable widget state.  (Remember\nthat following a cloud restore, apps may be installed piecemeal\nover a lengthy period of time.)  Telling the hosts up front\nabout all intended widget instances allows them to show placeholder\nUI or similarly useful information rather than surprising the user\nwith piecemeal unexpected appearances.\n\nThe AppWidgetProvider helper class has been updated to add a new\ncallback, onRestored(...), invoked when the _RESTORED broadcast\nis received.  The call to onRestored() is immediately followed by\nan invocation of onUpdate() for the affected widgets because\nthey will need to have their RemoteViews regenerated under the\nnew ID values.\n\nBug 10622506\nBug 10707117\n\nChange-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b\n"
    },
    {
      "commit": "46cc43c6fa7623820d4ae9149496cf96bb15f8a3",
      "tree": "fe3a33bcdf0dc82414eb274aedefaef53aace059",
      "parents": [
        "32884c376fd06799f46ea3b1ded89ba9d21f8f14"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue Feb 19 14:08:59 2013 -0800"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Thu Mar 07 13:47:20 2013 -0800"
      },
      "message": "Full backup/restore now handles OBBs sensibly\n\nOBB backup/ restore is no longer handled within the target app\nprocess.  This is done to avoid having to require that OBB-using\napps have full read/write permission for external storage.\n\nThe new OBB backup service is a new component running in the\nsame app as the already-existing shared storage backup agent.\nThe backup infrastructure delegates backup/restore of apps\u0027\nOBB contents to this component (because the system process\nmay not itself read/write external storage).\n\nFrom the command line, OBB backup is enabled by using new\n-obb / -noobb flags with adb backup.  The default is noobb.\n\nFinally, a couple of nit fixes:\n\n- buffer-size mismatch between the writer and reader of chunked\n  file data has been corrected; now the reading side won\u0027t be\n  issuing an extra pipe read per chunk.\n\n- bu now explicitly closes the transport socket fd after\n  adopting it. This was benign but triggered a logged\n  warning about leaked fds.\n\nBug: 6718844\nChange-Id: Ie252494e2327e9ab97cf9ed87c298410a8618492\n"
    },
    {
      "commit": "240c7d2d1fb2944ee6a6f1dee41c7bbd766f8f0d",
      "tree": "1e512dba224bc80c1eeb58411b7d508317699958",
      "parents": [
        "be25ca2997ab98e1257d5625dd510e643dcead95"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Mon Oct 03 18:13:44 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Tue Oct 04 15:35:00 2011 -0700"
      },
      "message": "Add -nosystem flag to adb backup\n\nThis makes it easy to back up everything that belongs to 3rd party apps, but\nnothing that comes with the system per se.  If any system packages are\nexplicitly named on the command line they will be included in the backup\neven if -nosystem was passed.  So, for example, this will back up all 3rd\nparty apps as well as system settings, but nothing else belonging to\nsystem-deployed apps:\n\n   adb backup -all -nosystem com.android.provider.settings\n\nBug 5361503\n\nChange-Id: Iebe04b7d7027ca58b9f55e8eb7f219d6cca69269\n"
    },
    {
      "commit": "e26e96bcc19b1cdac690d21b3986f09a502739e6",
      "tree": "cd6054763d0a2043088027f9cac129ecef27beb0",
      "parents": [
        "3106a9b7f5c5c6a62d3fa5772d8c2bb41d22c6eb"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Fri Jun 10 18:33:16 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Mon Jun 20 19:26:31 2011 -0700"
      },
      "message": "Pass the data fd number as a command line argument to \u0027bu\u0027\n\nThis way we don\u0027t have to muck with stdin/stdout just to get known\nfds for data handling.\n\nChange-Id: If87d19f4867c883a32d4e9afb91b915511b9df19\n"
    },
    {
      "commit": "75a99709accef8cf221fd436d646727e7c8dd1f1",
      "tree": "9ce16dbf95890e8dad57d63724a6cdb3d36d6fb9",
      "parents": [
        "2978cef0a77550ea3a364ffbf42fc43f2029070e"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Wed May 18 16:28:19 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Wed Jun 01 15:09:55 2011 -0700"
      },
      "message": "Restore from a previous full backup\u0027s tarfile\n\nUsage:  adb restore [tarfilename]\n\nRestores app data [and installs the apps if necessary from the backup\nfile] captured in a previous invocation of \u0027adb backup\u0027.  The user\nmust explicitly acknowledge the action on-device before it is allowed\nto proceed; this prevents any \"invisible\" pushes of content from the\nhost to the device.\n\nKnown issues:\n\n* The settings databases and wallpaper are saved/restored, but lots\n  of other system state is not yet captured in the full backup.  This\n  means that for practical purposes this is usable for 3rd party\n  apps at present but not for full-system cloning/imaging.\n\nChange-Id: I0c748b645845e7c9178e30bf142857861a64efd3\n"
    },
    {
      "commit": "14a2935809e73a9d824888dc837f2f017100fd26",
      "tree": "408f6decede257f9c219355bb470906fefac84f1",
      "parents": [
        "4383243d0067d76a07966ff2178ea4d0c20271d3"
      ],
      "author": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Mon May 16 16:22:06 2011 -0700"
      },
      "committer": {
        "name": "Christopher Tate",
        "email": "ctate@google.com",
        "time": "Mon May 16 16:57:32 2011 -0700"
      },
      "message": "bu - add handling for both \u0027backup\u0027 and \u0027restore\u0027 modes\n\nRequires a parallel change in adb to support the new syntax.\n\nChange-Id: Iff30cb247e424b6817af121c018f3c4e40b9f81a\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"
    }
  ]
}