Tighten restore-at-install behavior

Harden the guarantee that if we're asked about a possible restore,
we always ALWAYS report back to the package manager.  This involved
closing "should never happen" edge cases around provisioning/auto-restore
setting that nevertheless were happening.

Also, on the auto-restore setting front, make sure to plumb that
system API through appropriately, since going behind its back and
manipulating the secure setting directly would cause things to get
out of step.

Bug 17060654

Change-Id: I52ca9c1ffbfc0bd6b57196157500d0868bfc2989

1 files changed, 22 insertions, 0 deletions

diff --git a/core/java/android/app/backup/BackupManager.java b/core/java/android/app/backup/BackupManager.java
index e9297b9..1bb4eba 100644
--- a/core/java/android/app/backup/BackupManager.java
+++ b/core/java/android/app/backup/BackupManager.java
@@ -229,6 +229,28 @@ public class BackupManager {
     }
 
     /**
+     * Enable/disable data restore at application install time.  When enabled, app
+     * installation will include an attempt to fetch the app's historical data from
+     * the archival restore dataset (if any).  When disabled, no such attempt will
+     * be made.
+     *
+     * <p>Callers must hold the android.permission.BACKUP permission to use this method.
+     *
+     * @hide
+     */
+    @SystemApi
+    public void setAutoRestore(boolean isEnabled) {
+        checkServiceBinder();
+        if (sService != null) {
+            try {
+                sService.setAutoRestore(isEnabled);
+            } catch (RemoteException e) {
+                Log.e(TAG, "setAutoRestore() couldn't connect");
+            }
+        }
+    }
+
+    /**
      * Identify the currently selected transport.  Callers must hold the
      * android.permission.BACKUP permission to use this method.
      * @return The name of the currently active backup transport.  In case of