Android Operating System

Report on:

Mobile Security

(Android Security)

Subject: Network Security

Submitted by: 1. Kashif Javed (110165031)

2. Muhammad Jagangir (110165129)

Submitted to: Sir Sheraz

Android Operating System

Table of Contents:

1. Introduction to Android Operating System 2. Founders 3. Acquisition by Google 4. A brief history 5. Versions of Android Operating System 6. How Android Operating System Works 7. Vulnerabilities in Android Operating System

Android Operating System

What is android? Meaning: (general) “a robot with a human appearance”.

(Trademark):“an open-source operating system used for smartphones and tablet computers.

It’s an operating system used for smartphones and tablets. Most important thing about android is that it is open source.

A Brief History:

Founders: ‘Android Inc.’ was found by four genius programmers in 2003 at Palo alto, California:

Andy Rubin, now director of mobile platforms at Google.

Rich Miner (co-founder of Wildfire Communications, Inc.),

Nick Sears (once VP at T-Mobile) Chris White (headed design and

interface development at WebTV)

Android Inc. operated secretly, revealing only that it was working on software for mobile phones. That same year, Rubin ran out of money. Steve Perlman, a close friend of Rubin, brought him $10,000 in cash in an envelope and refused a stake in the company. Acquisition by Google Google acquired Android Inc. on August 17, 2005, making Android Inc. a wholly owned subsidiary of Google Inc. Key employees of Android Inc., including Andy Rubin, Rich Miner and Chris White, stayed at the company after the acquisition. Not much was known about Android Inc. at the time of the acquisition, but many assumed that Google was planning to enter the mobile phone market with this move. Post-acquisition development At Google, the team led by Rubin developed a mobile device platform powered by the Linux kernel. Google marketed the platform to handset makers and carriers on the promise

Android Operating System

of providing a flexible, upgradable system. Google had lined up a series of hardware component and software partners and signaled to carriers that it was open to various degrees of cooperation on their part. Speculation about Google's intention to enter the mobile communications market continued to build through December 2006. Reports from the BBC and The Wall Street Journal noted that Google wanted its search and applications on mobile phones and it was working hard to deliver that. Print and online media outlets soon reported rumors that Google was developing a Google-branded handset. Some speculated that as Google was defining technical specifications, it was showing prototypes to cell phone manufacturers and network operators. In September 2007, InformationWeek covered an Evalueserve study reporting that Google had filed several patent applications in the area of mobile telephony. Open Handset Alliance

On November 5, 2007, the Open Handset Alliance, a consortium of several companies which include Broadcom Corporation, Google, HTC, Intel, LG, Marvell Technology Group, Motorola, Nvidia, Qualcomm, Samsung Electronics, Sprint Nextel, T-Mobile and Texas Instruments unveiled itself. The goal of the Open Handset Alliance is to develop open standards for mobile devices. On the same day, the Open Handset Alliance also unveiled their first product, Android, a mobile device platform built on the Linux kernel version 2.6. On December 9, 2008, 14 new members joined, including ARM Holdings, Atheros Communications, Asustek Computer Inc, Garmin Ltd, Huawei Technologies, PacketVideo, Softbank, Sony Ericsson, Toshiba Corp, and Vodafone Group Plc. Android Open Source Project The Android Open Source Project (AOSP) is led by Google, and is tasked with the maintenance and development of Android. According to the project "The goal of the Android Open Source Project is to create a successful real-world product that improves the mobile experience for end users." AOSP also maintains the Android Compatibility Program, defining an "Android compatible" device "as one that can run any application written by third-party developers using the Android SDK and NDK", to prevent incompatible Android implementations. The compatibility program is also optional and free of charge, with the Compatibility Test Suite also free and open-source. Version history Android has seen a number of updates since its original release, each fixing bugs and adding new features. Each version is named, in alphabetical order, after a dessert. Android 5.0 - Lollipop

Android Operating System

Android 4.4 - KitKat

Android 4.1-4.3 - Jelly Bean

Android 4.0 - Ice Cream Sandwich

Android Operating System

The follow-up to Honeycomb was announced at Google IO in May 2011 and released in December 2011. Dubbed Ice Cream Sandwich and finally designated Android 4.0, Ice Cream Sandwich brings many of the design elements of Honeycomb to smartphones, while refining the Honeycomb experience.

Android 3.X - Honeycomb

Android 3.0 came out in February 2011 with the Motorola Xoom. It's the first version of Android specifically made for tablets, and brings a lot of new UI elements to the table. Things like a new System bar at the bottom of the screen to replace the Status bar we see on phones, and a new recent applications button are a great addition for the screen real estate offered by Android tablets.

Some of the standard Google applications have also been updated for use with Honeycomb, including the Gmail app and the Talk app. Both make great use of fragments, and the Talk app has video chat and calling support built in. Under the hood, 3D rendering and hardware acceleration have been greatly improved.

We can't talk about Honeycomb without mentioning that it also shows Google's new distribution method, where manufacturers are given the source code and license to use it only after their hardware choices have been approved by Google. This dampens third party development, as the source code is no longer available for all to download and build, but Google assures us they will address this issue in the future.

Improvements to Honeycomb were announced at Google IO in May 2011 as Android 3.1, and Android 3.2 has followed.

Android 2.3 - Gingerbread

Android Operating System

Android 2.3 came out of the oven in December 2010, and like Eclair, has a new "Googlephone" to go along with -- the Nexus S. Gingerbread brings a few UI enhancements to Android, things like a more consistent feel across menus and dialogs, and a new black notification bar, but still looks and feels like the Android we're used to, with the addition of a slew of new language support.

Gingerbread brings support for new technology as well. NFC (Near Field Communication) is now supported, and SIP (Internet calling) support is now native on Android. Further optimizations for better battery life round out a nice upgrade.

Behind the scenes, the fellows at Mountain View spent time with more JIT (the Just-In-Time compiler) optimizations, and made great improvements to Androids garbage collection, which should stop any stuttering and improve UI smoothness. Round that out with new a multi-media framework for better support of sound and video files.

Versions of Android older than 2.3, while still used on a small number of devices, are considered "legacy" versions and are generally unsupported by Google, manufacturers and app developers.

Android 2.2 - Froyo

Android 2.2 was announced in May 2010 at the Google IO conference in San Francisco. The single largest change was the introduction of the Just-In-Time Compiler -- or JIT -- which significantly speeds up the phone's processing power.

Along with the JIT, Android 2.2 also brings support for Adobe Flash 10.1. That means you can play your favorite Flash-based games in Android's web browser. Take that, iPhone!

Froyo also brought native support for tethering, meaning you could use your Android smartphone's data connection to provide Internet (wirelessly or with a USB cable) to just about any device you want. Sadly, most carriers will strip this native support in exchange for some sort of feature they can charge for. (Can't really blame them, can you?)

Android 2.0/2.01/2.1 - Eclair

Eclair was a pretty major step up over its predecessors. Introduced in late 2009, Android 2.0 first appeared on the Motorola Droid, bringing improvements in the browser, Google Maps, and a

Android Operating System

new user interface. Google Maps Navigation also was born in Android 2.0, quickly bringing the platform on par with other stand-along GPS navigation systems.

Android 2.0 quickly gave way to 2.0.1, which the Droid received in December 2009, mainly bringing bugfixes. And to date, the Droid remains the phone phone to have explicitly received Android 2.0.1.

The now-defunct Google Nexus One was the first device to receive Android 2.1 when it launched in January 2010, bringing a souped-up UI with cool 3D-style graphics. From there, the rollout of Android 2.1 has been relatively slow and painful. Manufacturers skipped Android 2.0 in favor of the latest version but needed time to tweak their customizations, such as Motorola's Motoblur.

HTC's Desire and Legend phones launched with Android 2.1 later in the year, touting a new and improved Sense user interface.

Android 1.6 - Donut

Donut, released in September 2009, built on the features that came with Android 1.5, and expanded them. While not very rich in the eye-candy department, Android 1.6 made some major improvements behind the scenes, and provided the framework base for the amazing features to come. To the end user, the two biggest changes would have to be the improvements to the Android Market, and universal search.

Behind the screen, Donut brought support for higher resolution touchscreens, much improved camera and gallery support, and perhaps most importantly, native support for Sprint and Verizon phones. Without the technology in Android 1.6, there would be no Motorola Droid X or HTC Evo 4G.

The devices released with Android 1.6 cover a wide range of taste and features, including the Motorola Devour, the Garminphone, and the Sony Ericsson Xperia X10.

Android 1.5 - Cupcake

We expect big changes under the hood as well, and a plethora of new API changes in addition to forward-

facing features like a new interface. Google has plans to update their own Nexus 5, Nexus 4 and Nexus 7

to Android L, and other companies like Motorola have affirmed their intentions to do the same.

Android Operating System

Android 4.4 - KitKat

Google announced that the next version of Android would

be named for their favorite confectioneries — Kit Kat bars — on September 3, 2013. We're not yet sure

what manner of goodies we'll find in the next version of Android, because Google has been

understandably cryptic with details.

Their US partner in the deal, Hershy, hasn't been so quiet. They promise an update that really does taste

as good as it looks, and offers adjustable orientation that works perfectly in portrait or landscape. If you

enjoy a little tongue-in-cheek humor, have a look here and speculate with everyone else.

Android 4.1-4.3 - Jelly Bean

Jelly Bean arrived at Google IO 2012, with the release of the

ASUS Nexus 7, followed by a quick update for unlocked Galaxy Nexus phones. Later in the year, the

release of the Nexus 10 and Nexus 4 updated things from 4.1 to 4.2 and on to 4.3, but the version

remained Jelly Bean. The release polished the UI design started in Ice Cream Sandwich, and brought

several great new features to the table.

Besides the new focus on responsiveness with Project Butter, Jelly Bean brings multi-user accounts,

actionable notifications, lock screen widgets, quick-settings in the notification bar, Photosphere to the

"stock" Android camera and Google Now.

Android Operating System

Jelly Bean is hailed by many as the turning point for Android, where all the great services and

customization options finally meet great design guidelines. It's certainly very visually pleasing, and we'd

argue that it's become one of the nicest looking mobile operating systems available.

Android 4.0 - Ice Cream Sandwich

The follow-up to Honeycomb

was announced at Google IO in May 2011 and released in December 2011. Dubbed Ice Cream Sandwich

and finally designated Android 4.0, Ice Cream Sandwich brings many of the design elements of

Honeycomb to smartphones, while refining the Honeycomb experience.

The first device to launch with ICS was the Samsung Galaxy Nexus. The Motorola Xoom and the ASUS

Transformer Prime were the first tablets to receive updates, while the Samsung Nexus S was the first

smartphone to make the jump to Android 4.0.

Android 3.X - Honeycomb

Android 3.0 came out in February 2011 with the Motorola Xoom. It's

the first version of Android specifically made for tablets, and brings

a lot of new UI elements to the table. Things like a new System bar

at the bottom of the screen to replace the Status bar we see on

phones, and a new recent applications button are a great addition

for the screen real estate offered by Android tablets.

Android Operating System

Some of the standard Google applications have also been updated for use with Honeycomb, including the

Gmail app and the Talk app. Both make great use of fragments, and the Talk app has video chat and

calling support built in. Under the hood, 3D rendering and hardware acceleration have been greatly

improved.

We can't talk about Honeycomb without mentioning that it also shows Google's new distribution method,

where manufacturers are given the source code and license to use it only after their hardware choices

have been approved by Google. This dampens third party development, as the source code is no longer

available for all to download and build, but Google assures us they will address this issue in the future.

Improvements to Honeycomb were announced at Google IO in May 2011 as Android 3.1, and Android 3.2

has followed.

Android 2.3 - Gingerbread

Android 2.3 came out of the oven in December 2010, and like Eclair, has a

new "Google phone" to go along with -- the Nexus S. Gingerbread brings a

few UI enhancements to Android, things like a more consistent feel across

menus and dialogs, and a new black notification bar, but still looks and feels

like the Android we're used to, with the addition of a slew of new language

support.

Gingerbread brings support for new technology as well. NFC (Near Field

Communication) is now supported, and SIP (Internet calling) support is now

native on Android. Further optimizations for better battery life round out a

nice upgrade.

Behind the scenes, the fellows at Mountain View spent time with more JIT (the Just-In-Time compiler)

optimizations, and made great improvements to Androids garbage collection, which should stop any

stuttering and improve UI smoothness. Round that out with new a multi-media framework for better

support of sound and video files.

Versions of Android older than 2.3, while still used on a small number of devices, are considered "legacy"

versions and are generally unsupported by Google, manufacturers and app developers.

Android 2.2 - Froyo

Android 2.2 was announced in May 2010 at the Google

IO conference in San Francisco. The single largest change was the

Android Operating System

introduction of the Just-In-Time Compiler -- or JIT -- which significantly speeds up the phone's processing

power.

Along with the JIT, Android 2.2 also brings support for Adobe Flash 10.1. That means you can play your

favorite Flash-based games in Android's web browser. Take that, iPhone!

Froyo also brought native support for tethering, meaning you could use your Android smartphone's data

connection to provide Internet (wirelessly or with a USB cable) to just about any device you want. Sadly,

most carriers will strip this native support in exchange for some sort of feature they can charge for. (Can't

really blame them, can you?)

Android 2.0/2.01/2.1 - Eclair

Eclair was a pretty major step up over its predecessors.

Introduced in late 2009, Android 2.0 first appeared on the

Motorola Droid, bringing improvements in the browser, Google

Maps, and a new user interface. Google Maps Navigation also

was born in Android 2.0, quickly bringing the platform on par

with other stand-along GPS navigation systems.

Android 2.0 quickly gave way to 2.0.1, which the Droid

received in December 2009, mainly bringing bugfixes. And to date, the Droid remains the phone phone to

have explicitly received Android 2.0.1.

The now-defunct Google Nexus One was the first device to receive Android 2.1 when it launched in

January 2010, bringing a souped-up UI with cool 3D-style graphics. From there, the rollout of Android 2.1

has been relatively slow and painful. Manufacturers skipped Android 2.0 in favor of the latest version but

needed time to tweak their customizations, such as Motorola's Motoblur.

HTC's Desire and Legend phones launched with Android 2.1 later in the year, touting a new and

improved Sense user interface.

Android 1.6 - Donut

Donut, released in September 2009, built on the features that came

with Android 1.5, and expanded them. While not very rich in the eye-

candy department, Android 1.6 made some major improvements behind

the scenes, and provided the framework base for the amazing features

Android Operating System

to come. To the end user, the two biggest changes would have to be the improvements to the Android

Market, and universal search.

Behind the screen, Donut brought support for higher resolution touchscreens, much improved camera

and gallery support, and perhaps most importantly, native support for Sprint and Verizon phones. Without

the technology in Android 1.6, there would be no Motorola Droid X or HTC Evo 4G.

The devices released with Android 1.6 cover a wide range of taste and features, including the Motorola

Devour, the Garmin phone, and the Sony Ericsson Xperia X10.

Android 1.5 - Cupcake

Cupcake was the first major overhaul of the Android OS. The Android

1.5 SDK was released in April 2009 and brought along plenty of UI

changes, the biggest probably being support for widgets and folders on

the homescreens.

There were plenty of changes behind the scenes, too. Cupcake

brought features like improved Bluetooth support, camcorder functions,

and new upload services like YouTube and Picasa.

Android 1.5 ushered in the era of the modern Android phone, and the

explosion of devices included favorites like the HTC Hero/Eris, the

Samsung Moment, and the Motorola Cliq.

Android Operating System

How android Operating system works:

Design Architecture diagram Android consists of a kernel based on the Linux kernel, with middleware, libraries and APIs written in C and application software running on an application framework which includes Java-compatible libraries based on Apache Harmony. Android uses the Dalvik virtual machine with just-in-time compilation to run Dalvik dex-code (Dalvik Executable), which is usually translated from Java bytecode. Linux Android's kernel is based on the Linux kernel and has further architecture changes by Google outside the typical Linux kernel development cycle. Android does not have a native X Window System nor does it support the full set of standard GNU libraries, and this

Android Operating System

makes it difficult to port existing Linux applications or libraries to Android. Certain features that Google contributed back to the Linux kernel, notably a power management feature called wakelocks, were rejected by mainline kernel developers, partly because kernel maintainers felt that Google did not show any intent to maintain their own code. Even though Google announced in April 2010 that they would hire two employees to work with the Linux kernel community, Greg Kroah-Hartman, the current Linux kernel maintainer for the -stable branch, said in December 2010 that he was concerned that Google was no longer trying to get their code changes included in mainstream Linux. Some Google Android developers hinted that "the Android team was getting fed up with the process", because they were a small team and had more urgent work to do on Android. However, in September 2010 Linux kernel developer Rafael J. Wysocki added a patch that improved the mainline Linux wakeup events framework. He said that Android device drivers that use wakelocks can now be easily merged into mainline Linux, but that Android's opportunistic suspend features should not be included in the mainline kernel. In 2011 Linus Torvalds said that "eventually Android and Linux would come back to a common kernel, but it will probably not be for four to five years.". In December 2011 Greg Kroah-Hartman announced the start of the Android Mainlining Project, which aims to put some Android drivers, patches and features back into the Linux kernel, starting in Linux 3.3.

MANAGING THE ACTIVITY LIFECYCLE As a user navigates through, out of, and back to your app, the Activity instances in your app transition between different states in their lifecycle. For instance, when your activity starts for the first time, it comes to the foreground of the system and receives user focus. During this process, the Android system calls a series of lifecycle methods on the activity in which you set up the user interface and other components. If the user performs an action that starts another activity or switches to another app, the system calls another set of lifecycle methods on your activity as it moves into the background (where the activity is no longer visible, but the instance and its state remains intact).

Within the lifecycle callback methods, you can declare how your activity behaves when the user leaves and re-enters the activity. For example, if you're building a streaming video player, you might pause the video and terminate the network connection when the user switches to another app. When the user returns, you can reconnect to the network and allow the user to resume the video from the same spot.

Android Operating System

This class explains important lifecycle callback methods that each Activity instance receives and how you can use them so your activity does what the user expects and does not consume system resources when your activity doesn't need them.

Starting an Activity

Learn the basics about the activity lifecycle, how the user can launch your app, and how to perform basic activity creation.

Pausing and Resuming an Activity

Learn what happens when your activity is paused (partially obscured) and resumed and what you should do during these state changes.

Stopping and Restarting an Activity

Learn what happens when the user completely leaves your activity and returns to it.

Recreating an Activity

Learn what happens when your activity is destroyed and how you can rebuild the activity state when necessary.

Starting an Activity Unlike other programming paradigms in which apps are launched with a main() method, the Android system initiates code in an Activity instance by invoking specific callback methods that correspond to specific stages of its lifecycle. There is a sequence of callback methods that start up an activity and a sequence of callback methods that tear down an activity.

This lesson provides an overview of the most important lifecycle methods and shows you how to handle the first lifecycle callback that creates a new instance of your activity.

Understand the Lifecycle Callbacks

During the life of an activity, the system calls a core set of lifecycle methods in a sequence similar to a step pyramid. That is, each stage of the activity lifecycle is a separate step on the pyramid. As the system creates a new activity instance, each callback method moves the activity state one step toward the top. The top of the

Android Operating System

pyramid is the point at which the activity is running in the foreground and the user can interact with it.

As the user begins to leave the activity, the system calls other methods that move the activity state back down the pyramid in order to dismantle the activity. In some cases, the activity will move only part way down the pyramid and wait (such as when the user switches to another app), from which point the activity can move back to the top (if the user returns to the activity) and resume where the user left off.

Figure 1. A simplified illustration of the Activity lifecycle, expressed as a step pyramid. This shows how, for every callback used to take the activity a step toward the Resumed state at the top, there's a callback method that takes the activity a step down. The activity can also return to the resumed state from the Paused and Stopped state.

Depending on the complexity of your activity, you probably don't need to implement all the lifecycle methods. However, it's important that you understand each one and implement those that ensure your app behaves the way users expect. Implementing your activity lifecycle methods properly ensures your app behaves well in several ways, including that it:

• Does not crash if the user receives a phone call or switches to another app while using your app.

• Does not consume valuable system resources when the user is not actively using it.

• Does not lose the user's progress if they leave your app and return to it at a later time.

• Does not crash or lose the user's progress when the screen rotates between landscape and portrait orientation.

Android Operating System

As you'll learn in the following lessons, there are several situations in which an activity transitions between different states that are illustrated in figure 1. However, only three of these states can be static. That is, the activity can exist in one of only three states for an extended period of time:

Resumed

In this state, the activity is in the foreground and the user can interact with it. (Also sometimes referred to as the "running" state.)

Paused

In this state, the activity is partially obscured by another activity—the other activity that's in the foreground is semi-transparent or doesn't cover the entire screen. The paused activity does not receive user input and cannot execute any code.

Stopped

In this state, the activity is completely hidden and not visible to the user; it is considered to be in the background. While stopped, the activity instance and all its state information such as member variables is retained, but it cannot execute any code.

The other states (Created and Started) are transient and the system quickly moves from them to the next state by calling the next lifecycle callback method. That is, after the system calls onCreate(), it quickly calls onStart(), which is quickly followed by onResume().

That's it for the basic activity lifecycle. Now you'll start learning about some of the specific lifecycle behaviors.

Specify Your App's Launcher Activity

When the user selects your app icon from the Home screen, the system calls the onCreate() method for the Activity in your app that you've declared to be the "launcher" (or "main") activity. This is the activity that serves as the main entry point to your app's user interface.

You can define which activity to use as the main activity in the Android manifest file, AndroidManifest.xml, which is at the root of your project directory.

The main activity for your app must be declared in the manifest with an <intent-filter> that includes the MAIN action and LAUNCHER category. For example:

<activity android:name=".MainActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" />

Android Operating System

</intent-filter> </activity>

Note: When you create a new Android project with the Android SDK tools, the default project files include an Activity class that's declared in the manifest with this filter.

If either the MAIN action or LAUNCHER category are not declared for one of your activities, then your app icon will not appear in the Home screen's list of apps.

Create a New Instance

Most apps include several different activities that allow the user to perform different actions. Whether an activity is the main activity that's created when the user clicks your app icon or a different activity that your app starts in response to a user action, the system creates every new instance of Activity by calling its onCreate() method.

You must implement the onCreate() method to perform basic application startup logic that should happen only once for the entire life of the activity. For example, your implementation of onCreate() should define the user interface and possibly instantiate some class-scope variables.

For example, the following example of the onCreate() method shows some code that performs some fundamental setup for the activity, such as declaring the user interface (defined in an XML layout file), defining member variables, and configuring some of the UI.

TextView mTextView; // Member variable for text view in the layout @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Set the user interface layout for this Activity // The layout file is defined in the project res/layout/main_activity.xml file setContentView(R.layout.main_activity); // Initialize member TextView so we can manipulate it later mTextView = (TextView) findViewById(R.id.text_message); // Make sure we're running on Honeycomb or higher to use ActionBar APIs if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { // For the main activity, make sure the app icon in the action bar // does not behave as a button ActionBar actionBar = getActionBar(); actionBar.setHomeButtonEnabled(false); } }

Android Operating System

Caution: Using the SDK_INT to prevent older system's from executing new APIs works in this way on Android 2.0 (API level 5) and higher only. Older versions will encounter a runtime exception.

Once the onCreate() finishes execution, the system calls the onStart() and onResume() methods in quick succession. Your activity never resides in the Created or Started states. Technically, the activity becomes visible to the user when onStart() is called, but onResume() quickly follows and the activity remains in the Resumed state until something occurs to change that, such as when a phone call is received, the user navigates to another activity, or the device screen turns off.

In the other lessons that follow, you'll see how the other start up methods, onStart() and onResume(), are useful during your activity's lifecycle when used to resume the activity from the Paused or Stopped states.

Note: The onCreate() method includes a parameter called savedInstanceState that's discussed in the latter lesson about Recreating an Activity.

Figure 2. Another illustration of the activity lifecycle structure with an emphasis on the three main callbacks that the system calls in sequence when creating a new instance of the activity: onCreate(), onStart(), and onResume(). Once this sequence of callbacks complete, the activity reaches the Resumed state where users can interact with the activity until they switch to a different activity.

Destroy the Activity

Android Operating System

While the activity's first lifecycle callback is onCreate(), its very last callback is onDestroy(). The system calls this method on your activity as the final signal that your activity instance is being completely removed from the system memory.

Most apps don't need to implement this method because local class references are destroyed with the activity and your activity should perform most cleanup during onPause() and onStop(). However, if your activity includes background threads that you created during onCreate() or other long-running resources that could potentially leak memory if not properly closed, you should kill them during onDestroy().

@Override public void onDestroy() { super.onDestroy(); // Always call the superclass // Stop method tracing that the activity started during onCreate() android.os.Debug.stopMethodTracing(); }

Note: The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one: when you call finish() from within the onCreate() method. In some cases, such as when your activity operates as a temporary decision maker to launch another activity, you might call finish() from within onCreate() to destroy the activity. In this case, the system immediately calls onDestroy() without calling any of the other lifecycle methods.

Pausing and Resuming an Activity During normal app use, the foreground activity is sometimes obstructed by other visual components that cause the activity to pause. For example, when a semi-transparent activity opens (such as one in the style of a dialog), the previous activity pauses. As long as the activity is still partially visible but currently not the activity in focus, it remains paused.

However, once the activity is fully-obstructed and not visible, it stops (which is discussed in the next lesson).

As your activity enters the paused state, the system calls the onPause() method on your Activity, which allows you to stop ongoing actions that should not continue while paused (such as a video) or persist any information that should be permanently saved in case the user continues to leave your app. If the user returns to your activity from the paused state, the system resumes it and calls the onResume() method.

Note: When your activity receives a call to onPause(), it may be an indication that the activity will be paused for a moment and the user may return focus to your activity. However, it's usually the first indication that the user is leaving your activity.

Android Operating System

Figure 1. When a semi-transparent activity obscures your activity, the system calls onPause() and the activity waits in the Paused state (1). If the user returns to the activity while it's still paused, the system calls onResume() (2).

Pause Your Activity

When the system calls onPause() for your activity, it technically means your activity is still partially visible, but most often is an indication that the user is leaving the activity and it will soon enter the Stopped state. You should usually use the onPause() callback to:

• Stop animations or other ongoing actions that could consume CPU. • Commit unsaved changes, but only if users expect such changes to be

permanently saved when they leave (such as a draft email). • Release system resources, such as broadcast receivers, handles to sensors (like

GPS), or any resources that may affect battery life while your activity is paused and the user does not need them.

For example, if your application uses the Camera, the onPause() method is a good place to release it.

@Override public void onPause() { super.onPause(); // Always call the superclass method first // Release the Camera because we don't need it when paused // and other activities might need to use it. if (mCamera != null) { mCamera.release() mCamera = null;

Android Operating System

} }

Generally, you should not use onPause() to store user changes (such as personal information entered into a form) to permanent storage. The only time you should persist user changes to permanent storage within onPause() is when you're certain users expect the changes to be auto-saved (such as when drafting an email). However, you should avoid performing CPU-intensive work during onPause(), such as writing to a database, because it can slow the visible transition to the next activity (you should instead perform heavy-load shutdown operations during onStop()).

You should keep the amount of operations done in the onPause() method relatively simple in order to allow for a speedy transition to the user's next destination if your activity is actually being stopped.

Note: When your activity is paused, the Activity instance is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state.

Resume Your Activity

When the user resumes your activity from the Paused state, the system calls the onResume() method.

Be aware that the system calls this method every time your activity comes into the foreground, including when it's created for the first time. As such, you should implement onResume() to initialize components that you release during onPause() and perform any other initializations that must occur each time the activity enters the Resumed state (such as begin animations and initialize components only used while the activity has user focus).

The following example of onResume() is the counterpart to the onPause() example above, so it initializes the camera that's released when the activity pauses.

@Override public void onResume() { super.onResume(); // Always call the superclass method first // Get the Camera instance as the activity achieves full user focus if (mCamera == null) { initializeCamera(); // Local method to handle camera init } }

Android Operating System

Stopping and Restarting an Activity Properly stopping and restarting your activity is an important process in the activity lifecycle that ensures your users perceive that your app is always alive and doesn't lose their progress. There are a few of key scenarios in which your activity is stopped and restarted:

• The user opens the Recent Apps window and switches from your app to another app. The activity in your app that's currently in the foreground is stopped. If the user returns to your app from the Home screen launcher icon or the Recent Apps window, the activity restarts.

• The user performs an action in your app that starts a new activity. The current activity is stopped when the second activity is created. If the user then presses the Back button, the first activity is restarted.

• The user receives a phone call while using your app on his or her phone.

The Activity class provides two lifecycle methods, onStop() and onRestart(), which allow you to specifically handle how your activity handles being stopped and restarted. Unlike the paused state, which identifies a partial UI obstruction, the stopped state guarantees that the UI is no longer visible and the user's focus is in a separate activity (or an entirely separate app).

Note: Because the system retains your Activity instance in system memory when it is stopped, it's possible that you don't need to implement the onStop() and onRestart() (or even onStart() methods at all. For most activities that are relatively simple, the activity will stop and restart just fine and you might only need to use onPause() to pause ongoing actions and disconnect from system resources.

Android Operating System

Figure 1. When the user leaves your activity, the system calls onStop() to stop the activity (1). If the user returns while the activity is stopped, the system calls onRestart() (2), quickly followed by onStart() (3) and onResume() (4). Notice that no matter what scenario causes the activity to stop, the system always calls onPause() before calling onStop().

Stop Your Activity

When your activity receives a call to the onStop() method, it's no longer visible and should release almost all resources that aren't needed while the user is not using it. Once your activity is stopped, the system might destroy the instance if it needs to recover system memory. In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback, so it's important you use onStop() to release resources that might leak memory.

Although the onPause() method is called before onStop(), you should use onStop() to perform larger, more CPU intensive shut-down operations, such as writing information to a database.

For example, here's an implementation of onStop() that saves the contents of a draft note to persistent storage:

@Override protected void onStop() { super.onStop(); // Always call the superclass method first // Save the note's current draft, because the activity is stopping // and we want to be sure the current note progress isn't lost. ContentValues values = new ContentValues(); values.put(NotePad.Notes.COLUMN_NAME_NOTE, getCurrentNoteText()); values.put(NotePad.Notes.COLUMN_NAME_TITLE, getCurrentNoteTitle()); getContentResolver().update( mUri, // The URI for the note to update. values, // The map of column names and new values to apply to them. null, // No SELECT criteria are used. null // No WHERE columns are used. ); } When your activity is stopped, the Activity object is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state. The system also keeps track of the current state for each View in the layout, so if the user entered text into an EditText widget, that content is retained so you don't need to save and restore it.

Note: Even if the system destroys your activity while it's stopped, it still retains the state of the View objects (such as text in an EditText) in a Bundle (a blob of key-value pairs) and restores

Android Operating System

them if the user navigates back to the same instance of the activity (the next lesson talks more about using a Bundle to save other state data in case your activity is destroyed and recreated).

Start/Restart Your Activity

When your activity comes back to the foreground from the stopped state, it receives a call to onRestart(). The system also calls the onStart() method, which happens every time your activity becomes visible (whether being restarted or created for the first time). The onRestart() method, however, is called only when the activity resumes from the stopped state, so you can use it to perform special restoration work that might be necessary only if the activity was previously stopped, but not destroyed.

It's uncommon that an app needs to use onRestart() to restore the activity's state, so there aren't any guidelines for this method that apply to the general population of apps. However, because your onStop() method should essentially clean up all your activity's resources, you'll need to re-instantiate them when the activity restarts. Yet, you also need to instantiate them when your activity is created for the first time (when there's no existing instance of the activity). For this reason, you should usually use the onStart() callback method as the counterpart to the onStop() method, because the system calls onStart() both when it creates your activity and when it restarts the activity from the stopped state.

For example, because the user might have been away from your app for a long time before coming back it, the onStart() method is a good place to verify that required system features are enabled:

@Override protected void onStart() { super.onStart(); // Always call the superclass method first // The activity is either being restarted or started for the first time // so this is where we should make sure that GPS is enabled LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); boolean gpsEnabled = locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER); if (!gpsEnabled) { // Create a dialog here that requests the user to enable GPS, and use an intent // with the android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS action // to take the user to the Settings screen to enable GPS when they click "OK" } } @Override protected void onRestart() { super.onRestart(); // Always call the superclass method first

Android Operating System

// Activity being restarted from stopped state } When the system destroys your activity, it calls the onDestroy() method for your Activity. Because you should generally have released most of your resources with onStop(), by the time you receive a call to onDestroy(), there's not much that most apps need to do. This method is your last chance to clean out resources that could lead to a memory leak, so you should be sure that additional threads are destroyed and other long-running actions like method tracing are also stopped.

Recreating an Activity There are a few scenarios in which your activity is destroyed due to normal app behavior, such as when the user presses the Back button or your activity signals its own destruction by calling finish(). The system may also destroy your activity if it's currently stopped and hasn't been used in a long time or the foreground activity requires more resources so the system must shut down background processes to recover memory.

When your activity is destroyed because the user presses Back or the activity finishes itself, the system's concept of that Activity instance is gone forever because the behavior indicates the activity is no longer needed. However, if the system destroys the activity due to system constraints (rather than normal app behavior), then although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the "instance state" and is a collection of key-value pairs stored in a Bundle object.

Caution: Your activity will be destroyed and recreated each time the user rotates the screen. When the screen changes orientation, the system destroys and recreates the foreground activity because the screen configuration has changed and your activity might need to load alternative resources (such as the layout).

By default, the system uses the Bundle instance state to save information about each View object in your activity layout (such as the text value entered into an EditText object). So, if your activity instance is destroyed and recreated, the state of the layout is restored to its previous state with no code required by you. However, your activity might have more state information that you'd like to restore, such as member variables that track the user's progress in the activity.

Note: In order for the Android system to restore the state of the views in your activity, each view must have a unique ID, supplied by the android:id attribute.

Android Operating System

To save additional data about the activity state, you must override the onSaveInstanceState() callback method. The system calls this method when the user is leaving your activity and passes it the Bundle object that will be saved in the event that your activity is destroyed unexpectedly. If the system must recreate the activity instance later, it passes the same Bundle object to both the onRestoreInstanceState() and onCreate() methods.

Figure 2. As the system begins to stop your activity, it calls onSaveInstanceState() (1) so you can specify additional state data you'd like to save in case the Activity instance must be recreated. If the activity is destroyed and the same instance must be recreated, the system passes the state data defined at (1) to both the onCreate() method (2) and the onRestoreInstanceState() method (3).

Save Your Activity State

As your activity begins to stop, the system calls onSaveInstanceState() so your activity can save state information with a collection of key-value pairs. The default implementation of this method saves information about the state of the activity's view hierarchy, such as the text in an EditText widget or the scroll position of a ListView.

To save additional state information for your activity, you must implement onSaveInstanceState() and add key-value pairs to the Bundle object. For example:

static final String STATE_SCORE = "playerScore"; static final String STATE_LEVEL = "playerLevel"; ... @Override public void onSaveInstanceState(Bundle savedInstanceState) { // Save the user's current game state savedInstanceState.putInt(STATE_SCORE, mCurrentScore); savedInstanceState.putInt(STATE_LEVEL, mCurrentLevel); // Always call the superclass so it can save the view hierarchy state super.onSaveInstanceState(savedInstanceState);

Android Operating System

}

Caution: Always call the superclass implementation of onSaveInstanceState() so the default implementation can save the state of the view hierarchy.

Restore Your Activity State

When your activity is recreated after it was previously destroyed, you can recover your saved state from the Bundle that the system passes your activity. Both the onCreate() and onRestoreInstanceState() callback methods receive the same Bundle that contains the instance state information.

Because the onCreate() method is called whether the system is creating a new instance of your activity or recreating a previous one, you must check whether the state Bundle is null before you attempt to read it. If it is null, then the system is creating a new instance of the activity, instead of restoring a previous one that was destroyed.

For example, here's how you can restore some state data in onCreate():

@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Always call the superclass first // Check whether we're recreating a previously destroyed instance if (savedInstanceState != null) { // Restore value of members from saved state mCurrentScore = savedInstanceState.getInt(STATE_SCORE); mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL); } else { // Probably initialize members with default values for a new instance } ... } Instead of restoring the state during onCreate() you may choose to implement onRestoreInstanceState(), which the system calls after the onStart() method. The system calls onRestoreInstanceState() only if there is a saved state to restore, so you do not need to check whether the Bundle is null:

public void onRestoreInstanceState(Bundle savedInstanceState) { // Always call the superclass so it can restore the view hierarchy super.onRestoreInstanceState(savedInstanceState); // Restore state members from saved instance mCurrentScore = savedInstanceState.getInt(STATE_SCORE); mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL); }

Caution: Always call the superclass implementation of onRestoreInstanceState() so the default implementation can restore the state of the view hierarchy.

Android Operating System

To learn more about recreating your activity due to a restart event at runtime (such as when the screen rotates), read Handling Runtime Changes.

Vulnerabilities in Android?

1. Here is a vulnerability in Android versions below 5.0 that could allow an attacker to bypass ASLR and run arbitrary code on a target device under certain circumstances. The bug was fixed in Lollipop, the newest version of the mobile OS, released earlier this week. The vulnerability lies in java.io.ObjectInputStream, which fails to check whether an object that is being deserialized is actually a serialized object. Security researcher Jann Horn discovered the vulnerability and reported it to Google earlier this year.

“This means that when ObjectInputStream is used on untrusted inputs, an attacker can cause an instance of any class with a non-private parameterless constructor to be created. All fields of that instance can be set to arbitrary values. The malicious object will then typically either be ignored or cast to a

Android Operating System

type to which it doesn’t fit, implying that no methods will be called on it and no data from it will be used. However, when it is collected by the GC, the GC will call the object’s finalize method,” the security advisory from Horn says. “The class android.os.BinderProxy contains a finalize method that calls into native code. This native code will then use the values of two fields of type int/long (depends on the Android version), cast them to pointers and follow them. On Android 4.4.3, this is where one of those pointers ends up. r0 contains the attacker-supplied pointer, and if the attacker can insert data into the process at a known address, he ends up gaining arbitrary code execution in system_server.” Horn said via email that the exploitability of the vulnerability is difficult to judge.

“An attacker would need to get a malicious app onto the device in order for this to work.”

“An attacker would need to get a malicious app onto the device in order for this to work. The app would need no permissions,” he said. “However, I don’t have a full exploit for this issue, just the crash PoC, and I’m not entirely sure about how predictable the address layout of the system_server really is or how easy it is to write a large amount of data into system_server’s heap (in order to make less accurate guesses for the memory position work). It might be necessary to crash system_server once in order to make its memory layout more predictable for a short amount of time, in which case the user would be able to notice the attack, but I don’t think that’s likely.” Android vulnerabilities can be especially problematic for users because of the way that the update cycle works. Carriers are responsible for providing updates to users but many of them are very slow to do so and users often will got through several years without a single security update to their device.

2.

Researchers from Indiana University and Microsoft published a paper that describes a new class of Android vulnerabilities called Pileup flaws. Pileup, which is short for privilege escalation through updating, increases the permissions offered to malicious apps once Android is updated, without informing the user.

"Every few months, an update is released, which causes replacement and addition of tens of thousands of files on a live system. Each of the new apps being installed needs to be carefully configured to set its attributes within its own

Android Operating System

sandboxes and its privileges in the system, without accidentally damaging existing apps and the user data they keep," the researchers wrote. "This complicates the program logic for installing such mobile updates, making it susceptible to security-critical flaws."

"Through the app running on a lower version of Android, the adversary can strategically claim a set of carefully selected privileges or attributes only available on the higher OS version," the researchers wrote.

The problem, to put it simply, is that for the sake of convienience the Android user interface doesn't pop up any prompts pointing out the new permissions, but instead assigns them automatically in the background without giving the user any say in the matter.

The researchers claim to have discovered six different Pileup vulnerabilities within the Android Package Management Service (PMS), and have confirmed that these vulnerabilities are present in all Android Open Source Project versions, along with more than 3,500 customized versions of Android developed by handset OEMs and carriers. In total, the researchers claim that this leaves more than a billion Android devices vulnerable to a Pileup attack.

"A third-party package attribute or property, which bears the name of its system counterpart, can be elevated to a system one during the updating shuffle-up where all apps are installed or reinstalled, and all system configurations are reset," the researcher wrote. "Also, when two apps from old and new systems are merged as described above, security risks can also be brought in when the one on the original system turns out to be malicious."

The researchers have also introduces a new scanner called SecUP that detects malicious apps already on a device lying in wait for elevated privileges. The scanner verifies the source code of PMS (from different Android versions) to identify any violation of a set of security constraints."

All of the issues have been reported to Google, and the company has already patched one of the six vulnerabilities.

3.

The Heart-bleed Bug

Android Operating System

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL

cryptographic software library. This weakness allows stealing the

information protected, under normal conditions, by the SSL/TLS

encryption used to secure the Internet. SSL/TLS provides

communication security and privacy over the Internet for

applications such as web, email, instant messaging (IM) and some

virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the

memory of the systems protected by the vulnerable versions of the

OpenSSL software. This compromises the secret keys used to identify

the service providers and to encrypt the traffic, the names and

passwords of the users and the actual content. This allows attackers

Android Operating System

to eavesdrop on communications, steal data directly from the

services and users and to impersonate services and users.

Bugs in single software or library come and go and are fixed by new versions. However this bug has left large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitation and attacks leaving no trace this exposure should be taken seriously. Encryption is used to protect secrets that may harm your privacy or security if they leak. In order to coordinate recovery from this bug we have classified the compromised secrets to four categories: 1) primary key material, 2) secondary key material and 3) protected content and 4) collateral. These are the crown jewels, the encryption keys themselves. Leaked secret keys allow the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed.

What versions of the OpenSSL are affected?

Status of different versions:

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable

• OpenSSL 1.0.1g is NOT vulnerable

• OpenSSL 1.0.0 branch is NOT vulnerable

• OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been

out in the wild since OpenSSL release 1.0.1 on 14th of March 2012.

OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

Android Operating System

4. You expect your apps and personal data to still be in your Android after an operating system upgrade, but the updating mechanism that allows that has a new class of privilege escalation vulnerabilities, which security researchers warn “pose serious threats to billions of Android users” who update their systems. Basically flaws in Android's program logic to install updates could allow a bad app to gain godlike permission to take control of your Android device, from hijacking your Google account, sending text messages, accessing voicemail, formatting removable storage, to stealing your passwords for a banking site. When talking about the flaws that affect “all the Android devices worldwide,” the researchers used words like dangerous, dire and devastating.

While OS upgrades often close security holes, a team of researchers from Indiana University and Microsoft Research explained that vulnerabilities in the Android Package Management Service (PMS) will allow a “seemingly harmless malicious app” to “automatically acquire significant capabilities without users’ consent once they upgrade” to a newer version of Android." They call the vulnerabilities Pileup flaws, for privilege escalation through updating, and identified six such flaws in Android OS code. This is the first time anyone has “systematically studied the security hazards introduced by the vulnerable program logic for installing” Android updates or patches. They will present their research, “Upgrading Your Android, Elevating My Malware: Privilege Escalation through Mobile

Android Operating System

OS Updating” at the IEEE Security and Privacy symposium in May.

“A distinctive feature of the threat is that the attack is not aimed at a vulnerability in the current system,” wrote the researchers. “Instead, it exploits the flaws in the updating mechanism of the ‘future’ OS, which the current system will be upgraded to.” Successfully exploiting these logic flaws when you upgrade to a newer OS could have “devastating consequences.”

Their research “confirmed the presence of the issues in all AOSP (Android Open Source Project) versions and 3,522 source code versions customized by Samsung, LG and HTC across the world.” They “further conducted a measurement study over 3,549 factory images from Google and Samsung, and discovered tens of thousands of attack opportunities across different Android versions, countries, carriers and vendors, each of which enables a knowledgeable adversary to acquire system capabilities automatically during an upgrade.”

What kind of attacks? The researchers wrote

As examples, on various versions of Android, an upgrade allows the unprivileged malware to get the permissions for accessing voicemails, user credentials, call logs, notifications of other apps, sending SMS, starting any activity regardless of permission protection or export state, etc.; the malware can also gain complete control of new signature and system permissions, lowering their protection levels to “normal” and arbitrarily changing their descriptions that the

Android Operating System

user needs to read when deciding on whether to grant them to an app; it can even replace the official Google Calendar app with a malicious one to get the phone user’s events, drop JavaScript code in the data directory to be used by the new Android browser so as to steal the user’s sensitive data, or prevent her from installing critical system apps such as Google Play Services.

5. The issue, which has been assigned the CVE identifier CVE-2014-6041, was first reported by Pakistan-based security researcher Rafay Baloch in late August. Baloch found that the Android Open Source Platform (AOSP) browser installed on Android 4.2.1 is vulnerable to Same Origin Policy (SOP) bypass. He tested his findings on numerous devices, including Qmobile Noir, Sony Xperia, Samsung Galaxy S3, HTC Wildfire and Motorola Razr.

After Baloch published a blog post describing the issue, researchers from security firm Rapid7 also conducted an analysis and determined that AOSP browsers shipped with versions of the operating system prior to Android 4.4 are affected.

The SOP is a security feature that's designed to make it possible for pages from the same site to interact, while preventing unrelated websites from interfering with each other. By bypassing the SOP, an attacker can gain access to content from the websites opened by the victim. An attacker simply needs to set up a malicious website, which enables the harvest of data from the sites opened in different tabs. This can be done by "malforming a javascript: URL handler with a prepended null byte," Rapid7 said.

"Imagine you went to an attackers site while you had your webmail open in another window -- the attacker could scrape your e-mail data and see what your browser sees. Worse, he could snag a copy of your session cookie and hijack your session completely, and read and write webmail on your behalf,"

Android Operating System

Rapid7's Tod Beardsley explained in a blog post. "This is a privacy disaster. The Same-Origin Policy is the cornerstone of web privacy, and is a critical set of components for web browser security."

After the introduction of Chrome for Android, Google stopped shipping the AOSP browser with Android. However, Android versions prior to 4.4 (KitKat), which have the vulnerable application installed by default, represent 75% of the Android ecosystem.

Baloch said he had notified Google of the existence of the flaw "way before" he published his blog post. Initially, Google's security team could not reproduce the issue, but they later confirmed it and claimed to be "working internally on a suitable fix."

In the meantime, Rapid7 has developed a Metasploit module that exploits the vulnerability. Researchers have also promised to publish a video demonstrating an attack.

"Research and testing is still ongoing to plumb the depths of this issue. We'd like to pin down exactly when the bug was fixed, and to determine just how widespread this vector really is," Beardsley explained.

6. Web-View Vulnerability

Vulnerabilities found in Web-View and possibly other components included in old versions of the Android operating system.

Web View is a component that’s used to display Web pages on Android smartphones. Starting with Android 4.4 (Kit Kat), Google introduced a new Web View based on the Chromium open source project.

The problem is that researchers such as Rafay Baloch and Rapid7’s Joe Vennix have found, and they keep finding, numerous security vulnerabilities in the old Web View, which is used by the Android Open Source Platform (AOSP) browser shipped by default

Android Operating System

with pre-Kit Kat versions of the OS. The popular penetration testing tool Metasploit includes exploits for 11 such flaws.

However, it appears that Google has stopped patching any vulnerabilities affecting this older version of Web View, despite the fact that roughly 60% of devices still run Android Jelly Bean (4.1-4.3), Ice Cream Sandwich (4.0), Gingerbread (2.3), and Froyo (2.2). According to recent studies, roughly 930 million devices run a version of the OS that Google considers outdated.

Google’s security team informed researchers at Rapid7 that they no longer develop patches for Web View prior to version 4.4. Instead, those who report the vulnerabilities are welcome to submit patches “for consideration,” Google said.

If vulnerability reports are not accompanied by a patch, all Google can do is notify its partners of the bug’s existence. If a patch is made available, it will be forwarded to partners, the company told Rapid7.

Google hasn’t clarified if the same policy applies to other components included in Android versions prior to 4.4.

While the search giant hasn’t officially informed customers that the operating systems they’re using on their mobile devices have reached end-of-life (EOL), the company says it can "no longer certify 3rd party devices that include the Android Browser," and "the best way to ensure that Android devices are secure is to update them to the latest version of Android."

Rapid7’s Tod Beardsley has pointed out that this is great news for cybercriminals because many users simply can’t afford to purchase new phones to get the latest version of the operating system.

“Open source security researchers routinely publish vulnerability details and working exploits with the expectation that this kind of public discussion and disclosure can get both vendors and users to take notice of techniques employed by bad guys,” the researcher noted in a blog post. “By ‘burning’ these vulnerabilities, users come to expect that vendors will step up and provide reasonable

Android Operating System

defenses. Unfortunately, when the upstream vendor is unwilling to patch, even in the face of public disclosure, regular users remain permanently vulnerable.”

The process of patching Android vulnerabilities is complicated as it is: Google usually doesn’t inform users and developers when a flaw has been patched, and carriers and manufacturers are responsible for distributing the updates from Google to their customers.

If Google no longer develops patches for older versions of Android, it’s unlikely that smartphone manufacturers and mobile operators will distribute the patches developed by security researchers, Beardsley noted.

“I empathize with their decision to cut legacy software loose. However, a billion people don't rely on old versions of my software to manage and safeguard the most personal details of their lives. In that light, I'm hoping Google reconsiders if (when) the next privacy-busting vulnerability becomes public knowledge,” the expert said.

Steve Hultquist, chief evangelist at security analytics company Red Seal, has pointed out how such decisions can impact enterprises.

“Technology keeps moving forward on mobile devices, client computers, servers, and network infrastructure. As a result, the overall security of an organization relies on the ongoing automated analysis of the current situation and processes and procedures to address the gaps that are uncovered daily,” Hultquist told Security Week. ”As we can see with the distribution of Android releases, being aware of the distribution of systems, their existing security issues, and how they are accessible from threats are all critical aspects of the overall security operation of an enterprise.”

Android Operating System

References: 1.http://www.redmondpie.com/android-version-history-guide-v1.0-to-v4.1-jelly-bean-infographic/ 2. http://threatpost.com/nasty-security-bug-fixed-in-android-lollipop-5-0/109476#sthash.tyR5sbnu.dpuf 3. http://heartbleed.com/ 4. http://www.securityweek.com/dangerous-same-origin-policy-bypass-flaw-found-android-browser 5. http://www.computerworld.com/article/2476019/mobile-security/all-android-devices-at-risk-of-being-hacked-when-installing-os-system-updates.html