Software Debloating 论文阅读（14）- 安卓简化调研1

AutoDebloater: Automated Android App Debloating

@inproceedings{liu2023autodebloater,
  title={AutoDebloater: Automated Android App Debloating},
  author={Liu, Jiakun and Hu, Xing and Thung, Ferdian and Maoz, Shahar and Toch, Eran and Gao, Debin and Lo, David},
  booktitle={2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE)},
  pages={2090--2093},
  year={2023},
  organization={IEEE}
}

1 介绍

例子：Wikipedia应用，用户可以读文章，找寻信息，编辑文章，阅读被保存的文章，包括创建账号，登入，登出，充值密码。然而，用户不需要所有的功能，比如如果一个用户只想看文章，他就不需要登入，重置密码和编辑文章
先前研究：
- [5]静态分析安卓应用中的死代码进行清除
- [6]将不会被运行的代码认定为膨胀代码；这些代码通过自动化程序探索找到（如 fuzzer）；随后移除这些代码并重新编译应用
- [7]从不同角度静态识别功能（如 permission,activity,modularity），要求开发者选择他们想要保留的功能
然而，这些研究不能辨认用户不想要的功能。对于用户，简化呈现了以下几个问题：
- 1. 完全探索一个应用，并且辨认不需要的功能会很困难。用户意识不到一些他们不需要功能的存在。如，他们意识不到应用简化掉的功能，而这些功能或特性对于他们的特定需求来说是不必要的，也就是说，他们没有意识到应用程序中的多余功能。
  - 让用户充分探索应用是困难的[8]
- 1. 现有方法需要完整的安卓软件开发环境[7]，需要面向终端用户简化程序
为此，我们提出AutoDebloater，自动化简化安卓应用。
- 其为网络应用，终端用户可以通过浏览器方便获取
- 其可以自动化探索程序，使用StoryDistiller[8,9]（是自动化探索安卓应用并生成ATG的SOTA）识别activities之间的转化；随后用户在ATG中选择需要保留的活动；最后ATG移除用户不需要的活动
为了评估性能，
- 我们从Google Play和F-Droid中获得5个安卓应用，包括3类（经济，工具，导航）。
- 我们要求7个用户使用AutoDebloater简化应用。
- 结果显示，用户队简化后程序的可靠性很满意，同时给也肯定了AutoDebloater帮助他们识别activities的能力。
- 平均每个简化过程平均20s

2 AUTODEBLOATER

A 使用场景

考虑Alice只想使用维基百科看文章，她想移除编辑文章的功能
- 1. Alice上传维基百科APK到我们的服务器
- 1. 我们的服务器使用StoryDistiller在APK上，（1）识别app的所有activities（2）对每个活动进行截屏（3）生成ATG。最后我们的服务器返回ATG给ALice（如果APK之前就有，会直接返回ATG）
- 1. Alice选择需要保留的活动，服务器移除Alice不想要的activities，随后重编译APK，发送简化后的程序给Alice

B 使用StoryDistiller提取ATG

StoryDistiller的细节可以在[8,9]中找到
为了探索活动间的转移，StoryDistiller需要外部的挂起应用activity（如使用命令行）
- 一个应用是否能被外部挂起，被 AndroidManifest.xml 中 android:exported决定，其默认不可被外部挂起
- 为此，StoryDistiller插桩应用，修改AndroidManifest.xml中的值
随后，StoryDistiller使用静态分析得到静态ATG。具体地
- 1. 生成应用调用图CG
- 1. 遍历每个类的每个方法，得到活动间的转移
在静态提取过程中，StoryDistiller同时提取Inter-Component Communication（ICC）数据来收集信息（如初始属性和额外参数）来外部挂起活动。更具体地
- 1. StoryDistiller解析manifest文件或Javadiamagnetic来提取初始属性如 action 和category
- 1. 为了提取额外参数，StoryDistiller 可以识别与活动生命周期相关的方法，并根据这些方法中的附加参数与活动渲染之间的关系对这些方法进行连续分析。
最后，StoryDistiller动态使用提取的ICC数据和Android Debug Bridge（ADB）来挂起活动。
- 然后，StoryDistiller探索每个活动的所有交互组件来识别动态活动间的跳转
- 动态活动跳转和静态活动跳转结合得到最终ATG，此时StoryDistiller也获得了每个活动的截图
StoryDistiller运行很耗时，所以对于所有分析过的APK，我们将对其结果进行记忆化

C 简化安卓应用

我们需要移除用户不需要的活动
- 1. 识别用户想要移除的活动的类的方法
- 1. 识别这些方法的相关方法，使用前向切片。更具体的
  - 我们标识需要删除的类的方法为初始的待删除方法集合
  - 对每个方法，识别在CG中该方法的连续方法，如果该方法只被需要被删除的方法调用，那么可以将该方法的后者加入待删除方法集合
  - 删除直到集合为空
我们使用 Soot 框架[10]从安卓应用中删除方法。
我们开发了Java库集成了方法移除模块：
- 输入：初始应用，调用图，移除的活动
- 输出：简化后应用

3 评估

选择5个应用 Bitcoin Wallet, Amaze File Manager, Gas Prices, Vespucci8, A2DP Volume
选择7个参与者，他们有使用安卓的经验，但不是开发者或研究员
我们首先解释简化的原理；然后要求他们探索选择应用的功能，使用我们的服务获得相应的ATG；如果他们发现有活动他们永远不会使用，我们要求他们使用AutoDebloator移除这些活动；最后我们要求他们对简化后程序stability（简化后程序运行不会崩溃）和overall satisfaction（AutoDebloater帮助他们识别和移除活动的能力）打分
结果
- stability：平均 4.8
- overall satisfaction : 平均3.97
- 一些用户抱怨：活动不能充分的展示在ATG上，在chen[9]的工作中已经提及。

4 相关工作

Google提供了一些简化工具，目的是减小安卓应用大小，而不是移除活动。
- 如 R8 静态检测并移除死代码，应用中不使用的资源
[13]简化安卓应用以最小化移动设备网络带宽使用
[7]的工作与我们最相似，然而没开源。同时，我们以服务的形式提供我们的工作。

5 结论

本文中，我们提供了一个网站，AutoDebloater，用户可以使用它简化安卓应用。
我们的工具使用StoryDistiller提取ATG，用户可以在ATG中选择需要保留的活动，随后我们移除用户不需要的活动。
我们的评估显示，用户对简化后程序的稳定性和AutoDebloater帮助他们识别和移除活动的能力很满意。
今后，我们计划允许用户以更细的粒度（如按钮或文本字段的粒度）标注他们不想要的功能。

XDebloat: Towards Automated Feature-Oriented App Debloating

@article{tang2021xdebloat,
  title={Xdebloat: Towards automated feature-oriented app debloating},
  author={Tang, Yutian and Zhou, Hao and Luo, Xiapu and Chen, Ting and Wang, Haoyu and Xu, Zhou and Cai, Yan},
  journal={IEEE Transactions on Software Engineering},
  volume={48},
  number={11},
  pages={4501--4520},
  year={2021},
  publisher={IEEE}
}

1 INTRODUCTION

开发者趋向构建复杂和庞大的单个程序，以：包含所有的功能，支持各个版本的库，以及多样的为不同平台准备的应用二进制接口（ABIs）[1]。
- 这种“one-size-fits-all”策略会导致代码膨胀[3,4],导致很多问题如低传输率，低下载率，大攻击面，低攻击率[4]
feature定义：应用中满足特定需求的功能。如，社交应用中，“chat with friends”考虑为一个功能
简化措施分两类
- pruning-based debloating：移除程序中不需要的功能[5,6,7,9,9,10]，如在软件演化中，一些功能过时或不在维护，开发者想要移除。
  - 目前只有RedDroid[6]在安卓应用上采用了这种策略，其在编译阶段移除死代码，减少多余的ABIS，包括多个SDKs和在下载过程中嵌入的ABIS
  - 我们与[6]不同在两个方面
    - （1）臃肿代码：RedDroid只考虑死代码为臃肿；XDebloat在应用中使用三种特征定位定位特征，运行开发者定义移除什么
    - （2）臃肿ABIs：除了移除特定于操作系统的ABIs外，Xdebloat还会移除应用中臃肿的资源
- module-based debloating：将程序分为若干模块，使得用户可以根据需要下载。
  - Google的两个框架 App Bundles 和 instant-enable app bundle 遵循了这一想法。
  - 然而，目前没有自动化工具可以将应用转为 app bundle。开发者必须重新开发应用
我们提出了第一个面向特征的应用简化框架，并实现了原型XDebloat自动化这一过程。
- 我们专注于安卓应用因为其占据80%市场份额[13]
- 对于给定的二进制格式的安卓应用（如APK），XDebloat支持pruning-based和module-based debloating
挑战：
- C1：type erors：错误移除类型时，其使用会出错
- C2：modelling unique dependencies in Andorid：与桌面应用不同，安卓应用会有被系统委托的间接调用。例如，Android 中的 Intents 可用于实现组件（如活动）之间的通信。
- 现有简化技术[5,6,8,14] 不能解决这些挑战，因[5,8,14]面向C应用，RedDroid[6]面向安卓应用但是其不能构建完整的程序调用图来进行简化。如，其不能解决组件间交流问题[15]，一些方法被认为是死代码而错误地被删除
措施
- 解决C1，我们使用静态分析，分析安卓的特殊机制（如是不明确 Intent 和调用引发的数据/控制流）。我们提出一个类型系统来避免在简化时引入类型错误
- 解决C2，我们探索了应用中安卓特定的依赖在3.2中
贡献
- 1. 第一个对面向功能的应用简化进行了系统调研
- 1. 为应用简化开发了XDebloat原型，支持移除不想要的功能，同时支持将程序自动化地转化为instant app或 app bundle
- 1. 在200个开源，1000个商用应用上评估。结果现实其可以正确地简化程序，生成正确的 instant app或app bundles，并保持较低的性能消耗。其减少代码率平均为34.33%（Activity-based），29.31%(permission-based),32.74(modularity-based).相关工作在[16]

2 BACKGROUND AND MOTIVATING EXAMPLE

在module-based debloating 我们使用了两种框架：instant app和 app bundle

2.1 Instant App

instant app：用户可以在不安装应用的情况下直接使用[12].
包括 base module 和大于等于零的 feature modules
- feature modules：使用定义在base module中的代码，资源和库；包含至少一个activity，为该module的入口，以url的形式访问
- 用户访问feature module时，一个包含该module 和 base module的apk会被下载，否则只下载base module[12,17]
如图一示

2.2 App Bundle

app bundle：app模块化打包，用户只下载需要的模块
一个应用必须包含一个 base module，其他dynamic feature modules是可选的
如图2示
- base 和 dynamic feature modules 打包到一个 .aab 文件中,上传到google play发布，google play会根据用户设备下载对应的模块，可以运行时再下载
- 对开发者，不需要构建过多apk；对用户，只下载需要的模块
- 图中例子，当dynamic feature module B被调用时，才会被下载

2.3 Motivating Example

使用 arxiv 应用（com.commonsware.android.arXiv）作例子展示我们的Xdebloat，其所有activity如图3示
登录app后，用户可以看到种子列表(RSSListWindow)，历史记录(HistoryWindow)，同时设置app偏好(EditPreference)，查询文章(SearchWindow)，查询结果展示在SearchListWindow 。如果一个元素被选中，该元素的细节被展示在 SingleItemWindow。app还允许用户打印文章(PrintDialogActivity)
XDebloat进行了以下操作
1. Feature Location：
- 定位功能，并为下一个步骤生成相应配置文件
- XDebloat支持多维度功能定位，包括类，方法，语句，可以手动功能定位；自动化功能定位维度包括 Activity-based, Permission-based, Modularity-based
  - Activity-based：活动以及附属于该活动的所有用户界面回调作为一种功能。如图3分为8个功能
  - Permission-based：检测应用中的权限，以此分类功能。如Arxiv需要NETWORK权限，所有需要网络的功能都被归为一类
  - Modularity-based：使用 Louvain算法将应用分为模块，以此分类功能。如图8分为10个功能
1. Specification Construction and Checking
- 生成可阅读的配置文件，开发者方便修改
- 配置文件记录<fId,config>，表示功能Id到config的映射。config为0表示移除，1保留。该配置只用在 pruning-based debloating。例子如图四示。
- 仅有config不够，简化要具体到程序元素。因此对每一个config需要具体的 Specification，其表示了每个程序元素的决定，本文中有3种决定，为 remove，preserve，unknown
1. Debloating
- 给定specification，XDebloat进行 pruning-based debloating或者module-based debloating
- 前者移除不需要的功能，后者将应用转化为instant app或app bundle

3 XDEBLOAT

3.1 Overview

如图五示，XDebloat对给定的应用4步操作
- 功能识别 3.3
- specification 构造和检查 3.4
- 简化 3.5，3.6
- 错误报告系统 3.7
输入文件形式是apk，支持pruning-based debloating和module-based debloating

3.2 Static Analysis

Overview:使用静态分析收集信息：
- AndroidManifest.xml中的Activities
- 需要的权限
- 所有布局文件
- 程序依赖图 program dependency graph (PDG) [18]. PDG包含了所有的控制和数据依赖关系
安卓应用入口两个来源[19]
- (1)安卓组件的生成周期方法（如activity）：组件的标准入口，从AndroidManifest.xml中提取
- (2)UI回调：
  - 开发者使用callback方法捕捉UI事件（如button click）
  - callback方法与register方法绑定[20,21],被应用定义为与安卓框架交互的方法[21]. 也称为registration-callback pairs [20].
  - 使用EdgeMiner[20]探索安卓框架中的registration-callback pairs。使用原因
    - 1. SOTA 找UI callbacks
    - 1. 广泛使用在从应用中探索UI callbacks[22,23,24]
    - 1. 结果精确，被DroidBench证明[18,20]
Inter-Component Communication (ICC)
- Intents：安卓中组件间通信的标准方式，其会导致额外的控制和数据流
- 使用IC3[25]推断Intent的目的地，其将ICC问题转化为Multi-Valued Composite (MVC) constant propagation problem 。
Reflections
- 移植DroidRA[26]至我们的分析模块，其是SOTA分析反射的工具
- DroidRA将反射调用转化为composite constant propagation problem。
- 他们使用COALsolver[15]推断被调用者
Asynchronous Task Dependencies
- 异步任务（即 android.os.AsyncTask）是指在后台线程上运行的计算，其结果在用户界面线程上发布[21]。
- 要实现异步任务，开发人员可以实现 AsyncTask 的子类，并实现一些方法
Implementation
- 在FlowDroid[18]上构建，其提供了dunmmyMain方法，可以通过其遍历调用图
- 使用IC3检测ICC

3.3 功能定位

[28,29,30,31]不同软件需要不同的功能定位方法
Activity-based：以活动及其相关的UI回调作为一个功能
- 方法：分析layout文件获得UI元素及回调
permission-based：以需要同一权限的方法为同一功能
- 也与安卓硬件设备相关
- 方法：使用PScout[33]探索权限使用。
  - 1.在赵安卓API和权限需要的对应中SOTA
  - 1. 其在相关研究中广泛使用[34,35,36,37]
modularity-based
- motivated：面向对象编程思想，一个程序的每个模块应该高内聚[38].收到[2,29,39,40]的影响，程序中的一个模块可以看作用户的一个功能
- 方法：社区检测方法[41]。在函数调用图CG上使用Louvain社区检测算法[42]

3.4 规则构造

因为简化可能破坏原有类型关系，因此我们需要构造类型系统。首先要建模语言，随后形成类型系统，随后根据类型系统，找到需要去除的类型的相关代码元素；最后对每个代码元素构建规范

3.5 简化（基于修建的）

步骤
- 1. 功能定位
- 1. 配置：选择哪些功能移除
- 1. 规范：具体到哪些代码元素是否被移除
- 1. 简化
解决Native Code
解决死代码
移除ABIs和DPIs

3.6 基于模型的简化

Instant App：
- 因为每个模型至少含有一个Activity，因此选择基于Activity的功能定位
- 需要满足Google的要求[12]
App Bundle
- 需要满足Google的要求

3.7 错误报告系统

两种可能的措施
- 1. 通过应用性能管理工具插桩[47,48]
- 1. 为整个应用设置crash handle
bug来源
- 1. 原来程序
- 1. 简化引起的bug
通过错误报告，我们可以指导bug来源，同时帮助我们解决

4 评估

4.1 实验设置

依据已有的相关工作[5,6,7,9,10]设置了5个RQ
- RQ1:简化后程序是否可以成功运行？
- RQ2：XDebloat是否可以成功将app转化为instant app或app bundle？
- RQ3：XDebloat可以移除多少代码？
- RQ4：XDebloat可以对运行时资源减少作贡献吗（如data，battery）？
- RQ5：Xdebloat运行时间如何？
我们使用F-Droid的200个应用[49]和1000个商用应用[50]进行评估
与SOTA方法比较。只有[1,6]但都没开源
- 在功能上比较
  - [6]提供了简化ABIs集合，去除死代码。这些XDebloat都有，并且提供了更多
  - [1]专注简化UI组件及相关代码。然而，我们不考虑UI组件为功能。

4.2 RQ1：简化后程序是否可以成功运行？

配置：随机产生配置进行简化（随机配置原因阐释）
程序使用：使用开源应用进行评估（及其原因）
方法：使用Sapienz[50]对简化后程序进行评估
评估步骤：
- 1. 使用EMMA对简化后程序进行插桩，使用Sapienz运行2个小时
- 1. fuzzer在简化程序中引发崩溃时进行记录以重现崩溃，以区分崩溃来源于源程序还是简化
评估结果
- Activity: 100%通过
- Permission:25/1415失败
  - 失败原因：缺少动态字符串分析；应用的开发框架
- Modularity: 1972/2023 成功
人工评估

4.3 RQ2：XDebloat是否可以成功将app转化为instant app或app bundle？

方法：使用Google提供的app bundle验证工具
instant app结果：
- 都可以转化为instant app
- 164个可以直接上传Google Play，36个需要修改（26个包含不支持的权限，10个因为不支持的或弃用的API）
app bundles 结果
- 190/200 个应用成功转化为 bundles；剩下10个使用了弃用的API

4.4 RQ3: XDebloat可以移除多少代码？

两种策略：
- 1. 禁用识别出的所有功能，在100个商用应用和200个开源应用上进行评估
- 1. 只保留应用的主要功能，在200个开源应用上进行评估
方法：使用代码简化率进行评估
策略1结果
- Activity: 34.33%
- Permission: 29.31%
- Modularity: 32.74%
- 结果分析：简化率十分接近，这是因为库，图，其它资源占多数。开发者可以选择性的去移除
策略2结果
- Activity: 19.12%
- Permission: 15.38%
- Modularity: 23.4%

4.5 RQ4: XDebloat可以对运行时资源减少作贡献吗（如data，battery）？

方法：随机选择10个应用，人工比较和评估简化在内存使用，电源使用，CPU时间上带来的影响。
策略1结果：

减少率	内存使用	电源使用	CPU时间
Activity	32.1%	27.2%	40.7%
Permission	16.5%	21.0%	38.4%
Modularity	46.8%	42.7%	42.7%

策略2结果

减少率	内存使用	电源使用	CPU时间
Activity	10.8%	12.2%	19.1%
Permission	9.1%	10.9%	14.3%
Modularity	14.3%	19.5%	25.8%

4.6 RQ5: Xdebloat运行时间如何？

结论
- 1. 功能定位方法影响运行性能
- 1. Activity，Permission的方法收到程序属性影响，modularity的方法受到程序结构的影响
- 1. XDebloat在构建app bundles时需要更多时间

5 例子研究

移除应用中不受欢迎/不需要的组件
移除应用中与硬件相关的功能

6 讨论

6.1 功能定位方法

应该由开发者决定[29]
本文提出 Activity-based, Permission-based, Modularity-based
也可以是 class， method ，statement，field

6.2 面向功能的简化使用场景

生成合法应用的轻量级版本
生成合法应用的 Instant App 或 App Bundle
移除应用中脆弱的部分

6.3 限制

1. 作为静态分析工具，XDebloat有着静态分析的固有问题，其不能解决运行时产生的值。未来工作我们将扩充XDebloat动态分析的能力
1. 在本地库上我们采取了保守的策略，我们计划支持XDebloat简化本地代码
1. XDebloat不支持混淆的应用，这将导致功能不好定位

6.4 有效性威胁

评估应用不够多，实验结果可能不够准确

7 相关工作

程序简化
- Chisel[8] 在C程序上使用强化学习进行简化
- [14] 在编译和加载阶段使用 piece-wise简化方法去除不用的C函数
- CIMPLIFIER运行简化应用容器，如Docker
- [5]TRIMMER使用用户提供的配置数据修建C应用
- JRed[7] 使用静态方法移除应用和运行时JRE中冗余的比特码
- RedDroid[6]使用静态分析移除安卓应用中死代码
- 我们的方法不仅可以去除无用的函数，同时也可以将应用转化为instant app和app bundles
软件膨胀检测
- [4]提出一个检测Java应用中代码膨胀来源的方法
- [3]和[55]讨论了代码膨胀的影响
- [56,57]检测了运行时膨胀
- 这超出了我们的研究范围
程序简化和定制化
- [9]PERSE提出了语法制导的C语言简化方法
- [10]C-Reduce从Clang中获得的语义使用一系列启发式方法进行简化
- 我们的方法使用功能来对程序进行定制化
程序切片 Program sicing
- 一个切片是原始程序的一部分，表示了一些有趣的值
- 与切边工作不同[58,59,60],我们的工作基于用户定义的配置而不是特定的有趣的值

8 结论

我们提出了一个面向功能的简化方法，实现了原型XDebloat来自动化这一工程
XDebloat的功能定位支持不同粒度，并且可以进行 pruning-based和module-based的简化。除了移除不需要的功能，其可以将简化后应用转化为instant app和app bundle
我们在1200个真实应用上评估了XDebloat，结果显示XDebloat在很短时间内可以成功简化并将他们转化为instant app和app bundles。

Towards Speedy Permission-Based Debloating for Android Apps

@inproceedings{thung2024towards,
  title={Towards Speedy Permission-Based Debloating for Android Apps},
  author={Thung, Ferdian and Liu, Jiakun and Rattanukul, Pattarakrit and Maoz, Shahar and Toch, Eran and Gao, Debin and Lo, David},
  booktitle={Proceedings of the IEEE/ACM 11th International Conference on Mobile Software Engineering and Systems},
  pages={84--87},
  year={2024}
}

1 INTRODUCTION

现代安卓应用通常包含大量功能以满足不同的目标用户，这包括但不限于不同的使用场景，不同的库，为不同设备架构准备的多样的应用二进制接口[7]
用户不需要的功能是与他们所不允许的权限相关的，我们可以安全地移除这些功能
最近的安卓简化工作[7,8,14],只有[14]专注于基于权限的简化。
- 他们主要基于 FlowDroid来构建调用图并进行静态分析[1], 然而FlowDroid在现代软件运行时间需要几个小时[3,15]
- 这对用户不太友好，因此需要加速简化时间
本文提出MINIAPPPERM加速基于权限的简化，通过构建函数调用子图而不是全图
- 基于权限的简化首先要移除与权限相关的方法，随后移除可能会被这些方法移除的其它方法。
- 因此，我们不需要整个调用图，我们只需要探索权限相关方法的可达方法
- 构建可达方法的子图，我们可以加速简化时间
为了评估MINIAPPPERM，我们收集了现代安卓应用数据集
- 我们首先在这些APP上使用FlowDroid收集函数调用图构建时间
- 我们的试验表明，我们最多可以减少85.3%的函数调用图构建时间
- 我们也人工检查了简化后应用可以正确运行

2 MINIAPPPERM

MINIAPPPERM总括如上图示：输入为应用和禁止的权限，输出为简化后的应用
包括4个部分
- 1. 权限识别器：读取权限表，识别应用中权限相关的方法
  - 使用PScount[2]将权限映射到方法
- 1. 调用图构建器：构建只包含权限相关方法的可达方法的部分调用图
  - 在BackDroid上构建[15]
  - BackDroid执行有针对性的跨程序分析，可以跳过无法到达的代码，只跟踪那些通向安全敏感汇点API的路径（可将权限相关方法视为汇点API）
- 1. 调用图切片器：遍历部分调用图，移除可以图中可以移除的可达方法
  - 前向切片：移除只被权限相关方法调用的方法
  - 后向切片：移除只调用权限相关方法的方法
- 1. 简化器：移除不需要的方法，返回重新打包的APK

3 PRELIMINARY EXPERIMENT

数据集：取样10个应用
实验设置：
- 不同版本FlowDroid在函数调用图构造时间上差别很大
- 与XDebloat不比较，其没开源，且时间差不多；与其它基于权限的方法也不比较，我们的方法是补充
结果：
- 函数调用图构建时间占主体，这里应该加速
- 调用图构造时间不取决于权限的适量，却决于权限相关方法的广度

4 RELATEDWORK

许多工作面向程序简化
- Chisel[6]
- Piece-wise[11] 分段编译和加载，可以系统地检测和移除内存中的不用代码
- Cimplifier[12] 基于用户定义的限制简化Docker容器
- TRIMMER[13]通过在部署环境中特化程序简化C程序中不需要的功能
- JRed[9]通过静态分析移除Java应用和JRE中的不用代码
- RedDroid[8]移除编译时和加载时冗余来简化安卓应用
- XDebloat[14]面向功能的安卓简化
- 我们的工作是对以上工作的补充，加速了函数调用图的构建
一些工作致力于检测和分析软件膨胀
- [4]提出了通过关注信息检测Java应用中运行膨胀的方法
- [17]分析如何找到，移除，阻止软件膨胀带来的问题
- [5]强调了 bloat-aware design在大数据应用中的重要性
- [10]分析了软件膨胀在数据敏感系统中的影响
- [16]引入了一种称为复制图的抽象概念，可以用来揭示Java中常见的膨胀模式。
- 上述研究为去膨胀方法的工作提供了基础。在移除膨胀之前，应先检测到膨胀。对软件膨胀的更好理解也有助于未来去膨胀方法的开发。

5 CONCLUSION AND FUTUREWORK

我们提出MINIAPPPERM加速安卓应用中基于权限的简化
其通过构建函数调用子图而不是全图来加速简化，最快可以加速85.3%
未来：
- 在更多应用上更广泛地验证MiniAppPerm的有效性。
- 计划通过优化部分调用图构建来提高MiniAppPerm的速度
  - 例如引入并行化。另一种可能性是在不完全构建调用图的情况下进行即时切片。
  - 还有一个方向是使用神经符号程序分析来构建部分调用图，例如使用深度学习技术预测部分调用图的边。

Software Debloating 论文阅读 （14）- 安卓简化调研1

AutoDebloater: Automated Android App Debloating

1 介绍

2 AUTODEBLOATER

A 使用场景

B 使用StoryDistiller提取ATG

C 简化安卓应用

3 评估

4 相关工作

5 结论

XDebloat: Towards Automated Feature-Oriented App Debloating

1 INTRODUCTION

2 BACKGROUND AND MOTIVATING EXAMPLE

2.1 Instant App

2.2 App Bundle

2.3 Motivating Example

3 XDEBLOAT

3.1 Overview

3.2 Static Analysis

3.3 功能定位

3.4 规则构造

3.5 简化（基于修建的）

3.6 基于模型的简化

3.7 错误报告系统

4 评估

4.1 实验设置

4.2 RQ1：简化后程序是否可以成功运行？

4.3 RQ2：XDebloat是否可以成功将app转化为instant app或app bundle？

4.4 RQ3: XDebloat可以移除多少代码？

4.5 RQ4: XDebloat可以对运行时资源减少作贡献吗（如data，battery）？

4.6 RQ5: Xdebloat运行时间如何？

5 例子研究

6 讨论

6.1 功能定位方法

6.2 面向功能的简化使用场景

6.3 限制

6.4 有效性威胁

7 相关工作

8 结论

Towards Speedy Permission-Based Debloating for Android Apps

1 INTRODUCTION

2 MINIAPPPERM

3 PRELIMINARY EXPERIMENT

4 RELATEDWORK

5 CONCLUSION AND FUTUREWORK

Software Debloating 论文阅读（14）- 安卓简化调研1