总体评价
做的不怎么样，应该会被reject。因为soundness不够，并且覆盖率甚至不如APE（APE是sound的）
单入口想要测试充分的固有缺陷：
- 有些activity因为复杂手势或者复杂的逻辑操作而无法达到，每个activity距离默认的入口的距离不同，测试的exploration对于不同的activity是不同的，这就导致了越难发现的activity越难被测充分
- 有的测试方法能够找到activity之间的数据依赖但是不知道什么因素能够对后面的activity造成影响，可能达到这个activity的时候并不是一个完整的能够引发bug的上下文环境。并且这个上下文环境甚至可能是来自于app外部的 (1.Furthermore, because of the infinite test space of GUI programs, it is difficult to launch activities under complete contexts using SET 2. ...XXX has different behaviors depending on its Activity Launching Contexts (ALCs), which is generated by previous event operations or received from outside (e.g., another app))
- 即使达到了某个activity，也无法知道到底是否覆盖完全了（当然，这个问题本身也是不可判定的）
多入口试图如何解决问题：
- 找到什么才是最能够影响某个activity的启动结果的因素，然后尽可能测试这个因素 -> ICC（inter-component communication）最为重要 > 其余因素还有设备配置、activity栈以及全局数据。设备配置直接报告，activity栈能够在空栈的情况下使用Faxla策略，在非空情况下使用Faxex策略。而全局数据，如果能够探索到全局设置相关的activity，在多轮的测试中会修改它
- 试图直接启动某个activity，然后生成它需要的ICC并测试
- 动态的维护每个activity的explore weight使得能够触发更多transition的activity能够被更多的测试到，并且让一些意外crash掉的activity也能够被覆盖到（毕竟不能crash了发现了一个bug就丢掉，可能这个crash的节点是后面更多crash节点的entry）
整个工作的一些限制
- focus在启动环节，是以activity来进行划分，对于某个activity中的一些例如button的点击应该是完全没有纳入测试范围的
- 在basic attribute基本只用到了string相关API而不能够使用其他JDK的库更不用说第三方库
how-to：
- 如何产生多入口：把原本只能通过EA(exported activity 能够被外部app启动)达到的IA（internal activity）修改成为EA，只需要把andorid：exported设置为true或者修改manifest中的intent filter
- 如何动态修改权重：通过多轮测试，Faxex策略基于Faxla的结果，并结合了activity之间的transition > 因为静态分析的一些技术限制，transition可能不够精准，因此Faxex中也会动态地发现更多可到达的状态
- ALM如何建立：最主要依赖于“跳转都是与string相关操作”这一假设，例如if-else中使用一个对string的比较，根据比较结果决定是否跳转或do something，这个假设的局限性就在于当遇到与string不相关的操作时就不能work
- dummy activity：运行时构造出来的虚拟的入口用来访问一些需要权限的无法通过adb直接启动的activity
Evaluation
- RQ1: ALC构造的效果
- 自己构造了一些测试用例
- RQ2: activity启动的效果
- baseline : Monkey Ape IntentFuzzer
- 最终整个Fax覆盖率达到96.4%，成功启动了60%的activity
- RQ3: 是否提高了代码覆盖度
- 略低于IntentFuzzer的覆盖率，但不知道这个是一个怎么样的baseline
- RQ4: Fax是否能找到了更多的bug
- 确实找到了bug，但是没有baseline
整个evaluation都不行，并且它自己一个fuzz interface的work去和默认入口执行的比较这本身就不fair
没找到答案的问题：
- 如何确认一个activity是“global setting related”