Vous êtes sur la page 1sur 11


Introduction: We used Android as our operating system for our project. Our project is Text To Speech. This app reads the text which is in your phone or which you have written in the text box which is provided in the app. This app has different languages installed in it, unfortunately we havent added the Indian languages, but we have Spanish, German, and French, installed in it. When the user selects the required language slang; this app reads the text in that particular slang. We can be more specific about this app by saying that this is more useful for pronunciation. This app helps in pronouncing the particular word or any sentence in particular slang say for example French or German or Spanish. Background: 1. Android keeps all the resources under res directory in the application .apk (archive like jar for java apk for android). 2. Android keeps all the needed information about resources in resource table dumped as resources.arsc file. The resource table keeps track of the resources, their associated ids, and their packages. To build any android project there are predefined steps that we need to take:

1. Android Asset Packaging Tool (aapt.exe) It An Android SDK tool that generates a resource table from the <res> directory of an android application whose assets (resources) are to be packaged together. It takes the android jar as base library, Android Manifest file and application <res> folder for generating the resource table. The resource table generated is dumped as resources.arsc file. The mapping of resources and their associated ids are dumped into an R.java file for reference to develop java classes of the application. The resources.arsc file along with the needed resources in res folder is bundled within the application apk file. This <res> folder generated in apk file contains the binary equivalent xml files in the res folder provided as input except for the xml files from the values folder. 2. javac Compile all the application java files along with the R.java generated by the aapt tool. 3. dex It generates a .dex file from all the classes. Dex file is nothing but all classes combined in Dalvik Byte code format. This generates a classes.dex file of all the converted class files. 4. apkbuilder It prepares the final apk file from the dex file and the initial apk file. By default it signs the apk with the debug keystore of the

android. We can also provide our keyStore. We also can opt for unsigned apk file by specifying the u option. 5. apk signing if needed. If we opt for unsigned apk in apkbuilder, then we need to sign that apk by our own.

Memory Management In Android Operating System

Introduction about Android memory:
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

Android Memory:
Android is a Linux based OS with 2.6.x kernel, stripped down to handle most tasks pretty well. It uses native open source C libraries that have powered Linux machines for years. All the basic OS operations like I/O, memory management, and so on, are handled by the native stripped-down Linux kernel.

How to use memory for each application?

Androids process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual

machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications. Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources. Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the under- lying services, features, and hardware. Dalvik Virtual Machine Dalvik is a register-based virtual machine thats been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.

The Dalvik Virtual Machine:

One of the key elements of Android is the Dalvik virtual machine. Rather than use a traditional Java virtual machine (VM) such as Java ME (Java Mobile Edition), Android uses its own custom VM designed to ensure that multiple instances run efficiently on a single device. The Dalvik VM uses the devices underlying Linux kernel to handle low-level functionality including security, threading, and process and memory management. All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host

application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation. The Dalvik VM executes Dalvik executable files, a format optimized to ensure minimal memory foot- print. The .vex executable is created by transforming Java language compiled classes using the tools supplied within the SDK.

Understanding Application Priority and Process States:

The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An applications priority is equal to its highest-priority component. Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by inter process dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports. All Android applications will remain running and in memory until the system needs its resources for other applications.

Its important to structure your application correctly to ensure that its priority is appropriate for the work its doing. If you dont, your application could be killed while its in the middle of something important. The following list details each of the application states shown in Figure, explaining how the state is determined by the application components comprising it: Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.

Active processes include:

Activities in an active state; that is, they are in the foreground and responding to user events. Activities, services, or broadcast receivers that are currently executing an on Receive event

handler. Services that are executing an on-Start, on-Create, or on-Destroy event handler. Visible Processes Visible, but inactive processes are those hosting visible Activities. As the name suggests, visible Activities are visible, but they arent in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and theyll only be killed in extreme circumstances to allow active processes to continue. Started Service Processes, Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services dont interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and wont be killed unless resources are needed for active or visible processes. Background Processes, Processes hosting Activities that arent visible and that dont have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes. Empty Processes to improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of

applications when theyre re-launched. These processes are routinely killed as required.

How to use memory efficiently?

Android manages opened applications which are running in the background, so officially you shouldnt care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness in everyday performance. We can use advanced task killer/task manager and it does its job very well.

Resource Management In Android

The component development with android has one big difficulty in the way Resource Management of Android. The resources provided in components are not accessible in the easy way when the component is embedded in any application. Android doesnt keep any distinguishing factor to separate the component resources with application resources so that at runtime the respective component get its own resources. The intent is to find out any workaround to mix up the resources of the application and the component it uses in a fashion so that the application will get its resources and the component will get its resources.

Approaches adopted:

The approaches adopted involved two Android applications primarily using resources in the form of layouts and values. Other resource of type anima, draw able etc. Were to be dealt with later. One of the android applications acted as a component derived from an Android View and made use of a basic layout with values resources used to lay out a simple Text View. The other application acted as the main Android application making use of the component by instantiating it and using the generated View as a child in the main layout. Hence, it was required that the component be compiled into a library with dependant resources which would be resolved at runtime when the application statically links to the component.

1. Using exported jar from eclipse

Export the component classes and resources as jar from eclipse and provide it to application as external library. By this all the classes and resources in the component get merged with application. The final apk prepared by this method was having all the resources in the res folder and the R.java was generated for all these resources merged. So the ids for component resources too again got generated. This approach compiled fine but failed at runtime, since the resource ids from component R.java and those generated in apk did not match. The application gave ResourceNotFoundException for the resource id provided in component R.java which it wont find in application resources.

2. Using aapt with two different resource directories Provide two different resources directories to aapt, one for application and one for component, using S argument. In this approach, it gave us errors related overlay since the xml files in both the packages were different. So we tried to generate the R.java like first approach and kept the class file in the component package. But that approach too failed since the R.java contains all static final values which get inline replaced in the class files which used the previous R class. Hence at runtime, the component classes looked for a mapping of resources with the same ids with which the R.java was generated.

3. Programmatically merging two resource tables of component and application

Tried to change the aapt tool source code to merge the component resource table with application resource table and then store the table in application apk so that class files in component get all the references as generated during their compilation time. We partly succeeded in this trial and were able to generate different resource ids for the application resources. But when we merged the resource tables and dumped both the tables in the resources.arsc file, it gave us exception at code in aapt for verification of the generated resources.arsc file mentioning that the application cant have two packages. This is because android assumed one package unique for the

application and derived all the things related to the application using that package. So the final approach remained is to add all the resource information of the component under application package. During implementation of this approach, we added one L option to provide the component jar file. When aapt tool is run using this option along with x option, it generates different resource ids for the application resources. The thing remained is to reverse engineer how the ResTable parse the resources.arsc file and use the logic to add the component resources under application package.