109計(jì)算機(jī)專(zhuān)業(yè)安卓系統(tǒng)應(yīng)用相關(guān)有關(guān)外文文獻(xiàn)翻譯成品了解安卓android應(yīng)用程序編程和安全性_動(dòng)態(tài)研究

1、<p>　　此文檔是畢業(yè)設(shè)計(jì)外文翻譯成品（ 含英文原文+中文翻譯），無(wú)需調(diào)整復(fù)雜的格式！下載之后直接可用，方便快捷！本文價(jià)格不貴,也就幾十塊錢(qián)！一輩子一次的事！</p><p>　　外文標(biāo)題：Understanding Android Application Programming and Security: A Dynamic Study</p><p>　　外文作者：Barb

2、ara G. Ryder</p><p>　　文獻(xiàn)出處:International Conference on Software Maintenance and Evolution.2017</p><p>　　英文7845單詞，43852字符，中文11920漢字。</p><p>　　Understanding Android Application Progra

3、mming and Security: A Dynamic Study</p><p>　　Abstract—Most existing research for Android focuses on particular security issues, yet there is little broad understanding of Android application run-time charact

4、eristics and their implications. To mitigate this gap, we present the first systematic dynamic characterization study of Android apps that targets a broad understanding of application behaviors in Android. Through lightw

5、eight method-level profiling, we collected 59GB traces of method calls and Intent-based inter-component communication </p><p>　　I.INTRODUCTION</p><p>　　The Android platform and its user applicat

6、ions (referred to as apps) dominate the mobile computing arena, including smartphones, tablets, and other consumer electronics [1], [2]. Meanwhile, accompanying the rapid growth of Android apps is a surge of security thr

7、eats and attacks of various forms [1],[2].In this context, it becomes crucial for both developers and end users to understand the particular software ecosystem of Android for effectively developing and securing Android a

8、pps.</p><p>　　While written in Java, Android apps have set themselves apart from traditional Java programs by how they are built and the environment in which they execute. Android apps are supposed to rely o

9、n the Android SDK and other third-party libraries [3], [4]. In fact, many of the distinct characteristics of Android apps have led to unique challenges in developing sound and effective code-based app analyses, resulting

10、 in specialization and customization for Android of analyses originally designed for tr</p><p>　　Specifically, the framework-based nature of Android apps requires substantial modeling of the Android runtime

11、for static analyses [3]–[5] to achieve reasonable accuracy. Implicit invocation between components in Android apps through a mechanism called inter-component communication (ICC) requires special treatments (e.g., ICC res

12、olution [6], [7]) for a soundy [8] whole-program analysis. In addition, the event-driven paradigm in Android programming accounts for many challenges in Android security </p><p>　　Existing research on Androi

13、d has been predominantly aimed at security (as lately surveyed in [2]). Most solutions targeted specific security issues, with merely a few offering a broader view of application security related characteristics in gener

14、al [11], [12]. Several recent studies on Android apps investigated aspects other than security [13]–[16] but targeted static characterizations by examining the source code rather than the run-time behaviors of the apps.

15、Existing dynamic studies for Andr</p><p>　　We randomly chose 125 free Android apps from Google Play and 80 linked pairs among them, exercised each app and app pair with automatically generated inputs attaini

16、ng a mean line coverage of 70% per app, and gathered 59GB traces of ordinary function calls and ICCs. From these traces, which reasonably represent how the chosen apps are executed, we characterize applications on the pr

17、imary Android market from both security and program understanding perspectives. In particular, we stress metrics rel</p><p>　　These metrics and corresponding results constitute the first systematic dynamic c

18、haracterization of Android apps, which will benefit customization and/or optimization of future Android app analyses. For the longer term, our findings will inform better design of techniques and methodologies for more e

19、ffectively developing and securing Android apps. Further, changes in these behavioral characteristics over time will reveal how Android apps evolve.</p><p>　　The main contributions of this work include:</

20、p><p>　　?A dynamic study of the layered composition and functionality distribution of Android apps, which sheds light on their run-time structure and its security implications. The study reveals that (1) Androi

21、d apps are extremely framework-intensive, with around 90% of all callers and callees being SDK methods and (2) constantly the most (60–90% of all) exercised components are Activities, which receive most (about 60% of all

22、) exercised lifecycle callbacks.</p><p>　　?An intensive investigation of Intent-based ICC, the main inter-component communication mechanism in Android, which suggests optimization strategies for ICC-involved

23、 program analyses of Android apps. The investigation reveals that (1) most ICCs (70–80%) do not carry any data payloads and (2) ICCs that carry data payloads favor bundles over URIs, particularly in inter-app ICCs (>2

24、0% using bundles versus <5% using URIs).</p><p>　　?A detailed characterization of sensitive API calls during long Android app executions, which informs code-based analysis of sensitive-data accesses for i

25、mproved cost-effectiveness. The characterization reveals that (1) up to 5–10% of method calls access sensitive data/operations (with respect to highly comprehensive source/sink lists) and (2) constantly most (90% of all)

26、 exercised sensitive calls target only one or two particular (out of over ten) types of data/operation.</p><p>　　?An open-source dynamic study toolkit including an Android app (line) coverage measurement too

27、l that does not rely on source-code access and various predefined categorizations that can be reused for future studies and understanding of Android apps, along with a benchmark suite of dynamically communicating (via IC

28、C Intent) app pairs that can support other Android studies and analyses, especially dynamic inter-app analyses.</p><p>　　AI.BACKGROUND</p><p>　　Android is now the most popular operating system (

29、OS) running on smartphones and other types of mobile devices. To facilitate the development of user applications, the Android OS provides a rich set of APIs as part of its SDK which implements functionalities commonly us

30、ed on various mobile devices. These APIs serve as the only interface for applications to access the device, and the framework-based paradigm allows for quick creation of user applications through extending and customizin

31、g SDK clas</p><p>　　Four types of components are defined in Android, Activity, Service, Broadcast Receiver, and Content Provider, as the top-level abstraction of user interface, background service, response

32、to broadcasts, and data storage, respectively [20]. The SDK includes APIs for ICC by which components communicate primarily via ICC objects called Intents. We focus on ICCs based on Intents that can link components both

33、within the same app (i.e., internal ICC) and across multiple apps (i.e., external ICC). Appli</p><p>　　Some information on mobile devices is security-sensitive, such as device ID, location data, and contacts

34、 [11], [20]. Taint analysis commonly identifies sensitive information leakage by detecting the existence of feasible program paths, called taint flow, between predefined taint sources and taint sinks [9], [21]. In Androi

35、d, taint sources are the APIs through which apps access sensitive information (i.e., sensitive APIs). The Android SDK also provides APIs (inclusive of those for ICCs) through w</p><p>　　BI.EXPERIMENTAL METHO

36、DOLOGY</p><p>　　We traced method calls and Intent ICCs to understand the dynamic features of applications in Android. The resulting traces capture coarse-grained (method-level) control flows but not data flo

37、ws. Nonetheless, such traces can reveal a broad scope of important dynamic characteristics regarding the typical behaviors and security-related traits of Android apps. Next, we elaborate on the design of our empirical st

38、udy—benchmark apps, inputs used for the dynamic analysis, metrics calculated, and study p</p><p>　　A. Benchmarks and Test Inputs</p><p>　　We randomly downloaded 3,000 free apps from Google Play

39、 and statically analyzed the ICCs of each app using the most precise current ICC analysis [7] to find potentially communicating app pairs by matching the ICCs across apps [22]. This process led to a pool of over one mill

40、ion such pairs linked via either explicit or implicit ICCs, or both.</p><p>　　Next, we randomly picked 20 different pairs and removed them from the pool, performed our instrumentation, and then ran the instr

41、umented code on an Android emulator [23]. To ensure that we gathered useful traces and that our study reflected the use of current Android SDK features, we discarded pairs in which at least one app (1) was built on a ver

42、sion of Android SDK lower than 4.4 (API 19) or (2) failed to run on the emulator after the instrumentation, or (3) did not have at least 55% (as is hig</p><p>　　Previous dynamic studies of Android apps, usin

43、g much smaller benchmark suites, mostly resorted to manual (expert) inputs [21], [26]–[29], because the coverage of automatically generated Android inputs was regarded as too low. We chose to use automatically generated

44、inputs for two reasons. First, manually manipulating various apps is expensive, subject to human bias and uneven expertise, and an unscalable strategy for dynamic analysis. Second, state-of-the-art automatic Android inpu

45、t generators c</p><p>　　B. Metrics</p><p>　　We characterize run-time behaviors of Android apps via 122 metrics in three complementary perspectives/dimensions each consisting of several supporti

46、ng measures defined as follows. Metrics in the ICC dimension also cover both intra-and inter-app communications. Thus, our dynamic characterization is systematic in terms of the study scope.</p><p>　　General

47、 metrics—concerning the composition and distribution of app executions with respect to their usage of different layers of functionalities: user code (UserCode), third-party libraries (3rdLib), and the SDK (SDK). Specific

48、 measures include (1) the distribution of function call targets over these layers, (2) the interaction among the layers (i.e., calling relations and frequency), and (3) the extent and categorization of callback usage.<

49、;/p><p>　　ICC metrics—concerning Intent-based inter-component interaction within single apps and across multiple apps. ICC has been a major security attack surface in Android [6], [22],[32]as well as a feature

50、of Android application programming that sets it apart from ordinary Java programming. Specifically, we measure (1) the distribution of the four types of components (see Section II) in Android app executions, (2) the cate

51、gorization of run-time ICCs with respect to their scope (internal/external) and </p><p>　　Security metrics—concerning the production, consumption, and potential leakage of sensitive data in Android app execu

52、tions. We measure (1) the extent of use of the producers (i.e., sources) and consumers (i.e., sinks) and(2)the categories of information accessed by executed sources and operations performed by executed sinks.</p>

53、<p>　　For each of these measures, with each app, we examined the full execution traces of method calls and exercised Intent ICCs for the app. We considered all instances for each call and ICC (i.e., accounting for

54、the frequency) to capture the run-behaviors of the app. For understanding inter-app ICCs, we also examined the traces for each pair of apps. We trace all calls including those via exceptional control flows [33] by reusin

55、g our previous relevant utilities [34].</p><p>　　C. Procedure</p><p>　　To collect the operational profiles of the benchmark apps, we first ran our tool to instrument each app for monitoring ICC

56、 Intents and all method calls. Next, we ran each instrumented individual app separately and then each app pair, gathering the single-app and inter-app traces (when multiple target apps in inter-app ICCs are available, on

57、e was randomly chosen). All of our experiments were performed on a Google Nexus One emulator with Android SDK 6.0/API level 23, 2G RAM, and 1G SD storage, run</p><p>　　For each individual app, Monkey inputs

58、were provided for up to one hour of execution. For each app pair, the two apps ran concurrently, taking Monkey inputs alternately for an hour. To reduce the impact of possible non-determinism in the benchmarks, we repeat

59、ed each experiment three times and took the average of these repetitions. We checked the repeated traces for each app and app pair, and found only very small deviations among them. Thus, we used the mean over the repetit

60、ions for each metric </p><p>　　IV. CHARACTERIZATION PROCESS</p><p>　　Figure 1 depicts the process of our characterization study, including its three phases as well as inputs and outputs.</p&g

61、t;<p>　　Pre-processing. After obtaining the benchmark app pairs as described in Section III-A, the static code analysis instruments the Android (Dalvik) bytecode of each app for method call profiling and ICC Inten

62、t tracing. This first phase also produces relevant static information for each app using class hierarchy analysis (CHA), including the component type each class belongs to (i.e., the top component class it inherits) and

63、callback interface each method implements in the app. This information is u</p><p>　　Profiling. The second phase runs the instrumented code of each individual app and app pair to produce the single- and inte

64、r-app traces in the respective settings. We recorded method calls and ICC Intents using the Android logging utility and collects the traces using the logcat tool [36].</p><p>　　Characterization. The third ph

65、ase analyzes the traces by first building a dynamic call graph. Each node of the graph is the signature of a method (executed as a caller or callee), and each edge represents a dynamic call which is annotated with the fr

66、equency (i.e., number of instances) of that call. Also, for each ICC, the graph has an edge going from the sending API (e.g., startActivity) to the receiving API (e.g., getIntent) of that ICC. This phase computes various

67、 metrics using the call graph </p><p>　　To facilitate reproduction and reuse, we released the open-source implementation of our study utilities as an open-source toolkit DROIDFAX [38], including a line cover

68、age tracking tool directly working on an APK. Given a configured Android emulator or device and a set of apps and/or app pairs, the automated study workflow produces both metrics values and their visualization and tabula

69、tion. Also available are our study results, the categorization of event handlers we created, the improved source </p><p>　　V.RESEARCH QUESTIONS</p><p>　　With respect to the metrics described abo

70、ve, our study seeks to answer the following research questions.</p><p>　　RQ1: How heavily are the SDK and other libraries used by Android apps? This question addresses the construction of Android apps in ter

71、ms of their use of different layers of code and the interaction among them. Answering this question offers empirical evidence on the extent of the framework-intensive nature of Android apps—previous works only suggested

72、the existence of that nature through static analysis [4], [5]. RQ1 is answered using the first two measures (i.e., (1) and (2)) of the general met</p><p>　　RQ2: How intensively are callbacks invoked in Andro

73、id apps? It is well known that callbacks, including lifecycle methods and event handlers, are widely defined or registered in Android app code [3], [9], [10]. This research question addresses their actual usage in Androi

74、d app executions, that is, the frequency of callback invocation and the distribution of different types of callbacks. RQ2 is answered using the third measure (i.e., (3)) of the general metrics.</p><p>　　RQ3:

75、 How do Android app components communicate using the ICC mechanism? Much prior research has targeted Android security concerning ICCs [6], [7], [22], [32], yet it remains unclear how often ICCs occur relative to regular

76、function calls during app executions, how different types of ICCs are used, and whether all ICCs constitute security threats. The answers to each of these questions are subsumed by RQ3, and are investigated using the ICC

77、 metrics.</p><p>　　RQ4: How is sensitive information accessed in Android apps? Addressing the secure usage of sensitive information has been the focus of various previous works, including taint analysis [3],

78、 [9], privilege escalation defense [5], [27], and data leakage detection [22], [39]. However, how often that usage is exercised or which kinds of sensitive information are mostly accessed has not been studied. RQ4 explor

79、es these questions using the security metrics.</p><p>　　VI. EMPIRICAL RESULTS</p><p>　　This section presents the results of our study, reporting the three categories of metrics with respect to r

80、elevant research questions. For call frequencies, we report the number of instances of each executed callsite throughout all single-app traces using scatterplots. For callback and source/sink categorization, we rank the

81、categories for each app and report for each category the mean rank across all benchmarks along with the standard deviation of the ranks. For each of the other metrics, which</p><p>　　For each category of met

82、rics, we first present the results in detail and then summarize and discuss the most important observations from an average-case perspective. We also offer insights into the implications of our empirical findings and dem

83、onstrate how our results can be used in future development and security defense of Android apps.</p><p>　　A. General Characteristics of Android Apps</p><p>　　To gain a general understanding of

84、Android app behaviors, we investigated the structure of their execution in terms of three layers of functionality (i.e., UserCode, SDK, and 3rdLib), the interaction among these layers, and the usage of callbacks.</p&g

85、t;<p>　　1)Composition of Code and Execution: The composition of the method call trace of each Android app is characterized in terms of the percentages of call instances accessing user code, third-party libraries,

86、and the Android SDK. Figure 2 shows the distribution of these layers in all the single-app traces, with each group of boxplots depicting both class and method granularity.</p><p>　　The plots reveal that cons

87、istently all the subject apps employed library functionalities extensively, especially the SDK, in performing their tasks. On average, at both class and method levels, SDK code was executed the most frequently among the

88、three layers, suggesting that run-time behaviors of the SDK dominate in the apps. The observation that over 90% (on average) of all calls were to the SDK code in almost all apps corroborates that Android apps are highly

89、framework-intensive. In contrast, </p><p>　　2)Inter-layer Code Interaction: Figure 3 scatter-plots the frequency of each executed callsite per app. The data points are categorized by the calling relationship

90、s, denoted in the format of caller layer→callee layer, among the three code layers. Each plot shows the call-frequency ranking for one of the nine categories of inter-layer interaction. The breadth of each plot indicates

91、 the total number of executed callsites in the corresponding interaction category, while the height suggests the rang</p><p>　　Consistent with the results in Figure 2, these plots confirm that (1) many more

92、SDK and third-party library APIs were called than user methods and (2) the total number of unique SDK callees overwhelmingly dominated all callees. The plots reveal that categories having larger numbers of callsites most

93、ly had larger frequency maxima as well. The most frequently exercised calls were from SDK (which also received the calls of the highest frequency) followed by those from user code.</p><p>　　Figure 4 shows th

94、e percentage of call instances in each inter-layer interaction category over the total call instances in all benchmark app executions. Noticeably, the majority (75.7%) of call instances over all apps happened within the

95、same layer—dominated by the SDK layer (70.3%)—rather than across layers. User functions were called very rarely by any callers (no more than 4%), reconfirming our previous observation from Figure 2. The results reveal th

96、at the vast majority of calls to third-part</p><p>　　In summary, results on inter-layer code interaction further confirm the highly framework-intensive nature of Android apps, indicating that the Android fra