INDUSTRIAL TRAINING

REPORT

GIRISH CHANDRA
1609010051
TRAINING
INFORMATION

Reg. No. AND/200

NAME : Girish Chandra
YEAR : Fourth

ORGANIZATION: EI System Services

PLACE OF TRAINING: Delhi Technology University ,Shahbad Daultatpur Village

Rohini,Delhi
DESIGNATION OF SUPERVISOR: Director, Workshops And Stores
PERIOD: FROM 27/05/2019 to 26/06/2019
DURATION: 4 weeks
FIELD OF TRAINING: Android Application Development

1
ACKNOWLEDGEMENT

It gives me immense pleasure in presenting industrial training report on the

Android Application Development. I acknowledge the enormous assistance and
excellent co-operation extended to by my respected guide Prof. Mayur Dev
Sewak.

I would also like to thank the staff members for their valuable support.
Lastly I would like to express my heartfelt indebtedness towards all those who
have helped me directly or indirectly for the completion of the training.

- Mr. Girish Chandra

(Roll No. 1609010051)

4
Table of Contents

Chapter 1

1.1 Abstract 5

Chapter 2
2.1 Introduction 6

Chapter 3

3.1 Features of Android OS --------------------------------------------------------------

7
Chapter 4

1. Android Architecture 8

1. Application Framework 9

2. Libraries 10

3. Android Runtime 11

4. Linux Kernal 12

Chapter 5

5.1 Architecture for Secure Data storage 13

Chapter 6

1. Execution Environment 16

2. The Dalvik Virtual Machine 19

Chapter 7

1. Lifecycle of an Android Application 20

2. Security and permissions in Android 22

3. Development Tools
Chapter 8

1. Submitting Your App to the Android Market

5
Conclusion 25

References 26

Glossary 27

White Paper 28

6
 Chapter 1
1. ABSTRACT

Android is a software stack for mobile devices that includes an operating system, middleware and key
applications. Android is a software platform and operating system for mobile devices based on the Linux
operating system and developed by Google and the Open Handset Alliance. It allows developers to write
managed code in a Java-like language that utilizes Google-developed Java libraries, but does not support
programs developed in native code.
The unveiling of the Android platform on 5 November 2007 was announced with the founding of the Open
Handset Alliance, a consortium of 34 hardware, software and telecom companies devoted to
advancing open standards for mobile devices. When released in 2008, most of the Android platform will be
made available under the Apache free-software and open-source license.

1Open - Android allows to access core mobile device functionality through standard API calls. All
applications are equal - Android does not differentiate between the phone's basic and third-party
applications -- even the dialer or home screen can be replaced. Breaking down boundaries - Combine
information from the web with data on the phone -- such as contacts or geographic location -- to create new
user experiences. Fast and easy development - The SDK contains what need to build and run Android
applications, including a true device emulator and advanced debugging tools.

7
 Chapter 2

1. INTRODUCTION

Android is a software stack for mobile devices that includes an operating system, middleware and
key applications. Android is a software platform and operating system for mobile devices based on
the Linux operating system and developed by Google and the Open Handset Alliance. It allows
developers to write managed code in a Java-like language that utilizes Google-developed Java
libraries, but does not support programs developed in native code.
The unveiling of the Android platform on 5 November 2007 was announced with the founding of
the Open Handset Alliance, a consortium of 34 hardware, software and telecom companies devoted
to advancing open standards for mobile devices. When released in 2008, most of the Android
platform will be made available under the Apache free-software and open-source license.

1.THE BIRTH OF ANDROID Google Acquires Android Inc.

In July 2005, Google acquired Android Inc., a small startup company based in Palo Alto, CA.
Android's co-founders who went to work at Google included Andy Rubin (co-founder of Danger),
Rich Miner (co-founder of Wildfire Communications, Inc), Nick Sears (once VP at T-Mobile), and
Chris White (one of the first engineers at WebTV). At the time, little was known about the functions
of Android Inc. other than they made software for mobile phones.

2.Open Handset Alliance Founded

On 5 November 2007, the Open Handset Alliance, a consortium of several companies which
include Google, HTC, Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel and NVIDIA, was
unveiled with the goal to develop open standards for mobile devices. Along with the formation of
the Open Handset Alliance, the OHA also unveiled their first product, Android, an open source
mobile device platform based on the Linux operating system.

3.Hardware
Google has unveiled at least three prototypes for Android, at the Mobile World Congress on
February 12, 2008. One prototype at the ARM booth displayed several basic Google applications. A
'd-pad' control zooming of items in the dock with a relatively quick response.

8
 Chapter 3
3.1 Features of Android OS

· Application framework enabling reuse and replacement of components

· Dalvik virtual machine optimized for mobile devices

· Integrated browser based on the open source WebKit engine

· Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the

OpenGL ES 1.0 specification (hardware acceleration optional)

· SQLite for structured data storage

· Media support for common audio, video, and still image formats (MPEG4, H.264, MP3,
AAC, AMR, JPG, PNG, GIF)

· GSM Telephony (hardware dependent)

· Bluetooth, EDGE, 3G, and WiFi (hardware dependent)

· Camera, GPS, compass, and accelerometer (hardware dependent)

· Rich development environment including a device emulator, tools for debugging, memory
and performance profiling, and a plugin for the Eclipse IDE

9
  Chapter 4

4.1 Android Architecture

The following diagram shows the major components of Android

Figure 1: Architecture of Android OS

1
0
4.1.1 Application Framework
Developers have full access to the same framework APIs used by the core applications. The application
architecture is designed to simplify the reuse of components; any application can publish its capabilities
and any other application may then make use of those capabilities (subject to security constraints enforced
by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

· A rich and extensible set of Views that can be used to build an application, including lists, grids, text
boxes, buttons, and even an embeddable web browser

· Content Providers that enable applications to access data from other applications (such as Contacts),
or to share their own data

· A Resource Manager, providing access to non-code resources such as localized strings, graphics, and
lat files

· A Notification Manager that enables all applications to display custom alerts in the status bar

· An Activity Manager that manages the life cycle of applications and provides a common navigation
backstack

1
1
4.1.2 Libraries
Android includes a set of C/C++ libraries used by various components of the Android system.
These capabilities are exposed to developers through the Android application framework. Some of
the core libraries are listed below:

·System C library - a BSD-derived implementation of the standard C system library (libc), tuned for
embedded Linux-based devices

·Media Libraries - based on PacketVideo's Open CORE; the libraries support playback and recording of
many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC,
AMR, JPG, and PNG

·Surface Manager - manages access to the display subsystem and seamlessly composites 2D and 3D
graphic layers from multiple applications

·LibWebCore - a modern web browser engine which powers both the Android browser and an
embeddable web view

·SGL - the underlying 2D graphics engine

·3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D
acceleration (where available) or the included, highly optimized 3D software rasterizer

·Free Type - bitmap and vector font rendering

SQLite - a powerful and lightweight relational database engine available to all applications.

12
4.1.3 Android Runtime
Android includes a set of core libraries that provides most of the functionality available in the core libraries
of the Java programming language. Every Android application runs in its own process, with its own
instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs
efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for
minimal memory footprint. The VM is register-based, and runs classes compiled by a Java
language compiler that have been transformed into the .dex format by the included "dx" tool. The Dalvik
VM relies on the Linux kernel for underlying functionality such as threading and low-level memory
management.

At the same level there is Android Runtime, where the main component Dalvik Virtual Machine is located.
It was designed specifically for Android running in limited environment, where the limited battery, CPU,
memory and data storage are the main issues. Android gives an integrated tool “dx”, which converts
generated byte code from .jar to .dex file, after this byte code becomes much more efficient to run on the
small processors.

Figure 2: Conversion from .java to .dex file

As the result, it is possible to have multiple instances of Dalvik
virtual machine running on the single device at the same time. The
Core libraries are written in Java language and contains of the
collection classes, the utilities, IO and other tools.

13
4. Linux Kernal
Android Architecture is based on Linux 2.6 kernel. It helps to manage security, memory
management, process management, network stack and other important issues. Therefore, the user should
bring Linux in his mobile device as the main operating system and install all the drivers required in order
to run it. Android provides the support for the Qualcomm MSM7K chipset family. For instance, the current
kernel tree supports Qualcomm MSM 7200A chipsets, but in the second half of 2008 we should see mobile
devices with stable version Qualcomm MSM 7200, which includes major features:

1. WCDMA/HSUPA and EGPRS network support

2. Bluetooth 1.2 and Wi-Fi support

3. Digital audio support for mp3 and other formats

4. Support for Linux and other third-party operating systems

5. Java hardware acceleration and support for Java applications

6. Qcamera up to 6.0 megapixels

7. gpsOne – solution for GPS

14
 Chapter 5
5.1 Architecture for Secure Data Storage

Figure 3 Android and Secure Local Data Storage

Secure data storage solution that could potentially be deployed on Android. It

is as shown in the figure. However, many shortcomings of the design have
been addressed. Additional security highlights will be presented at the end of
the section.
Using figure 3, we have the following workflow:
1. The user enters his credentials on the handset.
2.The credentials are not sent to the SSO service over the network. Instead,
the credentials are used as
the passphrase to decrypt the local public/private key pair of the user. We
define the public/private key pair to be of type RSA and of at least 4096 bits
in size. Already we gain the advantage that the user’s password is not sent
over the network.
3.The private key is used to decrypt the symmetric cipher key. The
symmetric cipher key is used to encrypt/decrypt any locally cached data. A 15
strong symmetric cipher like 3DES is used.
4.All data found in the local cache is encrypted with the symmetric cipher
 5. If the requested data is not locally cached or expired. We must communicate with the SSO service
again to be able to receive fresh data from the Restful web services. However, unlike the
architecture presented in section 2 of this document, we login to the SSO server using a hostile
challenge based on the private key of the user. As such, we login with the SSO system using
public/private key infrastructure. The user name and the password are never sent over the network.
The SSO system can identify the user based on this challenge and returns a 496 bit alpha numeric
token.
6. The tokens generated by the SSO system are set to automatically expire after a given period of time.
7. On reception of the SSO token. The Android background application can now communicate with
any Restful web services that adhere to the same SSO federation. Public/private key infrastructure is
once again used to setup a secure communication channel between the phone and the server. The
certificates of the servers that host the web services are procured from the same certificate authority
that shipped with the phone.
8. On reception of a request, the SSO token is extracted from the request. The web service calls upon
the SSO system to authorize the operation.
9. On reception of the data, the symmetric cipher described in bullet #3 above is used to encrypt the
data before it reaches any local persistent storehouse.
10. Data is returned to the user facing application.

Additional security notes:

1. The public/private key pair of the user is generated directly on the handset at install time. As such,
the private key has never left the phone nor has it been transferred over any network.
2. The certificate of the user must at least be registered once in the SSO application. This could be
done at install time of the handset application.
3. “Man-in-the-middle”38 attacks are not possible since the application is deployed with the CA
certificate of the company that will be hosting the web services.
4. If the device is lost, all the locally cached data is completely unreadable. The symmetric key that
encrypted this data is also unreadable. The public/private keys that are central to the security architecture
are protected by a passphrase.
5. The passphrase is the weakest link in the chain. If the user enters an overly simple password, access
could be gained to the private key and hence the locally cached data.
6. That being said, it would be possible to further extend this architecture to store the encrypted
symmetric key on the server. This way, even if the passphrase of the private key is compromised, the
locally cached data still cannot be accessed. This is because the encrypted strong symmetric cipher key is16
stored on the server. By the time the passphrase has been cracked, there has been ample time to report the
stolen phone and revoke this key from this user account on the server. Furthermore, under this scheme, the
key stored on the server is still encrypted. Even if this key is intercepted in transit it is useless without the
user’s private key.
7.It is also possible to enforce a strong password policy directly from the handset application.
8.Even if this design is significantly more secure than the previous iteration, to the user, the experience is
the same. The user must enter a username and password to prove his identify.
9.We could augment the architecture in yet another direction. The local caching system could also require
an SSO token and subsequently request authorization from an SSO system. Such a design would prevent
terminated employees, i.e., an Individual who already knows what the local credentials are, from
accessing the locally cached data.

17
 Chapter 6
6.1 Execution Environment

Figure 4 Regular Java Execution Process

18
Figure 5 Android Execution Environment

19
 Figures 4 and 5 represent the regular Java and Android execution paths respectively. It is interesting
to note here however is that the Android compilers do not operate on Java
language code. Instead, the Android translators work on the resulting Java bytecode emitted from a
traditional Java compiler.
As such, it is possible to reuse existing Java libraries, even if the original source code is not
available. Such libraries must meet stringent requirements however, they need to:
1. adhere to the Java SE 5 dialect
2. not use any Java classes or packages found in Java SE 5 not found in the Android platform
3. not use any packages or classes specific to the Sun Microsystems platform
4. still behave in a predictable manner under the Apache Harmony Java environment

Following these guidelines, it’s possible to integrate existing Java source code, packages and
libraries piecemeal. Special care will be needed in the integration phase of such code but the potential
savings offered by such integration far outweighs the cost of rewriting well-coded, well-documented and
well-tested libraries ready for use. Furthermore, it is expected that has Apache Harmony matures, more and
more compatibility issues will be resolved further increasing the pool of available Java code that will be
able to execute unmodified under the Android platform.

20
6.2 The Dalvik Virtual Machine

The Dalvik Virtual Machine

The Dalvik virtual machine is an interpreter only machine optimized for use on low powered, low
memory devices like phones. Notably, Dalvik does not make use of just in time (JIT) Compilation to
improve the performance of an application at runtime. Furthermore, Dalvik is not a Java virtual machine.
This is because Dalvik is unable to read Java bytecode34, instead it uses its own bytecode format called
“dex”. Google claims this format allows battery power to be better-conserved at all different stages of
execution of an application. This means that standard Java SE applications and libraries cannot be used
directly on the Android Dalvik virtual machine.
Dalvik however stands at the center of the Android value proposition. Its low electrical power
consumption, rich libraries, and unified, non-fragmented application programming interfaces make it
stand out, or so Google hopes, over the fragmented ecosystem that is Java ME35 today.
Furthermore, since Dalvik uses the Java programming language but not the Java execution environment
(JVM), Google is free to develop Android without the need to license or obtain certification from Sun
Microsystems Inc, the legal owner of the Java trademark and brands.

21
 Chapter 7
1. Lifecycle of an Android Application
In most cases, every Android application runs in its own Linux process. This process is created for the
application when some of its code needs to be run, and will remain running until it is no longer needed and
the system needs to reclaim its memory for use by other applications.

An important and unusual feature of Android is that an application process's lifetime is not directly
controlled by the application itself. Instead, it is determined by the system through a combination of the
parts of the application that the system knows are running, how important these things are to the user, and
how much overall memory is available in the system.

It is important that application developers understand how different application components (in
particular Activity, Service, and IntentReceiver) impact the lifetime of the application's process. Not using
these components correctly can result in the system killing the application's process while it is doing
important work.

A common example of a process life-cycle bug is an IntentReceiver that starts a thread when it
receives an Intent in its onReceiveIntent() method, and then returns from the function. Once it returns, the
system considers that IntentReceiver to be no longer active, and thus its hosting process no longer needed
(unless other application components are active in it). Thus, it may kill the process at any time to reclaim
memory, terminating the spawned thread that is running in it. The solution to this problem is to
start a Service from the IntentReceiver, so the system knows that there is still active work being
done in the process.

To determine which processes should be killed when low on memory, Android places them into an
"importance hierarchy" based on the components running in them and the state of those components. These
are, in order of importance:

1. A foreground process is one holding an Activity at the top of the screen that the user is
interacting with (its onResume () method has been called) or an IntentReceiver that is currently running (its
onReceiveIntent () method is executing). There will only ever be a few such processes in the system, and
these will only be killed as a last resort if memory is so low that not even these processes can continue to
run. Generally at this point the device has reached a memory paging state, so this action is required in order
to keep the user interface responsive.

22
2. A visible process is one holding an Activity that is visible to the user on-screen but not in the
foreground (its onPause() method has been called). This may occur, for example, if the foreground activity
has been displayed with a dialog appearance that allows the previous activity to be seen behind it. Such a
process is considered extremely important and will not be killed unless doing so is required to
keep all foreground processes running.

3. A service process is one holding a Service that has been started with the startService() method.
Though these processes are not directly visible to the user, they are generally doing things that the user
cares about (such as background mp3 playback or background network data upload or download), so the
system will always keep such processes running unless there is not enough memory to retain all foreground
and visible process.

4. A background process is one holding an Activity that is not currently visible to the user (its
onStop() method has been called). These processes have no direct impact on the user experience. Provided
they implement their activity life cycle correctly (see Activity for more details), the system can kill such
processes at any time to reclaim memory for one of the three previous processes types. Usually there are
many of these processes running, so they are kept in an LRU list to ensure the process that was
most recently seen by the user is the last to be killed when running low on memory.

5. An empty process is one that doesn't hold any active application components. The only reason to
keep such a process around is as a cache to improve startup time the next time a component of
its application needs to run. As such, the system will often kill these processes in order to balance
overall system resources between these empty cached processes and the underlying kernel caches.

When deciding how to classify a process, the system picks the most important level of all
the components currently active in the process.

23
7.2 Security and Permissions in Android

Android is a multi-process system, where each application (and parts of the system) runs in its own
process. Most security between applications and the system is enforced at the process level
through standard Linux facilities, such as user and group IDs that are assigned to applications.
Additional finer- grained security features are provided through a "permission" mechanism that enforces
restrictions on the specific operations that a particular process can perform.

Android mobile phone platform is going to be more secure than Apple’s iPhone or any other device
in the long run. There are several solutions nowadays to protect Google phone from various attacks. One of
them is security vendor McAfee, a member of Linux Mobile (LiMo) Foundation. This foundation
joins particular companies to develop an open mobile-device software platform. Many of the companies
listed in the LiMo Foundation have also become members of the Open Handset Alliance (OHA).

As a result, Linux secure coding practice should successfully be built into the Android development
process. However, open platform has its own disadvantages, such as source code vulnerability for black-hat
hackers. In parallel with great opportunities for mobile application developers, there is an expectation for
exploitation and harm. Stealthy Trojans hidden in animated images, particular viruses passed from friend to
friend, used for spying and identity theft, all these threats will be active for a long run.

Another solution for such attacks is SMobile Systems mobile package. Security Shield –an
integrated application that includes anti-virus, anti-spam, firewall and other mobile protection is up
and ready to run on the Android operating system. Currently, the main problem is availability for viruses
to pose as an application and do things like dial phone numbers, send text messages or multi-media
messages or make connections to the Internet during normal device use. It is possible for somebody to use
the GPS feature to track a person’s location without their knowledge. Hence SMobile Systems is ready to
notify and block these secure alerts. But the truth is that it is not possible to secure r mobile
device or personal computer completely, as it connects to the internet. And neither the Android phone nor
other devices will prove to be the exception.

24
7.3 Development Tools
The Android SDK includes a variety of custom tools that help develop mobile applications on the Android
platform. The most important of these are the Android Emulator and the Android Development Tools
plugin for Eclipse, but the SDK also includes a variety of other tools for debugging, packaging, and
installing r applications on the emulator.

Android Emulator

A virtual mobile device that runs on computer use the emulator to design, debug, and test r
applications in an actual Android run-time environment.

Android Development Tools Plugin for the Eclipse IDE

The ADT plugin adds powerful extensions to the Eclipse integrated environment, making creating and
debugging r Android applications easier and faster. If use Eclipse, the ADT plugin gives an incredible
boost in developing Android applications:

It gives access to other Android development tools from inside the Eclipse IDE. For example,
ADT lets access the many capabilities of the DDMS tool — taking screenshots, managing port-
forwarding, setting breakpoints, and viewing thread and process information — directly from Eclipse.

It provides a New Project Wizard, which helps quickly create and set up all of the basic files’ll need for a
new Android application.

It automates and simplifies the process of building r Android application.

It provides an Android code editor that helps write valid XML for r Android manifest and
resource files.

Dalvik Debug Monitor Service (ddms)

Integrated with Dalvik, the Android platform's custom VM, this tool lets manage processes on an emulator
or device and assists in debugging. can use it to kill processes, select a specific process to debug, generate
trace data, view heap and thread information, take screenshots of the emulator or device, and
more.

Android Debug Bridge (adb)

25
 The adb tool lets install application's .apk files on an emulator or device and access the emulator or
device from a command line. can also use it to link a standard debugger to application code running on an
Android emulator or device.

Android Asset Packaging Tool (aapt)

The aapt tool lets create .apk files containing the binaries and resources of Android applications.

Android Interface Description Language (aidl)

Aidl Lets generate code for an interprocess interface, such as what a service might use.

sqlite3

Included as a convenience, this tool lets access the SQLite data files created and used by Android
applications.

Trace view

This tool produces graphical analysis views of trace log data that can generate from r Android
application.

mksdcard

Helps create a disk image that can use with the emulator, to simulate the presence of an external
storage card (such as an SD card).

dx

The dx tool rewrites .class bytecode into Android bytecode (stored in .dex files.)

activityCreator

A script that generates Ant build files that can use to compile r Android applications. If are
developing on Eclipse with the ADT plugin, won't need to use this script.

26
 Chapter 8
GoingOffline

There’s a feature of HTML5 called the offline application cache that allows users
to run web apps even when they are not connected to the Internet. It works like this:
when a user navigates to your web app, the browser downloads and stores all the
files it needs to display the page (HTML, CSS, JavaScript, images, etc.). The next
time the user navigates to your web app, the browser will recognize the URL and
serve the files out of the local application cache instead of pulling them across the
network.

The Basics of the Offline Application Cache

The main component of the offline application cache is a cache manifest file that
you host on your web server. I’m going to use a simple example to explain the
concepts involved, then I’ll show you how to apply what you’ve learned to the Kilo
example we’ve been working on.
A manifest file is just a simple text document that lives on your web server and is
sent to the user’s device with a content type of cache-manifest. The manifest
contains a list of files a user’s device must download and save in order to function.
Consider a web directory containing the following files:
index.html logo.jpg scripts/demo.js styles/screen.css
In this case, index.html is the page users will load in their browsers when they visit
your application. The other files are referenced from within index.html. To make
everything available offline, create a file named demo.manifest in the directory with
index.html. Here’s a directory listing showing the added file:
demo.manifest index.html logo.jpg scripts/demo.js styles/screen.css

27
Next, add the following lines to demo.manifest:
CACHE MANIFEST
index.html logo.jpg scripts/demo.js styles/screen.css

The paths in the manifest are relative to the location of the manifest file. You can also use
absolute URLs like so (don’t bother creating this just yet; you’ll see how to apply this to
your app shortly):
CACHE MANIFEST
http://www.example.com/index.html http://www.example.com/logo.jpg
http://www.example.com/scripts/demo.js http://www.example.com/styles/screen.css

Now that the manifest file is created, you need to link to it by adding a manifest attribute
to the HTML tag inside index.html:
<html manifest="demo.manifest">

You must serve the manifest file with the text/cache-manifest content type or the browser
will not recognize it. If you are using the Apache web server or a compatible web server,
you can accomplish this by adding an .htaccess file to your web directory with the
following line:
AddType text/cache-manifest .manifest

If the .htaccess file doesn’t work for you, please refer to the portion of your web server
documentation that pertains to MIME types. You must associate the file extension .manifest with
the MIME type of text/cache- manifest. If your website is hosted by a web hosting provider, your
pro- vider may have a control panel for your website where you can add the appropriate MIME
type. I’ll also show you an example that uses a PHP script in place of the .htaccess file a little later
on in this chapter (because PHP can set the MIME type in code, you won’t need to configure the
web server to do that).

Our offline application cache is now in working order. The next time a user browses to
http://example.com/index.html, the page and its resources will load normally over the
network (replace example.com/index.html with the URL of your web app). In the back-
ground, all the files listed in the manifest will be downloaded locally. Once the down- load
completes and the user refreshes the page, he’ll be accessing the local files only. He can
now disconnect from the Internet and continue to access the web app.
 Mac OS X and the .htaccess File
If you are serving up web pages on your local network using the Apache web server that’s included
with Mac OS X, it will ignore any .htaccess file in your personal web folder (the Sites folder that’s
in your home directory). However, you can enable support for .htaccess by following these steps:
1.Open Applications→Utilities→Terminal and typing these commands (you’ll need to type your
password when prompted):
cd /etc/apache2/users sudo pico $USER.conf

This loads your personal Apache configuration file into the pico editor (you can see a list of editor
commands at the bottom of the screen—the ^ symbol indicates the Control key).
2.Use the arrow keys to move down to the line AllowOverride None, delete the word
None, and replace it with All.
3.Press Control-X to exit, answer Y to save changes, and press Return to save the file.
4.Start System Preferences, go to Sharing, and, if needed, click the lock icon labeled “Click the lock
to make changes.” Type your password when prompted.
5.Clear the checkbox next to Web Sharing and then check it again (this restarts Web Sharing). The
web server on your Mac should now respect the settings in .htac- cess files you put in your Sites
directory or its subdirectories.

Now that the user is accessing our files locally on his device, we have a new problem: how
does he get updates when we make changes to the website?
When the user does have access to the Internet and navigates to the URL of your web app,
his browser checks the manifest file on the site to see if it still matches the local copy. If
the remote manifest has changed, the browser downloads all the files listed in it. It
downloads these in the background to a temporary cache.

The comparison between the local manifest and the remote manifest is a byte-by-byte comparison
of the file contents (including comments and blank lines). The file modification timestamp or
changes to any of the resources themselves are irrelevant when determining whether or not changes
have been made.

If something goes wrong during the download (e.g., the user loses Internet connection), the
partially downloaded temporary cache is automatically discarded and the previous one
remains in effect. If the download is successful, the new local files will be used the next
time the user launches the app.

TheBasicsoftheOfflineApplicationCache | 95
Remember that when a manifest is updated, the download of the new files takes
place in the background after the initial launch of the app. This means that even
after the download completes, the user will still be working with the old files. In
other words, the currently loaded page and all of its related files don’t automatically
reload when the download completes. The new files that were downloaded in the
background will not become visible until the user relaunches the app.
This is very similar to standard desktop app update behavior. You launch an
app, it tells you that updates are available, you click Down- load Updates, the
download completes, and you are prompted to re- launch the app for the updates to
take effect.
If you want to implement this sort of behavior in your app, you can listen for the
updateready event of the window.applicationCache object, as de- scribed in “The
JavaScript Console” on page 106, and notify the user however you like.

Online Whitelist and Fallback Options

It is possible to force the browser to always access certain resources over the
network (this process is known as whitelisting). This means the browser will
not cache them locally and they will not be available when the user is
offline. To specify a resource as online only, use the NETWORK: keyword (the
trailing : is essential) in the manifest file like so:
CACHE MANIFEST
index.html scripts/demo.js styles/screen.css

NETWORK:
logo.jpg

This whitelists logo.jpg by moving it into the NETWORK section of the

manifest file. When the user is offline, the image will show up as a broken
image link (Figure 6-1). When he is online, it will appear normally (Figure
6-2).
If you don’t want offline users to see the broken image, use the FALLBACK
keyword to specify a fallback resource like so:
CACHE MANIFEST
index.html scripts/demo.js styles/screen.css

FALLBACK:
logo.jpg offline.jpg

Now, when the user is offline, he’ll see offline.jpg (Figure 6-3), and when
he’s online, he’ll see logo.jpg (Figure 6-4).

96 | Chapter 6: Going Offline

Figure 6-1. Whitelisted images will show up as broken links when the user is offline

Figure 6-2. Whitelisted images will show up normally when the user is online

OnlineWhitelistandFallbackOptions | 97
 Conclusion

Android is a truly open, free development platform based on Linux and open source. Handset
makers can use and customize the platform without paying a royalty.
A component-based architecture inspired by Internet mash-ups. Parts of one application can be used
in another in ways not originally envisioned by the developer. can even replace built-in components with
own improved versions. This will unleash a new round of creativity in the mobile space.
 Android is open to all: industry, developers and users

 Participating in many of the successful open source projects

 Aims to be as easy to build for as the web.

 Google Android is stepping into the next level of Mobile Internet

32
 References

1. White paper for “A Spectrum White Paper: Thoughts on Google Android” from Spectrum
data Technology. http://www.spectrumdt.com

2. http://code.google.com/android/ - Google Android official webpage

3. http://www.openhandsetalliance.com/ - Open Handset Alliance webpage

4. http://en.wikipedia.org/wiki/Android_(mobile_phone_platform)–Wikipedia information

5. http://googleblog.blogspot.com/ - Official Google Blog

33
Glossary

SDK - Software Development

Kit APIs - Application
Program Interfaces GUI -
Graphical User Interface
OHA - Open Handset Alliance
GPS – Global Positioning
system
LRU – Last Recently Used
MHTML – Mobile HTML
QoS – Quality of Service
WAP – Web Application
Protocol CSD – Circuit
Switched Data OTA – Over-
the-Air

34
Whitepaper

35