d1475e0375
Restore runs during the SetupWizard, before the phone is usable per se, so we want to avoid presenting the usual "Application whatever has crashed..." dialog to the user in the middle of that process. This change modifies the exception handling around agent bringup so that agent-originated exceptions are caught and a null agent binder reported to the backup manager. There are three points during this code sequence at which an exception can be thrown due to application-code error: + the app's manifest can name a nonexistent or malformed BackupAgent class, incurring a VM-level exception like ClassNotFound or BadCast. - the agent's onCreate() method could crash/throw. - the agent's onBind() method could crash/throw. The new code arrangement here puts a try/catch around all of these possible failure points. When the code is invoked for backup, any caught exception is merely rethrown. During restore, however, execution is allowed to proceed through reporting the app's agent binder back to the activity manager. If any exception was thrown, this reported binder will be null, i.e. a clean failure notification to the backup manager. What this code does *not* do at present is tear down the app when an exception has been thrown. This is happens if the exception is allowed to propagate. Doing so cleanly is problematic, however, in circumstances where mutiple apps and agents share a process. Leaving the background process around until it is torn down by the usual policies is probably the safer course at present.