connglli / ELEGANT

ELEGANT - a tool to Effectively LocatE fraGmentAtion-iNduced compaTibility issues.
MIT License
3 stars 0 forks source link

weekly report: 2017.08.05-2017.08.09 #1

Closed connglli closed 6 years ago

connglli commented 7 years ago

周报

2017.08.05 ~ 2017.08.09

论文

距离上次许老师给我论文到现在大概过去了一个月,上次迷迷糊糊读的文章到现在也是忘得差不多了,因此这周的首要任务便是对 Lili 学姐的论文进行了再读,并进行了一些记录从而对接下来的研究和开发工作做好铺垫和准备。下面是论文阅读过程中的一些记录,如有不正确还希望许老师和学姐学长指正!

Android 系统兼容性问题概述

我们知道,Android 自诞生到现在,已经拥有了丰富的生态(无线端、智能家居甚至嵌入式等),而且版本迭代非常迅速,同时,基于 Android 原生的第三方 OS 也层出不穷,包括但不限于三星、LG、索尼、HTC、华为、中兴、小米等,也正是如此,才使得 App 在这不同的系统以及版本之间出现了各种兼容性问题,如正常运行在系统 A 上的 App 到了系统 B 可能就会白屏、崩溃等。

待解决的三个问题:

  1. RQ1 - FIC 在 Android Apps 中有哪些类型?引起他们的根源是什么?
  2. RQ2 - FIC 的普遍“症状”有哪些?
  3. RQ3 - Android 开发者在开发中是如何解决这类问题的?其中有没有共性?

RQ1 - FIC issues 分类

2 大类,5 小类。

  1. Device-Specific - 59%
    1. *Problematic drive implementation
    2. OS customization
      1. Functionality modifying
      2. Functionality arguments
      3. Functionality removal
  2. Paculiar hardware composition
  3. Non-Device-Specific - 41%
    1. *Android platform API evolution
    2. Original Android system bugs

RQ2 - “症状”

会导致出现应用崩溃、不正常工作、性能下降、用户体验下降等功能性和非功能性问题。

这些症状可能是应用特有的,对于此类很难做测试预言。

RQ3 - 解决方案和共性

通常问题的定位是非常具有挑战性的一项任务,以致于有些问题难于解决,但问题的解决却通常简单(如加一个判断、try-catch 语句块等)。

共性:查看设备信息、查看设备资源的可用性等。

FicFinder

兼容性测试:维度/搜索空间(版本迭代多、设备多样性、App 组件多)大

API-Context Pair Model

一个 API (i.e. issue-inducing api) 和 Context (i.e. issue-triggering context) 构成的元组。(i.e. acpair := (api, context))

Context -> Context | Context^Condition
Condition -> Software_env | Hardware_env | API usage

因此,根据上述模型,调用某个 API 会造成兼容性问题,当调用这个 API 的上下文满足对应的 Context 的时候。

兼容性检测
提取 API-Context Pair 模型(25 out of 191)

Model 需满足条件:

  1. 可以静态地进行检测(上下文不是仅当运行时才可以获取)
  2. 它们会影响 App 在常见设备上的运行
FicFinder 算法
## ALGORITHM
# @params apk     预分析的 apk 文件
# @params acPairs 所用到的 API-Context 模型
# @return         分析到的 FIC issues
function analyseFICIssues(apk, acPairs) {
  for acPair in acPairs do
    # 获取所有调用
    callsites := GetCallSites(acPair.API)
    for callsite in callsites do
      # 检测是否符合 API 用法以及软件配置
      if MatchAPIUsage(callsite, acPair.CTX) and MatchSWConfig(callsite, acPair.CTX) then
        # 调用 Soot,根据程序依赖图和调用图确定  callsite 的所有依赖
        slice := BackwardSlicing(callsite)
        issueHanddled := false
        for stmt in slice do
          if stmt checks acPair.CTX then
            issueHanddled := true
          fi
        done
        if  issueHanddled == false then
          emit(a warning and debugging info)
        fi
      fi
    done
  done
}

备注:上述算法 BackwardSlicing 对Soot API的调用涉及到“程序依赖图”(program dependence graph)和“调用图”(call graph),且根据文中意思,这两种图的构建限于 Java 本身语言的机制(反射机制可以动态的添加方法等)而无法得到完全准确的解,因此 FicFinder 可能会误报。

Soot

限于某些原因(下面 心声 部分会提到),本周对 Soot 工具仅仅看了下文档介绍,还未做其他深入了解。

下周计划

  1. 安装并配置 Soot,跑几个 Demo,并对程序依赖图和调用图做了解
  2. 考虑 API-Context Model 的实现,主要考虑这么几个部分:
    1. 在没有 Lili 学姐的帮助下,能否根据论文中提到的5个项目中自己进行 Issue 的提取
    2. 在没有 Lili 学姐的帮助下,能否根据论文中提到的5个项目中自己进行 Model 的提取(尤其是配置项的选择)
    3. 如果上述两个工作可以完成,考虑配置文件的书写规则(json?xml?或者 spring 格式),这需要根据 java 来进行适配,当然直接读文件也是可取的,但并不友好。

心声

因为现在正在阿里做 Summer Intern,而且跟着一个比较急着上线的项目,而且本周周一到周三集团又对实习生进行了为期三天的百技培训,所以这周没能拿出比较多的时间看这个东西。下周开始还是应该好好安排实习和研究的时间,争取都能做到自己满意的结果。

P.S. 以前没写过周报,这周报的格式是阿里内部周报大家常用的格式(项目、技术、心声等等模块),不知道合不合要求...