dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments We thank  Mr William Francis  who translated this manuscript, the  National Non-Communicable Diseases Control Program  of the  Benin Health Ministry  for contribution in the data collection, and the participants who gave their consent for this study. The study was conducted thanks to:  Laboratory of Chronic and Neurological Diseases Epidemiology, University of Abomey-Calavi, Benin UMR 1094 NET, University of Limoges, France Bolloré Africa Logistics Benin Daiichi Sankyo.
The electric field being confined in the barrier layer, the G-R current is suppressed in the absorption region. The darkcurrent of such a structure, when properly designed, is thus diffusion-limited whatever the temperature. The electrical performances should, a priori, be improved compared to the pin photodiode. However, at high temperature, since T2SL pin photodiodes are also limited by the diffusion contribution  [12] , a lower improvement is expected in comparison with low temperatures. The objective of this paper is to design and to theoretically evaluate, by using the commercial TCAD ATLAS software from SILVACO  [13] , the performances of T2SL barrier infrared detectors. The following section is devoted to the design of a T2SL MWIR barrier structure with a 5 µm cut-off wavelength at 77K.
Thickness and doping level of the absorption region Firstly, the T2SL absorption region suitable for the MWIR domain has to be defined. As the material composing the active region, the p-type T2SL with 7 monolayers (ML) of InAs and 4 ML of GaSb (referred to as the I As-ri h SL was chosen, since it presents the best performances in terms of dark current and quantum efficiency (QE) for a cut-off wavelength of 5 µm at 77K  [12, 17]. To determine the absorption region thickness, QE simulations on pin photodiodes have been performed to extract the minority carrier diffusion length. The material parameters used for the simulation of the InAs-rich SL structure are summarized in Table I  [14]. The LUMINOUS module integrated into ATLAS calculates the photogeneration rate in the presence of a defined beam (intensity, wavelength) that is taken into account in the generation terms of the carrier continuity equations.
-Conclusion Using the commercial TCAD ATLAS software from SILVACO, each layer of the barrier device has been optimized in terms of composition, doping and thickness by analysing energy band diagrams and the electro-optical performances. The proposed nBp device addressing the MWIR spectral domain is made of a 4 µm thick p-type (1 x 10 16 cm -3 ) InAs-rich SL absorption region, a 200 nm thick p-type (1 x 10 16 cm -3 ) InAs/GaSb/AlSb/GaSb high band gap SL barrier and an n-type (1 x 10 16 cm -3 ) InAs-rich SL contact layer. The electrical performances of this structure have been evaluated and compared to the equivalent pin photodiode having the same absorption region. As expected, the MWIR nBp device is limited by the diffusion current on the overall range of temperature from 77 up to 200K whereas the pin photodiode is limited by the G-R current below a temperature of 136K.
This environment is paired with Smart Monkey, a program that automates the installation, the testing of applications and the cleaning of the environment afterwards. The objective of Glassbox is to collect features for machine learning algorithm, to classify applications as malware or as benign. In the following sections we will present the related work about dynamic analysis systems, we will expose the architecture of both Glassbox and Smart Monkey. Finally, we will present the average coverage of basic blocks of Smart Monkey on the AndroCoverage Dataset  [3].
Features Analyzed Since the rise of Android dynamic analysis systems, the use of system calls have been the leading approach. System calls are the functions of the kernel space, available to the user space. It gives the capacity to manipulate hard drive files or to control processes. System calls can describe a program behaviors, from a low level perspective. The retrieval of those calls can be achieved in two ways, mainly: • Virtual Machine Introspection -This is a technique available for emulators, which enables the host to monitor the guest. It cannot be detected by the guest since it is out of its reach and it is therefore convenient for security analysis. Andrubis  [2] , Copper-Droid  [14]  and DroidScope  [10]  take advantage of VMI to retrieve, unseen by the target malware, all systems calls done by the guest Android virtual machine.
If a tainted value is used in a sink, it means data source has leaked. It enables to detect data leakage even if this data have been ciphered or encoded. An application that leaks data is not necessarily a malware, as data leakage is the business of both malware and user tracking frameworks in commercial applications -which constitutes essentially a large part of "goodware" applications. Whereas this feature gives useful insights on the application behaviors for manual analysis, its utility for automatic malware detection needs to be proved. Moreover the implementation and execution of taint tracking is costly, which leads us not to choose this feature for now. Java calls is another feature of interest as it captures an explicit behavior of the application. There are several ways to collect them: • Application instrumentation -This strategy does not need any modification of the Android source code and is not dependent on Android version.
The application can be modified in order to dump targeted method parameters and return values. APImonitor  [18]  is a tool that enables the instrumentation of targeted Java calls. It reverses the application into smali, a human friendly format equivalent to the Java bytecode, with the baksmali [19] utility. Then, it adds monitor routines around the targeted calls and it recompiles the code with the smali [19] utility. This strategy is used by the authors of  [13]. • DVM/ART instrumentation -The DVM (Dalvik Virtual Machine) or ART (Android RunTime, Android API version ≥ 4. 4) is the system that interprets and executes all the application instructions. All Java calls converge to this component. Hence, by hooking the execution of DVM/ART, one can monitor and control all Java calls, their arguments and their return values.
That implies the modification of Android source code and its compilation to a custom ROM. This is the strategy we chose to use for collecting Java calls. We prefer this method for keeping the application behaviors pristine, and particularly not inducing additional bugs. Andrubis  [2]  and DroidScope  [10]  use similar approaches for tracing method calls. For the last features, they are highly marginal. Here, Andrubis reported the retrieval of targeted shared library calls. Another data are the network communications. Only Andrubis reported the utilization of features from network communications, but without any further details. Our system.
Automated Testing Strategies Dynamic analysis does not consist of launching the application and waiting the malware to show its malicious behaviors off. Malware are using logic bombs for hiding the payload. Logic bombs are a malicious piece of code that is executed after a condition is triggered. It means we need to test each application as a real user could have done it. For achieving this objective, several strategies have been used in the past: • Black Box testing strategies -This class of strategies does not take the application source code into account, it focuses on sending inputs in the application without any prior information. This is the commonly used strategy. Monkey  [21]  is a dedicated tool created by Google for this task. It generates random events in a fast pace. Events range from system events (home/wifi/bluetooth/sound volume etc.
) to navigation events (motion, click). Because of its capacity to quickly explore applications activities, it has been used by most of dynamic analysis systems (AASandbox  [7] , AppsPlayground  [11] , Andrubis  [2] ,  [13] , HADM  [15] , Maline  [16] ). Monkey is sometimes confused with Monkey Runner  [22]  in the literature, which is a python library for writing Android test routines. • White Box testing strategies -This class of strategies takes the application source code into account. It focuses on sending specific inputs in the application for triggering targeted code paths. It requires the information from the static analysis of the application. Parsing the code is needed, to find the target methods and all their triggering conditions. SmartDroid  [9]  and IntelliDroid  [17]  determine all paths to sensitive API calls, then execute one of the paths to the target with dynamic analysis.
Android Instrumentation A custom Android OS has been made, based on the Android Open Source Project (AOSP)  [27]. The objective here is to log dynamically each Java call of a targeted application. This involves hooking these calls, at a point where all of them pass through. We instrumented ART (Android RunTime)  [28] , the Android managed runtime system that executes application instructions. With the default parameters, we found that ART (at least until Android Marshmallow ) have the following important behaviors for our study: • The first time Android is launched, Java Android API libraries and applications are optimized and compiled to a native code format called OAT  [29]. • Each time a new application is installed, it is optimized and compiled to OAT format. • Java methods can be executed in three ways: by an OAT JUMP instruction to the method address, by the ART interpreter for non-compiled methods (debugging purposes mostly), or via the Binder for invoking a method from another process or with Java Reflection.
Details on the Android Binder can be found in  [30]  chapter 4. A straightforward way of hooking Java calls is to instrument the ART interpreter. Unfortunately only a few calls are executed through it because most of the code is compiled into OAT and therefore it is not interpreted. We forced all calls to be interpreted by disabling several optimizations. The first one is the disabling of the compilation to OAT. That leads calls to be interpreted before executed. But others optimizations mechanisms comes into play, namely direct branching and inlining. The boot classpath contains the Android framework (Figure  4 ) and core libraries. They are always compiled in OAT resulting in a boot. oat file. This file is mapped into memory by the Zygote process, started at the initialisation of Android.
These textfields are filled with consistent values accordingly. For this task, we use databases of realistic data (samples can be found in the annexes). Uncategorised textfields are filled with a pseudo-random string. • The order of actions done matters. For example login and password textfields must be filled before validating. In the exploration, filling textfields and checkboxes takes precedence over the rest. • An application can register a receiver for a broadcast Android event like the change of phone state or wifi state. It can be done statically in the application manifest or dynamically. Those dynamical receivers could be hidden from static analysis with obfuscation. To trigger the receivers code, we test applications with a list of broadcast events that are often used by malware (a partial list is given in annexes).
Moreover, real SMS and phone calls are sent to the real device own number. We finally use the Monkey  [21]  program during the analysis. It can help to trigger behaviors requiring complex inputs combination that Smart Monkey could miss. At the end comes the cleaning phase. For our real device we keep a white list of regular processes and installed applicationsregular, system and device administrator applications. Nonauthorised processes are killed and applications uninstalled. Important phone configurations like wifi, data network and sounds are reset to a predefined value.
DISCUSSION Toward the standardization of the evaluation of automated testing methods for Android. Research community used different strategies for automated application testing, with different evaluation methods and different datasets. To promote the successful strategies for future researches on the domain, we need a standard for the experimentation. Otherwise, we cannot compare the results objectively. The research titled Automated Test Input Generation for Android: Are We There Yet?  [33]  shows the re-evaluation on the same ground of 5 published automated testing tools for Android. The experimental results found is far from what have been claimed in the published papers. Moreover, according to this study Monkey program have the best performances above all at around 53% average coverage of statements on 68 selected applications.
It could question the contribution of the main researches papers to the field. However, we believe the evaluation method lacks pertinence. To summarize, these observations reveal several problems on the experimental results: • (1) They are currently not reproductible. • (2) They cannot be compared to each other. • (3) They do not hightlight the contribution of the tested tool compared to Monkey program. To answer those problems, we propose the following rules: • (2) A common performance measure. We propose the average coverage of basic blocks (this measure is described in the Experimentation part). Statement coverage (also called line coverage) is considered as the weakest code coverage measure by specialists in software testing. This metric should not be used when another one is available.
For an argued reflection about coverage metrics, we refer to the paper What is Wrong with Statement Coverage  [34]. • (1)(2) A common dataset and common tools for instrumenting the applications. We propose the An-droCoverage Dataset  [3]. • (1)(2) A common configuration -Monkey arguments, a fixed seed for every random number generator used and application versions. These information are either present in annexes of this document or on the AndroCoverage Github web page. • (3) To assess the performance of the combination of both Monkey and the evaluated tool. Comparing separately, the performance of Monkey and the tested tool does not hightlight new code paths that have been triggered by the evaluated tool. A complex method would not seem successful whereas it would have triggered complex conditions that Monkey could never find.
EXPERIMENTATION We use the AndroCoverage Dataset  [3]  for our experimentation. It contains 100 applications from F-Droid, which is a repository of free and open source (FOSS ) applications. They have been manually selected with the following criteria for each application: • It does not depend on a third party library or application as an automatic tool would be unable to install it. • It does not depend on root privilege. To meet the requirement of a maximum of testing tools configuration, we stick with regular privilege. • It does not depend on local or temporary remote data. We want the application to be usable worldwide and in the long-term. This category excludes applications for a temporary event or a specific country. Our goal is to use applications which show a large variety of different and steady behaviors.
It is why we predict that performance on the AndroCoverage Dataset will be overestimated compared to the average of real applications. This dataset is to be used to compare the performance of different automated testing tools on the same ground. The AndroCoverage Dataset is supplied with tools which instruments the application, adding monitoring routines for code coverage. We used them for comparing the performance between Monkey and Smart Monkey. These tools are partially founded on BBoxTester  [35] , a tool for measuring the code coverage for Black Box testing of Android applications. Smart Monkey runs Monkey at the beginning of the analysis. For a fair trial, we tested the performance of its code coverage with and without Monkey. The configuration of the Monkey tool has been described in annexes.
The results are presented on Figure  5  The Monkey program tends to generate bugs with the instrumentation. For a significant amount of applications we are unable to get the coverage rate. We note that the same applications crash between Monkey and Smart Monkey so the crash rate has no effect on the comparison of performance between both programs. For the analysis of the results, we focus mainly on the average coverage of basic blocks, as it is the most significant measure. Here are definitions of the vocabulary used in the experimentation: • A basic block is an uninterrupted or continuous section of instructions. It means that when the first instruction of a basic block is executed, all other instructions of the block will also be executed, only one time. A basic block begins at the start of the program or at the target of a control transfert instruction (JUMP/-CALL/RETURN).
It ends at the next control transfert instruction. • The basic block coverage for an application is the number of unique basic blocks executed at runtime divided by the number of unique basic blocks present in the source code. • The average coverage of basic blocks, is the sum of the basic block coverage of all applications divided by the number of applications. The results shows Monkey and Smart (Smart Monkey without Monkey) do no trigger the same code paths. They have approximately the same performance but their combination leads to an increase of 13. 52% of average coverage of basic blocks ( smartmonkeyac monkeyac = 1. 1352) compared to the Monkey program only.
CONCLUSION & FUTURE RESEARCH This paper contributes to the domain of dynamic analysis system for Android in three ways. First, we presented Glassbox a functional prototype of a platform that uses real devices, controls network and GSM communications to some extends and monitors Java calls, systems calls and network communication content. Second, we experimented Smart Monkey, an automatic testing tool with a Grey Box testing strategy. We showed that it enhances the application code coverage compared to the common Black Box testing tool called Monkey. Last, we presented a method of evaluation of automated testing tools to research community. This method covers the problems of reproducibility, the comparison with other works and of the contribution measurement of the tool. We made the dataset available on Github under the name AndroCoverage.
The next step is to use Glassbox on malware/benign applications and to use the features found on a machine learning algorithm. We are working on the classification of these data with a neural network. Monkey configuration monkey -s 0 --pct -syskeys 0 --pctappswitch 0 --throttle 50 -p < package -name > -v 500 -s 0: The seed of the random number generator is fixed to 0 --pct -syskeys 0: No system key events are sent , such as Home , Back , Start Call , End Call , or Volume inputs. --pct -appswitch 0: No startActivity () are issued as calling the instrumentation activity another time breaks it. --throttle 50: The delay between events is fixed to 50 milliseconds. 500: A total of 500 events are sent.
Products In addition to this experimental design paper, and papers describing the new climate proxy syntheses, once the model simulations are complete we anticipate the production of overarching papers describing the "large-scale features" of the model simulations, and model-data comparisons. Following this, we anticipate a number of spin-off papers looking at various other aspects of the model simulations (e. g. ENSO, ocean circulation, monsoons). In particular we expect papers that explore the relevance of the DeepMIP simulations and climate proxy syntheses for future climate, for example through model developments that arise as a result of the model-data comparison, or emergent constraints (Bracegirdle and Stephenson, 2013) on global-scale metrics such as climate sensitivity. Furthermore, we will encourage modelling participants to publish individual papers that describe their own simulations in detail, including how the boundary conditions were implemented.
WA makes it possible to change the content, style, structure, and functionality of a Web page without the need for changing the source code at server-side. The scripts that perform a specific adaptation are called augmenters  [7] , and it is usual that their creators have some level of expertise in JavaScript. The amount of features that can be opportunistically added to an existing application are countless, moreover, taking into account the possibility of consuming information from a wide range of sources. For instance, EBay products can be augmented with more information for the user to decide whether to purchase it or not by summarizing opinions on the sellers or checking the price of the product in other sites. In the same way, books in Goodreads can be augmented with more options for buying a copy, promoting local online stores, and actors in IMDB may also include pictures from Google Images in the case there are no, or few, images in their profiles.
In this paper, we focus on mobile Web augmentation, adding different kinds of mobile-based features to existing Web applications. Applying Web augmentation on mobile devices implies that, besides the common aspects that may be adapted typically (e. g. , look and feel, personalization, recommendations), mobile and context-aware features can be contemplated as well. For instance, we could take into account the user's position for augmenting a news portal with geopositioned and content-related videos and tweets. By taking the current user's position through the Geoposition Web API (https://developer. mozilla. org/en-US/docs/Web/API/Geolocation), it is possible to use it for building geolocated queries through the Data API of YouTube (https://developers. google. com/youtube/v3/docs/search/list) and the REST API of Twitter (https://dev.
twitter. com/rest/reference/get/ geo/search). Then, the retrieved content could be injected into a news portal's Web page by using the Addon-SDK (https://developer. mozilla. org/en-US/Add-ons/Firefox for Android) of Firefox. We can listen for device's orientation changes (DeviceOrientationEvent (https://developer. mozilla. org/en-US/docs/Web/API/DeviceOrientationEvent)) and augment Google Maps' Web page with a real world view (camera capture) and an arrow pointing to the target location when the user tilts the device vertically. We can calculate the perceived sound level by using the WebRTC API (https:// webrtc. github. io/samples/src/content/getusermedia/volume/) for automatically adapting the volume of YouTube videos at middle levels or stopping/resuming the reproduction at the high ones.
Although there are already some approaches for augmenting Web applications from mobile Web browsers, such as  [8] [9] [10] , they are aimed and limited to producers with programming skills (from now on, developers). In a previous work, we have presented a mobile Web augmentation (MoWA) approach  [11, 12] , which comprises a software framework and a set of tools for developers. Basically, MoWA provided developers with a framework for creating mobile Web applications based on client-side adaptation, including the addition of new (e. g. , location-based) contents and functionality (such as context-awareness) directly on the frontend, that is, the Web browser. In this paper, by incorporating EUD principles, we change our target audience from developers to broader ones: producers with no programming skills (from now on just producers).