Android startForeground 却无notification的黑科技原理分析 以及Android7.1的修复

契机：今天升级了Android7.1 beta版。然而升上去之后，国产的部分App简直丑态百出啊，给各位看看我的手机截图

啧啧，原来Android7.0以及以下干干净净的通知栏瞬间被这几个家伙占满。有句话说：潮水退去，才知道谁在裸泳啊。同样的，系统升级修复漏洞后，才赤果果地暴露出吃相呢。

开始进入正题：
startForeground啥效果我就不啰嗦了。
而国内大部分主流应用，其实都使用了Android的一个通知栏的bug，使得在调用startForegound之后在通知栏没有任何通知，而且进程同样处于低oom_adj状态。直到Android7.1才修复了这个漏洞。

首先是怎么做：这里代码参考https://github.com/D-clock/AndroidDaemonService
首先是一个主service，在这个service里的onstartCommand里头启动一个临时的GrayInnerService

Intent innerIntent = new Intent(this, GrayInnerService.class);
startService(innerIntent);
startForeground(GRAY_SERVICE_ID, new Notification());

随后在GrayInnerService的onstartCommand里头

startForeground(GRAY_SERVICE_ID, new Notification());
//stopForeground(true);
stopSelf();
return super.onStartCommand(intent, flags, startId);

看起来十分容易，总结关键点就是 一个进程里头的两个service同时用同一个ID来startForeground,然后其中一个自杀，就OK了。

原理的话也相当简单：
因为Android没有针对startForeground的ID的唯一性做判定，然后两个service对应了一个notification，然后其中一个自杀，会把这个Notification带走，所以我们看不见notification了，但是另一个处于foreground的service依然存活着！，只要存在一个foreground的service，那么这个进程的oomadj的值就比较底，就不容易被杀死

代码分析如下：

    public final void startForeground(int id, Notification notification) {
        try {
            mActivityManager.setServiceForeground(
                    new ComponentName(this, mClassName), mToken, id,
                    notification, true);
        } catch (RemoteException ex) {
        }
    }

跟踪setServiceForeground

585    public void setServiceForegroundLocked(ComponentName className, IBinder token,
586            int id, Notification notification, boolean removeNotification) {
587        final int userId = serHandle.getCallingUserId();
588        final long origId =Binder.clearCallingIdentity();
589        try {
590            ServiceRecord r = findServiceLocked(className, token, userId);//找到service对应的serviceRecord
591            if (r != null) {
592                if (id != 0) {
593                    if (notification == null) {
594                        throw new IllegalArgumentException("null notification");
595                    }
596                    if (r.foregroundId != id) {//这里并没有对id的进程内的唯一性做检查。只是单存地更新一下ID和notification而已
597                        r.cancelNotification();
598                        r.foregroundId = id;
599                    }
600                    notification.flags |= Notification.FLAG_FOREGROUND_SERVICE;
601                    r.foregroundNoti = notification;
602                    r.isForeground = true;
603                    r.postNotification();
604                    if (r.app != null) {
605                        updateServiceForegroundLocked(r.app, true);//走到这里！
606                    }
607                    getServiceMap(r.userId).ensureNotStartingBackground(r);
.....
}

注意本段代码已经出现了最最重要的关键点,Android只是简单地把startForeground传入的id记录在r.foregroundId ，而没有检查是否id之前是否被其他的foreground service使用过了·

然后调用updatServiceForeground：

630    private void updateServiceForegroundLocked(ProcessRecord proc, boolean oomAdj) {
631        boolean anyForeground = false;
632        for (int i=proc.services.size()-1; i>=0; i--) {
633            ServiceRecord sr = proc.services.valueAt(i);
634            if (sr.isForeground) {
635                anyForeground = true;
636                break;
637            }
638        }
639        mAm.updateProcessForegroundLocked(proc, anyForeground, oomAdj);
640    }

即检查本进程内有任意service为foreground状态，然后依据这个结果进入updateProcessForegroundLocked对进程进行后续调整：

18964    final void updateProcessForegroundLocked(ProcessRecord proc, boolean isForeground,
18965            boolean oomAdj) {
18966        if (isForeground != proc.foregroundServices) {
18967            proc.foregroundServices = isForeground;//更新ProcessRecord的foregroundServices
18968            ArrayList<ProcessRecord> curProcs = mForegroundPackages.get(proc.info.packageName,
18969                    proc.info.uid);
18970            if (isForeground) {
18971                if (curProcs == null) {
18972                    curProcs = new ArrayList<ProcessRecord>();
18973                    mForegroundPackages.put(proc.info.packageName, proc.info.uid, curProcs);
18974                }
18975                if (!curProcs.contains(proc)) {
18976                    curProcs.add(proc);
...电量统计相关...
18992            if (oomAdj) {
18993                updateOomAdjLocked(); //更新并应用进程oomadj的值
18994            }
18995        }
18996    }

分析就到updateOomAdjLocked为止了。后面就是一长串的oomadj计算并且将新的oomadj应用到本进程上了，这样进程就不被杀的优先级就提升了，以后如果有机会再详细说，这不是本章的重点。

还记得我们启动了两个相同id的service了吗，然后其中一个Service开始自杀。开始看自杀啦：

   public final void stopSelf(int startId) {
        if (mActivityManager == null) {
            return;
        }
        try {
            mActivityManager.stopServiceToken(
                    new ComponentName(this, mClassName), mToken, startId);
        } catch (RemoteException ex) {
        }
    }

    private void stopServiceLocked(ServiceRecord service) {
460        if (service.delayed) {
461            // If service isn't actually running, but is is being held in the
462            // delayed list, then we need to keep it started but note that it
463            // should be stopped once no longer delayed.
464            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "Delaying stop of pending: " + service);
465            service.delayedStop = true;
466            return;
467        }
468        synchronized (service.stats.getBatteryStats()) {
469            service.stats.stopRunningLocked();
470        }
471        service.startRequested = false;
472        if (service.tracker != null) {
473            service.tracker.setStarted(false, mAm.mProcessStats.getMemFactorLocked(),
474                    SystemClock.uptimeMillis());
475        }
476        service.callStart = false;
477        bringDownServiceIfNeededLocked(service, false, false);//重点
478    }

跟进bringDownServiceIfNeededLocked

   private final void bringDownServiceLocked(ServiceRecord r) {
1691        //Slog.i(TAG, "Bring down service:");
1692        //r.dump("  ");
1693
1694        // Report to all of the connections that the service is no longer
1695        // available.
1696        for (int conni=r.connections.size()-1; conni>=0; conni--) {
1697            ArrayList<ConnectionRecord> c = r.connections.valueAt(conni);
1698            for (int i=0; i<c.size(); i++) {
1699                ConnectionRecord cr = c.get(i);
1700                // There is still a connection to the service that is
1701                // being brought down.  Mark it as dead.
1702                cr.serviceDead = true;
1703                try {
1704                    cr.conn.connected(r.name, null);
1705                } catch (Exception e) {
1706                    Slog.w(TAG, "Failure disconnecting service " + r.name +
1707                          " to connection " + c.get(i).conn.asBinder() +
1708                          " (in " + c.get(i).binding.client.processName + ")", e);
1709                }
1710            }
1711        }
.............
1755
1756        r.cancelNotification();//取消serviceRecord对应的前台的广播！！
1757        r.isForeground = false;//取消serviceRecord的前台资格。
1758        r.foregroundId = 0;
1759        r.foregroundNoti = null;
1760
1761        // Clear start entries.
1762        r.clearDeliveredStartsLocked();
1763        r.pendingStarts.clear();
1764
1765        if (r.app != null) {
1766            synchronized (r.stats.getBatteryStats()) {
1767                r.stats.stopLaunchedLocked();
1768            }
1769            r.app.services.remove(r);
1770            if (r.app.thread != null) {
1771                (r.app, false);//重点。更新前台的状态，回到前面的那个函数
1772                try {
1773                    bumpServiceExecutingLocked(r, false, "destroy");
1774                    mDestroyingServices.add(r);
1775                    r.destroying = true;
1776                    mAm.updateOomAdjLocked(r.app);
1777                    r.app.thread.scheduleStopService(r);
1778                } catch (Exception e) {
1779                    Slog.w(TAG, "Exception when destroying service "
1780                            + r.shortName, e);
1781                    serviceProcessGoneLocked(r);
1782                }
1783            } else {
1784                if (DEBUG_SERVICE) Slog.v(
1785                    TAG_SERVICE, "Removed service that has no process: " + r);
1786            }
1787        } else {
1788            if (DEBUG_SERVICE) Slog.v(
1789                TAG_SERVICE, "Removed service that is not running: " + r);
1790        }
1791
。。。。。。。。
1812    }

可以看到一个service自杀的时候，会先取消和对应serviceRecord相关的所有的前台广播的notification（1756行），还有把自身设置为非foreground状态（1757行）。
然后调用updateServiceForegroundLocked，这个方法是之前startForeground那块就分析过的。它是根据serviceRecord是否是前台service的信息更新一下进程的oomadj。而当时我们开了两个前台Service，现在死了一个，还剩下一个呢！所以进程依旧保持高优先级状态。
发现问题了吗？那个代表着foreground的notification没了，但是进程却仍然保持低oomadj值！

修复其实也相当容易，
方案1：严格要求一个startForeground的id对应一个notification。不过这要修改API文档描述。不可取。
方案2：在移除通知的时候做判定，如果通知对应的Service没有死光，那么通知不能够移除！因为service和notification是多对一的状态。

手头没有7.1的代码，不过可以推断应该就是走了方案二，然后导致各个国产App没能成功移除Notification，导致在通知栏上群魔乱舞，不忍直视

花絮：翻阅代码的时候看到这么一段：

if (localForegroundNoti.getSmallIcon() == null) {
     // It is not correct for the caller to not supply a notification
     // icon, but this used to be able to slip through, so for
     // those dirty apps we will create a notification clearly
     // blaming the app.
     Slog.v(TAG, "Attempted to start a foreground service ("
             + name
             + ") with a broken notification (no icon: "
             + localForegroundNoti
             + ")");
     CharSequence appName = appInfo.loadLabel(
             ams.mContext.getPackageManager());
     if (appName == null) {
         appName = appInfo.packageName;
     }
     Context ctx = null;
     try {
         ctx = ams.mContext.createPackageContextAsUser(
                 appInfo.packageName, 0, new UserHandle(userId));
         Notification.Builder notiBuilder = new Notification.Builder(ctx);
         // it's ugly, but it clearly identifies the app
         notiBuilder.setSmallIcon(appInfo.icon);

这个就是Android对一个以前的一个保活方法的修复，利用方法是：startForeground的notification没有setSmallIcon的话就不会在通知栏出现。然后后面的版本很暴力地直接取出App的图标给他填了上去。

参考：www.jianshu.com/p/63aafe3c12af