毕业设计外文资料翻译-Android程序的静态分析

1、毕业论文（设计）外文资料翻译学 院： 专业班级： 学生姓名： 指导教师： 外文出处：(外文) Information and Software Technology 附 件：1.外文资料翻译译文； 2.外文原文 指导教师评语： 材料选取适当，符合论文选题但翻译的不够透彻，希望翻译的过程，也能理解其中意思，不要理解的太表面。以达到学习的效果。签名： 2015 年 10 月 14日外文资料翻译译文 Android程序的静态分析Android是基于Java编程语言和操作系统的嵌入式和移动设备，其上层被写入在Android语言本身。作为一种语言，它拥有一个扩展的基于事件的库，并从XML声明布局文件图形

2、视图动态的输出文件。静态分析仪为Android方案必须考虑正确性和准确性这个特征。目的：我们的目标是扩展朱丽亚静态分析器，基于抽象的解释，以进行正式正确的分析Android程序。这篇文章是深入描述我们所面临的困难以及解决结果。方法：我们通过考虑一些Android的关键功能如多入口点，以程序的潜力存在和从XML图形视图通胀来延长朱莉娅分析。我们显著提高了Android程序的零度分析。结果：我们已经应用了几十个静态分析，包括类的代码，死区码，空值和终止性分析。朱丽亚已经发现，自动，错误，缺陷和效率低下，无论是在谷歌的样品和在开放源代码的应用。结论：Julia是第一部Android程序有声静态分析仪

3、。基于一个正式的基础，如抽象的解释。我们的研究结果表明，它可以实时分析第三方Android应用程序，无需任何代码的用户注释，在产生最多7分钟，在标准硬件上正式正确的结果。因此，它已准备好第一工业用途。Android是在操作系统市场上的主要参与者为移动和嵌入式设备如移动电话，平板电脑和电视提供平台。它是一个这样装置的操作系统，其上层被写入在编程语言中，也称为机器语言。作为一种语言，Android是使用Java的移动扩展库和交互应用。因此，基于事件驱动的架构。任何Java编译器可以将Android应用程序，但由此产生的Java字节码必须最终转换成非常优化，字节码Dalvik在设备上运行。由于质量和

4、可靠性是关键在Android市场上取得的成功。所以Android应用程序静态分析是非常重要的。因此，Android的程序员要确保它们的方案都是无缺陷。例如，他们不提供出任何异常和不挂的设备。但Android应用也日益部署在关键上下文，即使是在军事方案中，安全性和可靠性是极为重要的。由于这些原因，在工业上我们都知道的演员如Klocwork的16已经扩展了其静态分析工具从Java到Android，获得Android的唯一的静态分析。它在动力相对有限，据我们可以从他们的网页推断。我们无法得到一个免费的评估许可证。一个工具如Klocwork是基于句法检查。这意味着，错误是通过寻找代码的典型语法模式，通

5、常包含一个错误识别。使用语法检查，导致非常快速，实用的分析。然而，它未能认识到错误时，错误的代码没有按照预定的模式由分析仪称。这种情况是语义工具如朱丽亚的相反，在错误被发现在该工具的人工智能，基于形式化方法，也没能证明一个程序片段不包含错误。这第二种情形是更复杂且计算昂贵的，但提供了稳健的结果：保证如果没有潜在的错误被发现，那么就没有在代码类的错误。在其他方面，语法工具是快的，但是不健全。这两种方法信号误报，也就是说，实际上不是一个真正的错误是一个潜在的bug。在这里精密是关键，因为误报的数量应不压倒工具的用户。这是经过大多数开发人员静态分析工具确认的。例如，我们可以给网页提供业界最准确的分析

6、解决方案和最低的误报率，你可以专注于真正的和相关的缺陷，而不是浪费开发周期。因此，大多数开发人员努力使用静态分析是为了减少假阳性。这个声音对分析器来说是很难的，因为它们不能只发出警告，还有持续的声音。在任何情况下，公司的存在如Klocwork的这个市场上表明行业认识到的Android代码的静态分析的重要性。更科学的方法是突出SCanDroid工具14。目前仅限于Android应用程序的安全验证。它执行的Android应用程序的信息流的分析，通过跟踪意图和组件间通信通过应用联盟的潜在非法收购的安全权限。其基础是代码的基于约束的分析，有一个健全性的保证，至少一个受限制的字节码。 Klocwork公

7、司目前不执行Android应用程序的任何信息流分析。 Julia是一个静态分析器为Java字节码的基础上，抽象解释6，以确保，自动，所分析的应用程序不包含大量组编程错误。它适用于非平凡的整个程序，过程间和语义静态分析，包括classcast，死代码，NULL的含量和终止分析。它配备了一个正确的保证，因为它通常是在抽象解释社会的情况：如果该应用程序包含一个错误，由分析仪确认，那么朱莉娅将举报。这使得分析的结果更显著。虽然Java和Android是相同的语言，用不同的库集。朱莉娅到在Android应用并不直接使用Android程序，我们必须解决许多问题为前提后朱莉娅才可以可以分析正确。许多都涉及到

8、不同的库集，其他人使用XML来构建应用程序的一部分。在这篇文章中，我们提出这些问题再加上我们对他们的解决方案，并显示所产生的系统分析不平凡的Android程序具有高精确度，并认为第三方代码中的错误。本文不详细描述朱莉娅静态分析，但只适应分析仪的Android和它的分析。特别是我们的阶级分析，在简单的检查，如classcast和死代码分析的内核，在27中描述;我们的NULL的含量分析在25,26被描述;我们的终止分析在28中描述。必须指出，我们的朱莉娅仪不健全反射在Java和多线程。类加载机制需重新定义。这并不意味着使用这些功能不被分析，但这些结果可能是不正确的。实际上，我们的工作中的一个主要的

9、成就在于教导朱莉娅，关于具体使用反射Android的XML布局。所以，该分析的结果在这种情况下仍然稳健（但不包括反射的其他用途）。我们的分析假定一个封闭的世界。假设例如在入口点，变量可能被绑定到每类具有其声明的类型上，可以在任何可能的方式共享或保持。同样的假设不能为库，进行扩展，其行为可以通过子分级进行修改。因此，我们可以图书馆模块化分析，因为我们只分析完成Android应用程序。有许多静态分析仪，它能够分析Java源代码和发现错误或低效。他们中的大多数都是基于语法分析（Checkstyle Coverity公司的FindBugs）或使用定理与一些简化假设证明。因为Android语言是Java

10、语言。仅库的变化，这可能原则上可以应用这些分析Android源代码。然而，正如我们将在下面的章节中展示的，有新的语言特性，如XML通胀，不是由这些工具理解和影响该程序的控制流图结构是相同的，通常是一个类型推理分析进行被称为阶级分析。有许多新种Android的代码中bug，因为使用该库方式，不属于典型的Java。因此，可能在一个合理的方式假定这些功能不存在，就不会发生这些错误，或者必须一一应对。我们认为，我们在文中突出的解决方案可以应用到那些静态分析仪。因为它们并不局限于我们所选择的特定的静态分析仪。Julia是一种商业产品，其功率由超时和分析的最大尺寸限制了该网站的网页界面自由使用。福斯托斯波

11、托是该公司的董事长，他成立于2010年11月他也是朱莉娅软件的主要开发者。艾蒂安帕耶特目前在留尼旺岛（法国）副教授。在对Android的静态分析方面的挑战是不平凡的，因为我们不需要考虑Android系统的一些具体特点，无论是对分析的正确性和精确性。首先，朱丽亚分析了java字节码在Android应用程序运在Dalvik字节码。有从Dalvik的翻译成Java字节码。但是开发Android应用程序在Eclipse IDE可始终JAR格式导出里面，也就是在Java字节码。Eclipse是Android的标准开发环境的那一刻，因此我们更愿意从生成Eclipse中jar文件。另一个问题是，Androi

12、d的程序从多个事件处理程序开始启动程序的分析。这也适用于一些基于事件的Java程序，如使用执行摆动程序的一个问题事件处理程序。这是Android代码，其中整个项目工程通过事件处理程序往往是通过反射调用，所以他们实际上可能看起来像死代码静态分析不理解反射更多的问题。因此，我们必须使之从所有这些处理程序开始分析修改朱莉娅，认为他们为潜在的并发条目。必须指出的是，Android的事件处理程序是由单个线程执行，因此我们没有考虑多线程应用程序进行分析的难题。入口点是从最坏情况假设分析，并说明实例其参数和接收器可以属于他们的静态类型兼容任何类，或者总是可以为空或持有重叠的数据结构。一个更复杂的问题是用户界

13、面通过XML文件的声明性指定，由Android使用。这意味着该代码是不是在字节码格式完全可用，在运行时，从XML布局文件到实际的字节码，通过使用Java反射。这个问题必须布局代码只包含图形方面，不相干的静态分析会被低估。相反，在Android的程序，XML的数据类，如视图，菜单和偏好，包含大多数或甚至全部的应用程序的代码，其中包括它的业务逻辑。此外，XML之间的联系代码和xplicit应用程序代码引入管型和潜在的空指针异常。因此，分析必须考虑通胀的XML。最后，一个真正的挑战是库的大小：一般来说，Android应用程序使用java和Android的等级限制。他们的类必须被分析的程序，这很容易导

14、致10000种方法或更多的分析Android的基础知识。在这里我们只描述了在本文有用的Android概念。看到Android应用程序是用java写的，运行在自己的进程自己的虚拟机内。他们没有一个单一的入口点，但可以使用，其他Android应用程序部分点播，可以通过调用需要的服务，他们的事件处理程序，直接或通过操作系统。特别是，Android应用包含活动（代码通过一个可视界面与用户交互），服务（与用户的交互的后台操作），内容提供者（数据容器如数据库）和广播接收器（对象反应广播消息）。事件处理程序被安排在没有特别的顺序，有一些明显的例外，如活动的生命周期。一个XML清单文件注册一个应用程序的组件。

15、其他的XML文件描述了活动的可视化布局。活动的布局文件转换成可视对象（视图的层次），通过Android的库提供吹气。这意味着，库或用户定义的视图中未明确由新语句创建而是通过反射充当。使用库等方法找到ViewById访问膨胀意见。作为一个例子，考虑到图的活性。从Android 2.2谷歌分布之后，它的构造已经由Android系统隐含调用第一次创建活动时OnCreate事件处理函数被调用。该库的设置内容方法调用布局，其整个参数中唯一标识所示的XML布局文件。2.外文原文 Static analysis of Android programsContext: Android is a program

16、ming language based on Java and an operating system for embedded and mobile devices, whose upper layers are written in the Android language itself. As a language, it features an extended event-based library and dynamic inflation of graphical views from declarative XML layout files. A static analyzer

17、 for Android programs must consider such features, for correctness and precision. Objective: Our goal is to extend the Julia static analyzer, based on abstract interpretation, to perform formally correct analyses of Android programs. This article is an in-depth description of such an extension , of

18、the difficulties that we faced and of the results that we obtained .Method: We have extended the class analysis of the Julia analyzer, which lies at the heart of many other analyses, by considering some Android key specific features such as the potential existence of many entry points to a program a

19、nd the inflation of graphical views from XML through reflection. We also have significantly improved the precision of the null ness analysis on Android programs.Results: We have analyzed with Julia most of the Android sample applications by Google and a few larger open-source programs. We have appli

20、ed tens of static analyses, including class cast, dead code, null ness and termination analysis. Julia has found, automatically, bugs, flaws and inefficiencies both in the Google samples and in the open-source applications .Conclusion: Julia is the first sound static analyzer for Android programs, b

21、ased on a formal basis such as abstract interpretation. Our results show that it can analyze real third-party Android applications, without any user annotation of the code, yielding formally correct results in at most 7 min and on standard hardware. Hence it is ready for a first industrial use .1. I

22、ntroductionAndroid is a main actor in the operating system market for mobile and embedded devices such as mobile phones, tablets and televisions. It is an operating system for such devices, whose upper layers are written in a programming language, also called Android. As a language, Android is Java

23、with an extended library for mobileand interactive applications, hence based on an event-driven architecture. Any Java compiler can compile Android applications, but the resulting Java bytecode must be translated into a final, very optimized, Dalvik bytecode to be run on the device.Static analysis o

24、f Android applications is important because quality and reliability are keys to success on the Android market . Buggy applications get a negative feedback and are immediately discarded by their potential users. Hence Android programmerswant to ensure that their programs are bug-free, for instance th

25、at they do not throw any unexpected exception and do not hang the device. But Android applications are also increasingly deployed in critical contexts, even in military scenarios, where security and reliability are of the utmost importance. For such reasons, an industrialactor such as Klocwork 16 ha

26、s already extended its static analysis tools from Java to Android, obtaining the only static analysis for Android that we are aware of. It is relatively limited in power, as far as we can infer from their web page. We could not get a free evaluation licence.A tool such as Klocwork is based on syntac

27、tical checks. This means that bugs are identified by looking for typical syntactical patterns of code that often contain a bug. The use of syntactical checks leads to very fast and practical analyses. However, it fails.to recognize bugs when the buggy code does not follow the predefined patterns kno

28、wn by the analyzer. The situation is the opposite for semantical tools such as Julia, where bugs are found where the artificial intelligence of the tool, based on formal methods, has not been able to prove that a program fragment does not contain a bug.This second scenario is much more complex and c

29、omputationally expensive, but provides a guarantee of soundness for the results:if no potential bug (of some class) is found, then there is no bug of that class in the code. In other terms, syntactical tools are fast but unsound. Both approaches signal false alarms, that is, potential bugs that are

30、actually not a real bug. Precision (i.e., the amount of real bugs w.r.t. the number of warnings) is the key issue here, since the number of false alarms should not overwhelm the user of the tool. This is acknowledged by most developers of static analysis tools. For instance, we can quote the web pag

31、e of Coverity 7:By providing the industrys most accurate analysis solution and the lowest false positive rate, you can focus on the real and relevant defects instead of wasting development cycles. Hence, most of the effort of the developer of a static analyzer is towards the reduction of the number

32、of false positives. This is much moredifficult for sound analyzers, since they cannot just throw away warnings and nevertheless stay sound. In any case, the presence of a company such as Klocwork on this market shows that industry recognizes the importance of the static analysis of Android code. A m

33、ore scientific approach is underlying the SCanDroid tool 14,currently limited to security verification of Android applications. It performs an information flow analysis of Android applications, tracking inter-component communication through intents and the potential illegal acquisition of security p

34、rivileges through a coalition of applications. Its basis is a constraint-based analysis of the code and there is a soundness guarantee, at least for a restrictedkind of bytecodes. Klocwork does not currently perform any information flow analysis of Android applications. Julia is a static analyzer fo

35、r Java bytecode, based on abstract interpretation 6, that ensures, automatically, that the analyzedapplications do not contain a large set of programming bugs. It applies non-trivial whole-program, interprocedural and semantical static analyses, including classcast, dead code, nullness and terminati

36、on analysis. It comes with a correctness guarantee, as it is typically the case in the abstract interpretation community: if the application contains a bug, of a kind considered by the analyzer, then Julia will report it. This makes the result of the analyses more significant. Although Java and Andr

37、oid are the same language, with a different library set, the application of Julia to Android is notimmediate and we had to solve many problems before Julia could analyze Android programs in a correct and precise way. Many are related to the different library set, others to the use of XML to build pa

38、rt of the application. In this article, we present those problems together with our solutions to them and show that the resulting system analyzes non-trivial Android programs with high degree of precision and finds bugs in third-party code. This paper does not describe in detail the static analyses

39、provided by Julia, already published elsewhere, but only the adaptation to Android of the analyzer and of its analyses. In particular, our class analysis, at the heart of simple checks such as classcast and dead code analysis, is described in 27; our nullness analysis is described in 25,26; our term

40、ination analysis is described in 28. It must be stated that our Julia analyzer is not sound in the presence of reflection, redefinitions of the class loading mechanism of Java and multithreading. This does not mean that pograms using those features cannot be analyzed, but only that the results might

41、be incorrect. Actually, one main achievement of our work has been to teach Julia about the specific use of reflection that is done during the XML layout inflation in Android, so that the results of the analysis remain sound in that case (but not for other uses of reflection). Our analyzer assumes a

42、closed world assumption, in the sense that, for instance, it assumes that, at the entry points, variables might be bound to every class compatible with their declared type, might share in any possible way or hold null. The same assumption cannot be made for libraries, that can be expanded and whose

43、behavior can be modified by sub classing. Hence ours is not a modular analysis for libraries since we only analyze complete (closed) Android applications. There are many static analyzers that are able to analyze Java source code and find bugs or inefficiencies. Most of them are based on syntactical

44、analyses (Checkstyle Coverity FindBugs) or use theorem proving with some simplifying (and in general unsound) hypotheses (ESC/Java 12). Since the Android language is Java, only the library changes, it might be in principle possible to apply those analyzers to Android source code as well. However, as

45、 we show in the next sections, there are new language features, such as XML inflation, that are not understood by those tools and that affect the same construction of the control flow graph of the program, usually performed through a type inference analysis known as class analysis; there are many ne

46、wkinds of bugs in Android code, because of the way the library is used, that are not typical of Java. Hence, either a static analyzer assumes that those features do not exist and those bugs do not occur (unsoundness) or must deal with them, possibly in a sound way. We think that the solutions that w

47、e highlight in this paper can be applied to those static analyzers as well, since they are not limited to our specific static analyzer of choice. The rest of this paper is organized as follows. Section 2 justifiesthe difficulties of the static analysis of Android programs. Section 3 introduces the A

48、ndroid concepts relevant to this paper. Section 4presents the more relevant static analyses that we performed on Android code. Sections 57 describe how we improved Julia to work on Android. In particular, Section 5 discusses the construction of a sound control-flow graph through class analysis, in t

49、he presence of XML inflation. Section 8 presents experimental results over many non-trivial Android programs from the standard Google distribution and from larger open-source projects; it shows thatJulia found some actual bugs in those programs. Section 9 concludes the paper. This article is an exte

50、nded version of a shorter conference paper presented at CADE in 2011 22. The full experimental evaluation of Section 8 does not appear in 22. Moreover, Sections 46 provide a deeper presentation of the way we extended Julia, compared to the corresponding sections of 22. Julia is a commercial product

51、thatcan be freely used through a web interface available from the web site of the company, whose power is limited by a time-out and a maximal size of analysis. Fausto Spoto is the chairman of the company, that he established in November 2010. He is also the main developer of the Julia software. tien

52、ne Payet is currently an associate professor in Reunion (France). He is not a member of Julia Srl but he regularly collaborates with Fausto Spoto on scientific matters.2. Challenges in the static analysis of Android The analysis of Android programs is non-trivial since we mustn consider some specifi

53、c features of Android, both for correctness and precision of analysis. First of all, Julia analyzes Java bytecode while Android applications are shipped in Dalvik bytecode. There are translators from Dalvik to Java bytecode (such as undx 24 and dex2jar 8). But Android applications developed inside t

54、he Eclipse IDE 9 can always be exported in jar format, that is, in Java bytecode. Eclipse is the standard development environment for Android at the moment, hence we have preferred to generate the jar files from Eclipse.Another problem is that Julia starts the analysis of a program from its main met

55、hod while Android programs start from many event handlers. This is also a problem for some event-based Java programs, such as Swing programs using the actionPerformedevent handlers. This is much more problematic for Android code, where the whole program works through event handlers that are often ca

56、lled through reflection, so that they might actually look like dead code to a static analyzer that does not understand reflection. Hence, we had to modify Julia so that it starts the analysis from all such handlers, considering them as potentially concurrent entry. points. It must be stated that the

57、 Android event handlers are executed by a single thread, so we had not to consider the difficult problem of the analysis of multithreaded applications. Entry points are analyzed from a worst-case assumption, stating for instance thattheir parameters and receiver can belong to any class compatible wi

58、th their static type, or can always be null or hold overlapping data structures. A much more complex problem is the declarative specification of user interfaces through XML files, used by Android. This means that the code is not completely available in bytecode format, but is ather inflated, at runt

59、ime, from XML layout files into actual bytecode, by using Java reflection. This problem must not be underestimated by thinking that layout code only contains graphical aspects, irrelevant to static analysis. Instead, in Android programs, XML-inflatable classes, such as views, menus and preferences,

60、contain most or even all the code of an application, including its business logic. Moreover, the link between XML inflated code and the xplicit application code introduces casts and potential null pointer exceptions. Hence, the analyzer must consider XML inflationin detail if we want it to be correc