BackupManagerService分析 基于Android 8.0

最近遇到BackupManagerService备份恢复后桌面小部件重复添加达到800个之多的问题,严重影响系统体验,所以抽出半天时间进行分析.

废话不多说先看下BackupManagerService dump出来的信息从中窥探它的大概原理以及结构

DUMP OF SERVICE backup:
Backup Manager is enabled / provisioned / not pending init
Auto-restore is enabled
Last backup pass started: 0 (now = 1516085568739)
next scheduled: 1516056771175
Transport whitelist:
android/com.android.internal.backup.LocalTransportService
com.google.android.gms/.backup.component.D2dTransportService
com.google.android.gms/.backup.BackupTransportService
Available transports:
android/com.android.internal.backup.LocalTransport
destination: Backing up to debug-only private cache
intent: null
com.google.android.gms/.backup.migrate.service.D2dTransport
destination: Moving data to new device
intent: null
* com.google.android.gms/.backup.BackupTransportService
destination: hackerdevdas@gmail.com
intent: Intent { cmp=com.google.android.gms/.backup.SetBackupAccountActivity }
@pm@ - 3086 state bytes
com.google.android.apps.maps - 124 state bytes
android - 477 state bytes
com.google.android.apps.messaging - 124 state bytes
com.android.cellbroadcastreceiver - 116 state bytes
com.google.android.googlequicksearchbox - 116 state bytes
com.google.android.videos - 72 state bytes
com.google.android.googlequicksearchbox_widget - 95 state bytes
com.google.android.contacts - 124 state bytes
com.android.providers.settings - 84 state bytes
Pending init: 0
Ancestral: 0
Current:   3fea8d5038fd8e55
Participants:
uid: 1000
com.android.providers.settings
android
uid: 10000
com.android.providers.blockednumber
com.android.calllogbackup
com.android.providers.userdictionary
uid: 10009
com.android.cellbroadcastreceiver
uid: 10012
Ancestral packages: none
Ever backed up: 28
com.google.android.apps.maps
android
com.google.android.apps.messaging
com.android.cellbroadcastreceiver
com.google.android.googlequicksearchbox
com.google.android.videos
com.google.android.contacts
com.android.providers.settings
com.google.android.marvin.talkback
com.google.android.play.games
com.android.calllogbackup
com.google.android.apps.inputmethod.hindi
Pending key/value backup: 31
BackupRequest{pkg=com.google.android.apps.maps}
BackupRequest{pkg=android}
BackupRequest{pkg=com.google.android.apps.messaging}
BackupRequest{pkg=com.android.cellbroadcastreceiver}
BackupRequest{pkg=com.google.android.googlequicksearchbox}
BackupRequest{pkg=com.google.android.videos}
BackupRequest{pkg=com.google.android.contacts}
BackupRequest{pkg=com.android.providers.settings}
Full backup queue:68
0 : com.studio71.sunday_suspense
0 : com.qapp.secprotect
0 : se.dirac.acs
0 : com.android.bips
0 : com.android.carrierdefaultapp
0 : com.qti.vzw.ims.internal.tests
0 : com.qualcomm.timeservice
1511525714741 : com.google.android.ext.services
1511525862187 : com.android.launcher3
1511526633498 : com.google.android.backuptransport
1511530346032 : com.android.smspush
1511606005489 : com.lenovo.anyshare.gps
1511606022751 : com.graymatrix.did
1511606025293 : com.jio.media.ondemand
1511606027829 : com.android.cts.priv.ctsshim
--------- 0.013s was the duration of dumpsys backup

首先可以肯定BackupManagerService肯定是一个调度框架

其次它调度什么呢,肯定是Transport,这里可以看到有白名单,和可用的 transports,还有Transport执行任务的历史数据.

另外后面的几项信息

Pending init是什么? 从字意思看应该是待执行的初始化

Participants是参加者的含义到底是用来做什么的?

Ancestral字面意思是先祖,到底是干什么用的

另外三项好像还比较理解

Ever backed up:

Pending key/value backup 延时的keyvalue 备份

Full backup queue 完全备份队列

好了带着这些疑问我们进行分析.

public BackupManagerService(Context context, Trampoline parent) {
......
mBackupManagerBinder = Trampoline.asInterface(parent.asBinder());
....
Set<ComponentName> transportWhitelist = systemConfig.getBackupTransportWhitelist();

String transport = Settings.Secure.getString(context.getContentResolver(),
Settings.Secure.BACKUP_TRANSPORT);
......
mTransportManager = new TransportManager(context, transportWhitelist, currentTransport,
mTransportBoundListener, mHandlerThread.getLooper());
mTransportManager.registerAllTransports();
......
}

值得注意的是Trampoline是真正实现IBackupManager.Stub接口的类,向外部提供服务. 另外TransportManager可定是用于管理transport的,这里进行初始化.我们看下初始化逻辑

TransportManager(Context context, Set<ComponentName> whitelist, String defaultTransport,
TransportBoundListener listener, Looper looper) {
mContext = context;
mPackageManager = context.getPackageManager();
mTransportWhitelist = (whitelist != null) ? whitelist : new ArraySet<>();
mCurrentTransportName = defaultTransport;
mTransportBoundListener = listener;
mHandler = new RebindOnTimeoutHandler(looper);
}

只是简单的赋值,这里面连个关键的数据whitelist和defaultTransport已经传进来了.

我们再看一下TransportManager.registerAllTransports()函数,注意参数都null

private final Intent mTransportServiceIntent = new Intent(SERVICE_ACTION_TRANSPORT_HOST);
private static final String SERVICE_ACTION_TRANSPORT_HOST = "android.backup.TRANSPORT_HOST";

private void bindToAllInternal(String packageName, String[] components) {
PackageInfo pkgInfo = null;
...
Intent intent = new Intent(mTransportServiceIntent);
if (packageName != null) {
intent.setPackage(packageName);
}

List<ResolveInfo> hosts = mPackageManager.queryIntentServicesAsUser(
intent, 0, UserHandle.USER_SYSTEM);
if (hosts != null) {
for (ResolveInfo host : hosts) {
final ComponentName infoComponentName = host.serviceInfo.getComponentName();
boolean shouldBind = false;
if (components != null && packageName != null) {
for (String component : components) {
ComponentName cn = new ComponentName(pkgInfo.packageName, component);
if (infoComponentName.equals(cn)) {
shouldBind = true;
break;
}
}
} else {
shouldBind = true;
}
if (shouldBind && isTransportTrusted(infoComponentName)) {
tryBindTransport(infoComponentName);
}
}
}
}
private void tryBindTransport(ComponentName transportComponentName) {
Slog.d(TAG, "Binding to transport: " + transportComponentName.flattenToShortString());
// TODO: b/22388012 (Multi user backup and restore)
TransportConnection connection = new TransportConnection(transportComponentName);
if (bindToTransport(transportComponentName, connection)) {
synchronized (mTransportLock) {
mValidTransports.put(transportComponentName, connection);
}
} else {
Slog.w(TAG, "Couldn't bind to transport " + transportComponentName);
}
}

代码也很简单, 查询Action是android.backup.TRANSPORT_HOST的service,如果查询到的组件在白名单且是预装在priv-app下的应用,则认为是可以新人的组件,绑定它的service,绑定的过程很简单我们看下绑定完成执行的onServiceConnected函数,代码在frameworks/base/services/backup/java/com/android/server/backup/TransportManager.java文件中.

success = mTransportBoundListener.onTransportBound(mBinder);
mBoundTransports.put(mTransportName, component);

添加到mBoundTransports集合里面,代表已经绑定成功,另外绑定成功后又添加到mValidTransports中代表组件可用.

另外执行了mTransportBoundListener的回调,函数的代码在BackupManagerService类中.是一个内部成员类

private TransportManager.TransportBoundListener mTransportBoundListener =
new TransportManager.TransportBoundListener() {
@Override
public boolean onTransportBound(IBackupTransport transport) {
// If the init sentinel file exists, we need to be sure to perform the init
// as soon as practical.  We also create the state directory at registration
// time to ensure it's present from the outset.
String name = null;
try {
name = transport.name();
String transportDirName = transport.transportDirName();
File stateDir = new File(mBaseStateDir, transportDirName);
stateDir.mkdirs();

File initSentinel = new File(stateDir, INIT_SENTINEL_FILE_NAME);
if (initSentinel.exists()) {
synchronized (mQueueLock) {
mPendingInits.add(name);

// TODO: pick a better starting time than now + 1 minute
long delay = 1000 * 60; // one minute, in milliseconds
mAlarmManager.set(AlarmManager.RTC_WAKEUP,
System.currentTimeMillis() + delay, mRunInitIntent);
}
}
return true;
} catch (Exception e) {
// the transport threw when asked its file naming prefs; declare it invalid
Slog.w(TAG, "Failed to regiser transport: " + name);
return false;
}
}
};

这里检查/data/backup/${transportDirName}/need_init文件是否存在,如果存在则建立一个mPendingInits任务,一分钟后唤醒执行mRunInitIntent描述的一个广播任务. 可见mRunInitIntent所描述的任务肯定是用于处理mPendingInits的. 另外${transportDirName}为绑定的transport自己定义的路径. 第一次绑定肯定不会有这个文件的,所以我们先不去分析初始化任务.

BackupManagerService如何启动还没有分析,这里就不去翻SystemServer代码了,是通过

BackupManagerService.Lifecycle启动的,Lifecycle实现了SystemService

public static final class Lifecycle extends SystemService {

public Lifecycle(Context context) {
super(context);
sInstance = new Trampoline(context);
}

@Override
public void onStart() {
publishBinderService(Context.BACKUP_SERVICE, sInstance);
}

@Override
public void onUnlockUser(int userId) {
if (userId == UserHandle.USER_SYSTEM) {
sInstance.initialize(userId);

// Migrate legacy setting
if (!backupSettingMigrated(userId)) {
if (DEBUG) {
Slog.i(TAG, "Backup enable apparently not migrated");
}
final ContentResolver r = sInstance.mContext.getContentResolver();
final int enableState = Settings.Secure.getIntForUser(r,
Settings.Secure.BACKUP_ENABLED, -1, userId);
if (enableState >= 0) {
if (DEBUG) {
Slog.i(TAG, "Migrating enable state " + (enableState != 0));
}
writeBackupEnableState(enableState != 0, userId);
Settings.Secure.putStringForUser(r,
Settings.Secure.BACKUP_ENABLED, null, userId);
} else {
if (DEBUG) {
Slog.i(TAG, "Backup not yet configured; retaining null enable state");
}
}
}

try {
sInstance.setBackupEnabled(readBackupEnableState(userId));
} catch (RemoteException e) {
// can't happen; it's a local object
}
}
}
}

启动直到onUnlockUser后就能读取到非dirctBoot的service了sInstance.initialize(userId);函数就是用于创建BackupManagerService,做初始化操作. 之后要根据backup_enabled值去写/data/backup/backup_enabled文件,别问我为啥还要做这一步周转,我目前也不知道,我们慢慢分析.

接下来,整个初始化的关键,让整个系统跑起来的关键就在 sInstance.setBackupEnabled(readBackupEnableState(userId));这一步.会调用到BackupManagerService的setBackupEnabled函数.

public void setBackupEnabled(boolean enable) {
......
boolean wasEnabled = mEnabled;
synchronized (this) {
writeBackupEnableState(enable, UserHandle.USER_SYSTEM);
mEnabled = enable;
}

synchronized (mQueueLock) {
if (enable && !wasEnabled && mProvisioned) {
// if we've just been enabled, start scheduling backup passes
KeyValueBackupJob.schedule(mContext);
scheduleNextFullBackupJob(0);
} else if (!enable) {

KeyValueBackupJob.cancel(mContext);

if (wasEnabled && mProvisioned) {
// NOTE: we currently flush every registered transport, not just
// the currently-active one.
String[] allTransports = mTransportManager.getBoundTransportNames();
// build the set of transports for which we are posting an init
for (String transport : allTransports) {
recordInitPendingLocked(true, transport);
}
mAlarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(),
mRunInitIntent);
}
}
}
}
...
}

在开启状态的时候会执行 KeyValueBackupJob.schedule(mContext);

scheduleNextFullBackupJob(0); 函数,这是整个系统跑起来的关键,为了防止读代码时候太跳跃我们先看下变成不可用的情况,给每个allTransports添加了一个mPendingInit任务,并要求马上执行.

这下就可以看两个schedule函数了.

先看KeyValueBackupJob,代码在frameworks/base/services/backup/java/com/android/server/backup/KeyValueBackupJob.java中

private static ComponentName sKeyValueJobService =
new ComponentName("android", KeyValueBackupJob.class.getName());
public static void schedule(Context ctx, long delay) {
synchronized (KeyValueBackupJob.class) {
if (!sScheduled) {
if (delay <= 0) {
delay = BATCH_INTERVAL + new Random().nextInt(FUZZ_MILLIS);
}
if (BackupManagerService.DEBUG_SCHEDULING) {
Slog.v(TAG, "Scheduling k/v pass in "
+ (delay / 1000 / 60) + " minutes");
}
JobScheduler js = (JobScheduler) ctx.getSystemService(Context.JOB_SCHEDULER_SERVICE);
JobInfo.Builder builder = new JobInfo.Builder(JOB_ID, sKeyValueJobService)
.setMinimumLatency(delay)
.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY)
.setRequiresCharging(true)
.setOverrideDeadline(MAX_DEFERRAL);
js.schedule(builder.build());

sNextScheduled = System.currentTimeMillis() + delay;
sScheduled = true;
}
}
}

这里添加了一个JobScheduler任务,延时4个小时到一天,真正执行任务的service是sKeyValueJobService(其实就是KeyValueBackupJob这个service),并且需要插电. 可见备份事件还是不太紧急的

public boolean onStartJob(JobParameters params) {
synchronized (KeyValueBackupJob.class) {
sNextScheduled = 0;
sScheduled = false;
}

// Time to run a key/value backup!
Trampoline service = BackupManagerService.getInstance();
try {
service.backupNow();
} catch (RemoteException e) {}

// This was just a trigger; ongoing wakelock management is done by the
// rest of the backup system.
return false;
}

这里只是调用了BackupManagerService.backupNow()函数.

Intent backupIntent = new Intent(RUN_BACKUP_ACTION);
backupIntent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
mRunBackupIntent = PendingIntent.getBroadcast(context, MSG_RUN_BACKUP, backupIntent, 0);
public void backupNow() {
......
final PowerSaveState result =
mPowerManager.getPowerSaveState(ServiceType.KEYVALUE_BACKUP);
if (result.batterySaverEnabled) {
if (DEBUG) Slog.v(TAG, "Not running backup while in battery save mode");
KeyValueBackupJob.schedule(mContext);   // try again in several hours
} else {
if (DEBUG) Slog.v(TAG, "Scheduling immediate backup pass");
synchronized (mQueueLock) {
mRunBackupIntent.send();
......
// ...and cancel any pending scheduled job, because we've just superseded it
KeyValueBackupJob.cancel(mContext);
}
}
}

函数发了一个mRunBackupIntent描述的pendingIntent任务,然后取消job,我们来看看如何处理这个任务

在RunBackupReceiver内部实例中处理该广播RUN_BACKUP_ACTION

private class RunBackupReceiver extends BroadcastReceiver {
public void onReceive(Context context, Intent intent) {
if (RUN_BACKUP_ACTION.equals(intent.getAction())) {
synchronized (mQueueLock) {
if (mPendingInits.size() > 0) {
.....
} else {
if (mEnabled && mProvisioned) {
if (!mBackupRunning) {
mBackupRunning = true;
mWakelock.acquire();
Message msg = mBackupHandler.obtainMessage(MSG_RUN_BACKUP);
mBackupHandler.sendMessage(msg);
} else {
Slog.i(TAG, "Backup time but one already running");
}
} else {
Slog.w(TAG, "Backup pass but e=" + mEnabled + " p=" + mProvisioned);
}
}
}
}
}
}

这里有遇到了mPendingInits我们先不管它,直接分析else部分,如果备份可用并且当前没有正在运行的备份任务,就发送一个MSG_RUN_BACKUP给后台线程的handler处理

处理这个消息的部分在BackupManagerService的内部实例BackupHandler的handleMessage中,这部分代码也比较长.

ArrayList<BackupRequest> queue = new ArrayList<BackupRequest>();
File oldJournal = mJournal;
synchronized (mQueueLock) {
if (mPendingBackups.size() > 0) {
for (BackupRequest b: mPendingBackups.values()) {
queue.add(b);
}
mPendingBackups.clear();
// Start a new backup-queue journal file too
......
}
}
if (queue.size() > 0) {
// Spin up a backup state sequence and set it running
......
PerformBackupTask pbt = new PerformBackupTask(transport, dirName, queue,
oldJournal, null, null, Collections.<String>emptyList(), false,
false /* nonIncremental */);
Message pbtMessage = obtainMessage(MSG_BACKUP_RESTORE_STEP, pbt);
sendMessage(pbtMessage);

其实逻辑很简单,就是收集mPendingBackups放到queue集合里面.并创建PerformBackupTask作为一个备份任务去,并创建MSG_BACKUP_RESTORE_STEP去执行,这里只是因为分步去做才又进行了一次倒手,其实处理该任务的handler还是这个线程同一个handler. 我们先不管mPendingBackups哪里来的,这里告诉读者,是允许备份的包护数据变化后会通知BackupManagerService并添加PendingBackup任务.我们先去分析如何执行备份任务,回来在分析任务的添加过程.

case MSG_BACKUP_RESTORE_STEP:
{
try {
BackupRestoreTask task = (BackupRestoreTask) msg.obj;
if (MORE_DEBUG) Slog.v(TAG, "Got next step for " + task + ", executing");
task.execute();
} catch (ClassCastException e) {
Slog.e(TAG, "Invalid backup task in flight, obj=" + msg.obj);
}
break;
}

这里task实际类型为PerformBackupTask,我们只需要看下它的execute()函数就能知道其中逻辑.

public void execute() {
synchronized (mCancelLock) {
switch (mCurrentState) {
case INITIAL:
beginBackup();
break;

case RUNNING_QUEUE:
invokeNextAgent();
break;

case FINAL:
if (!mFinished) finalizeBackup();
else {
Slog.e(TAG, "Duplicate finish");
}
mFinished = true;
break;
}
}
}

这里要执行的是void beginBackup()函数