weekly report: 2017.11.15-2017.11.21

周报

2017.11.15 ~ 2017.11.21

相比上周，本周的任务相对比较轻。首先我们回顾一下上周提到的接下来的任务：

5. 接下来的任务

解决上面提到的两个问题，尤其需要考虑第二个问题的解决方案。

对 slicing 过程进行进一步调优，如上面提到的 k 邻近，以及更精确到查找。

对 canHandleIssue 进行更精确到判断，需要涉及对判断语义的理解，从而降低误报率。

上面三个问题解决后转到安卓。

按以前计划进行下一步。

根据上面提到的问题，本周首先针对 1 和 2 进行了解决。

问题 1.1 - Soot 的同步问题

上周提到，在进行代码追踪的时候发现代码执行中存在有几次中间运行结果不一致的现象，本考虑到将核心代码放到回调中执行，但查看 email-list 后发现官方给出的 flow-droid 的代码就是同步的代码，而非异步代码，因此这个问题暂留，随代码更新继续查看。

问题 1.2 - Soot 的优化问题

针对这种编译优化问题，如果我们把问题报出来，由于这个问题已经被开发者解决而我们却报告，将会导致误报率提高；如果我们不报，准确率将提高。因此本着“降低误报率、提高准确性”的原则，我们在这种问题上做一点 trick，考虑到大多数开发者对兼容性问题的解决一般都会以 *compatible* 命名，因此我们将检测方法名，如果方法名中存在 compatible 字段，我们认为问题已经解决。

问题 2 - k 邻近优化

我们知道，开发者对兼容性问题的解决方式多种多样，常见的解决方式在上次汇报中已经提到，然而，即便是这种常见的情况，仅仅使用最近的 IfStmt 来进行检测得到的结果仍然是宽泛的，考虑下面的情况：

public void someMethod() {
  ...
  if (isCompatible()) {
    for (int i = 0; i < 100; i ++) {
       if (i % 7) {
         someApi();
       }
    }
  }
  ...
}

可以看到，在上面对 someApi 的兼容性解决中，在检测到兼容性后中间还涉及了更多的代码，其中不乏 if/for 等流程控制语句，从而在代码中引入了更多的 IfStmt，而最近的 IfStmt 便不是针对兼容性问题的检测，因此我们引入常量 ENV_K_NEIGHBORS 来对 API 临近的 ENV_K_NEIGHBORS 个 IfStmt 进行检测，从而使得上述问题得到解决，最终得到的结果显然取决于 ENV_K_NEIGHBORS 的值。

修改代码如下：

/**
* Find K IfStmt neighbors
*
*/
private List<Map.Entry<Integer, Unit>> findKNeighbors(List<Unit> unitsOfCaller,
                                                      Unit callerUnit) {
  LinkedList<Map.Entry<Integer, Unit>> queue = new LinkedList<>();

  for (int i = 0; i < unitsOfCaller.size(); i ++) {
    Unit u = unitsOfCaller.get(i);

    // stop here
    if (u.equals(callerUnit)) { break; }

    // add to queue
    if (u instanceof IfStmt) {
      if (queue.size() == Env.ENV_K_NEIGHBORS) {
        queue.poll();
      }
      queue.offer(new HashMap.SimpleEntry<>(i, u));
    }
  }

  return queue;
}

剩余的问题

Soot 同步问题（随着代码继续更新再次查看是否还有类似问题）
对 canHandleIssue 进行更精确到判断，需要涉及对判断语义的理解，从而降低误报率。
上面三个问题解决后转到安卓。
按以前计划进行下一步。

connglli / ELEGANT