Unit II Introducing Android 5 Hrs.

SDK Overview
Android Emulator
Android Installation
setting up development environment using Eclipse/ Android Studio
DDMS
Activity Lifecycle
Manifest File
Locales, Drawable, Listeners, Supporting Multiple Screens.

Mapping of Course Outcomes for Unit II CO1: Describe the process of developing mobile applications.
 SDK Overview
Software Development Kit (SDK) is a collection of Software Development tools in one installable
package. This SDK is also used with Android which helps to download the tools, the latest versions
of Android.

The Android SDK (Software Development Kit) is a set of development tools that are used to develop
applications for the Android platform.

This SDK provides a selection of tools that are required to build Android applications and ensures
the process goes as smoothly as possible.
Whether you create an application using Java, Kotlin or C#, you need the SDK to get it to run on
any Android device.

You can also use an emulator in order to test the applications that you have built.

Note: You can download the Android SDK independently.

With the help of Android SDK, we can create android Apps easily.

About Android SDK :

Android SDK is a collection of libraries and Software Development tools that are essential for
Developing Android Applications.

Whenever Google releases a new version or update of Android Software, a corresponding SDK also
releases with it.

Android SDK consists of some tools which are very essential for the development of Android
Application.

These tools provide a smooth flow of the development process from developing and debugging.

Android SDK is compatible with all operating systems such as Windows, Linux, macOS, etc.
How to install Android SDK?

Follow these steps in order to install the Android SDK.

Step 1: Install Android Studio on your system.

Step 2: When you get the Welcome page for Android Studio, click on
the Configure and select SDK manager.

OR

If you have already created a new project, you can simply go to Tools -> SDK
Manager -> SDK Tools and install the required SDK files.
 OR
You can just click on the Download Icon on the menubar.

Different features of Android SDK

•Offline Mapping

•SDK helps in dynamically downloading the maps for more than 190 countries in over 60 languages.
You can view these offline. Also dealing with the map styles and the touch gesture. This SDK also has
the ability to render raster tiles and map objects interleaved within different map layers.
•Dynamic Markers :

n the previous versions, you could not have moved

the position without a fallback or re-adding the icon.
But in the latest edition, you can update the position
of the icon dynamically.

•Improvised API compatibility

With the latest release, it is much easier to migrate
from the Google Maps Android API. This is another
added advantage of using Android SDK in your
program.
Android SDK manager :

In order to download and install latest android APIs and development tools from the internet,
Android helps us by having the Android SDK manager.

This separates the APIs, tools and different platforms into different packages which you can
download.

Android SDK Manager comes with the Android SDK bundle. You can’t download it
separately.
Components of SDK

1. SDK Tools
Android SDK Tools is a component for the Android SDK.

This includes a complete set of development and debugging tools for Android.

SDK tools are also included with Android Studio.

Android comes up with the revised version every now and then the latest release is SDK Tools,
Revision 26.1.1 (September 2017)
SDK tools are generally platform-independent and they are required no matter which
Android platform you are currently working on.
There are a set of tools that get installed automatically when you install Android Studio.

Android SDK tool is an important component of Android SDK. It consists of a complete set of
development and debugging tools. Below are the SDK developer tools:

Android SDK Build tool.

Android Emulator.
Android SDK Platform-tools.
Android SDK Tools.
2. Android SDK Build-Tools
Android SDK build tools are used for building actual binaries of Android App.

The main functions of Android SDK Build tools are built, debug, run and test Android applications.

While downloading or updating Android in our System, one must ensure that its latest version is download in
SDK Components.

3. Android Emulator
An Android Emulator is a device that simulates an Android device on your system.

Suppose we want to run our android application that we code, One option is that we will run this on our
Android Mobile by Enabling USB Debugging on our mobile.

Another option is using Android Emulator. In Android Emulator the virtual android device is shown on our
system on which we run the Android application that we code.

Thus, it simply means that without needing any physical device Android SDK component “Android Emulator”
provides a virtual device on the System where we run our Application.
The emulator’s come with the configuration for Various android phones, tablets, Wear OS, and Android TV
devices.
In Android Virtual Emulator all functions that are feasible on real Android mobile is works on virtual Device
like:

phone calls, text messages.

stimulate different network speeds.
specify the location of a device
access on google play store and lot’s more.

One disadvantage of this emulator is that, It is very slow when System’s PC has less RAM.

It works fine when a maximum GB of RAM is present on our device

4. Android SDK Platform-tools

Android SDK Platform-tools is helpful when we are working on Project and they will show the error messages
at the same time.
It is specifically used for testing. It includes:

Android Debug Bridge (ADB), is a command-line tool that helps to communicate with the device.
It allows us to perform an action such as Installing App and Debugging App etc.

Fastboot allows you to flash a device with a new system image.

Systrace tools help to collect and inspect timing information. It is very crucial for App Debugging.

5. Android SDK Tools

Android SDK tool is a component of SDK tool.

It consists of a set of tools and other Utilities which are crucial for the development of Android Application.

It contains the complete set of Debugging and Development tools for android.
 6. SDK Platforms
For Each Android Software, one SDK platform is available as shown below:

Like in this Android 11.0(R) is installed.

These are numbered according to the android version.

The new version of the SDK platform has more features and more compatible but the old version is less
compatible with fewer features.
Like in Android 11.0(R) have more compatible and have more feature but the below versions like Android
10.0(Q), Android4.4(KitKat) have less feature and is less compatible.
7. SDK Update Sites
In SDK Update Sites, some sites are embedded in it which will check for Android SDK Updates Tools.

In this, one must ensure we don’t unclick the button below because these are checked by default which will
check for updates if we will unclick it then it doesn’t check updates for those.
Android Emulator

An Android emulator is a tool that creates virtual Android devices (with software and hardware) on your
computer. Note that:
•It is a program (a process that runs on your computer’s operating system).
•It works by mimicking the guest device’s architecture

Working of Android Emulators :

•Quick Emulator (QEMU)
It’s an open-source and incredibly versatile tool.
It can run on a large variety of host (workstation) CPUs/OSs and emulate an even larger range of guest
CPUs/OSs.
QEMU powers most Android emulators (including the one by Android Developer Studio).
It mimics guest device hardware.
Then it translates the Application Binary Interface (ABI) of the guest device to match that of the host
device.
You equip this with with an OS and run it like a program on your computer.
The translation of CPU architectures is a complex, time-consuming process which makes emulation almost
painfully slow.
It can be skipped if the guest and the host CPU architectures are the same, with the help of a hypervisor.
Hypervisors :
When the guest and the host devices have same instruction architecture (say, x86 Android system images and
x86 Intel processor), QEMU skips the ‘binary translation’ part and runs the guest device directly on the host
CPU. This is called hardware-assisted virtualization.

You need a hypervisor to enable this. Intel’s HAXM (Hardware Acceleration Execution Manager) is a
hypervisor component for Windows and macOS.
There’s KVM (Kernel-based Virtual Machine) for Linux.
x86 Android ABIs (Application Binary Interface, or system images) are now available to support hardware-
acceleration on most computers.

If your CPU supports it, the Android emulator prompts you to enable or install the hypervisor in order to speed
up virtual device performance.

With hardware-acceleration, the Android emulator can run virtual devices at speeds similar to that of
your workstation CPU
Android Emulator (by Android Developer Studio)
Post the release of version 25.3.0, the Android Emulator is distributed separately from Android SDK tools.

To install it from your Android Developer Studio console, go to Configure -> SDK Manager -> Android SDK.
Within this screen, under the ‘SDK Tools’ tab, you’ll find the Android Emulator.
Check the box and click OK to install it.

Hardware Prerequisites:
SDK version 26.1.1 or above
PC/laptop with 64 or 86-bit processor.
If you want to work with Android 8.1 or above, you’ll need a webcam that can capture 720p frames.

The emulator may prompt you to enable hardware-acceleration (to speed up virtual device performance).
For this, you’ll need HAXM version 7.2.0-the Intel hypervisor we mentioned above.

Windows and Linux users will need more components, depending on their processor family:

Intel: Intel VT-x and Intel EM64T (Intel 64) support; Execute Disable (XD) Bit capability.
AMD (Linux): AMD Virtualization (AMD-V) support; SIMD Extensions set 3.
AMD (Windows): Android Studio v3.2 or above; Windows Hypervisor Platform API.
Once you’re done with the installation, you’ll arrive at the Android Virtual Device (AVD) Manager:
•Android Virtual Device Manager – Things to Note

•AVD Manager lets you set up and configure your virtual Android devices. Some key points:
• Device Type: Contains pre-configured, manufacturer-specific device profiles for TV, Phone, Tablet, and
Wear OS. You can customize screen size and certain external capabilities–or import a profile of your
own.

Interestingly, the Google Play Store and the Compatibility Test Suite are only available for a very
limited number of devices–ones that meet the Android Compatibility Program criteria.
You cannot add this capability to a cloned or custom device profile.

• System Image: Lets you equip the virtual device with a system image/ABI and an Android OS version.
ABIs come in ARM, x86, x86-64 variants for different Android OS versions/APIs.
Each ABI has a file size of about 900 MB.

The emulator will recommend ABIs that are similar in architecture to your workstation processor, but
you can pick others (with a trade-off in emulator performance).

Only certain system images have Google APIs (which give you access to Google apps like Maps,
Gmail, etc.).
 Verify Configuration: Allows you to change previously defined hardware/software profiles and
configure some startup settings for the virtual device (name, orientation etc.)

•Once you click ‘Finish’, the emulator launches the virtual device instance with your specifications–complete
with extended controls to adjust device rotation, geolocation, camera, fingerprint sensor, network
latency, battery state, and more.

•You can test your web app, a project from Android Studio or upload a native app APK from your own
device.

•By default, these virtual device instances get saved in the state they were in when you closed them. You can
also save snapshots of the device state (includes OS, your app/project, and user data) and pick up where you
left off later.
Select Hardware
System Image
Android Virtual Device
Android Emulator: Capabilities and Limitations :

The latest Android emulator by Developer Studio can closely imitate a real Android device. But it still has its
limitations.

•Capabilities :

Data transfer is faster on a virtual device (than a physical device connected via USB).
The drag-and-drop file upload lets you place .apk files from your computer to the virtual mobile device.
It’s particularly great when developers need to quickly test apps under context.

•The emulator is also pretty useful when you’re working with physical sensors like the accelerometer.
If you were testing a specific app feature that relies on the sensors, it’ll be easier to configure the settings
through the visual, extended controls of the emulator.
•Limitations

The most popular chipset for Android smartphones out there is ARM v7a. Most PCs/laptops run on Intel (x86). Recall that
guest and host CPU architectures need to match for faster emulation.

Basically, without a computer equipped with an ARM processor, you’re stuck with poor emulation of most of the
commercially-available Android devices.

The AVD Manager creates separate directories to store each virtual device’s user data, SD card data, and cache.

A single virtual device can take as much as 3.5GB of your disk space. Over time, a library of virtual devices will clam up
your workstation.

Virtual devices’ performance is affected by that of your workstation. The emulator will crash and burn if you don’t have
enough free disk space at launch.

Enabling hardware-acceleration takes care of performance issues. But setting up hardware-acceleration is a complex
process that even experienced developers struggle with. The results often lead to complete system failure.
•Android emulator isn’t reliable when it comes to understanding app interactions with the native device
environment. For instance, you’d never know:
• Which background processes your app runs
• How front-end appears in different brightness levels
• How the app responds to a complete range of touch-gesturesS
 Features of Android Studio
Android Studio is the official IDE (Integrated Development Environment) for Android app
development and it is based on JetBrains’ IntelliJ IDEA software.

•Android Studio provides many excellent features that enhance productivity when building
Android apps, such as:

•A blended environment where one can develop for all Android devices
•Apply Changes to push code and resource changes to the running app without restarting the app
•A flexible Gradle-based build system
•A fast and feature-rich emulator
•GitHub and Code template integration to assist you to develop common app features and import
sample code
•Extensive testing tools and frameworks
•C++ and NDK support
•Built-in support for Google Cloud Platform, making it easy to integrate Google Cloud Messaging
and App Engine, and many more.
•Provides GUI tools that simplify the less interesting parts of app development.
•Easy integration with real time database ‘firebase’.
 Android Studio Installation
System Requirements :

Microsoft Windows 7/8/10 (32-bit or 64-bit)

4 GB RAM minimum, 8 GB RAM recommended (plus 1 GB for the
Android Emulator)
2 GB of available disk space minimum, 4 GB recommended (500 MB for
IDE plus 1.5 GB for Android SDK and emulator system image)
1280 x 800 minimum screen resolution

For installation refer the pdf shared for practical

DDMS : Using the Dalvik Debug Monitor :

• Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS)

• It provides :
port-forwarding services
, screen capture on the device
thread and heap information on the device
Logcat
Process
radio state information
incoming call and SMS spoofing
location data spoofing, and more.

DDMS ships in the tools/ directory of the SDK.

Enter this directory from a terminal/console and type ddms (or ./ddms on Mac/Linux) to run it.

DDMS will work with both the emulator and a connected device.

If both are connected and running simultaneously, DDMS defaults to the emulator.
Adb :Android Debug Bridge

Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator
instance or Android-powered device.

It is a client-server program that includes three components:

A client, which runs on your development machine.

You can invoke a client from a shell by issuing an adb command.
Other Android tools such as the ADT plugin and DDMS also create adb clients.
A server, which runs as a background process on your development machine.
The server manages communication between the client and the adb daemon running on an
emulator or device.
A daemon, which runs as a background process on each emulator or device instance
You can find the adb tool in <sdk>/platform-tools/.

When you start an adb client, the client first checks whether there is an adb server process already running.
If there isn't, it starts the server process.

When the server starts, it binds to local TCP port 5037 and listens for commands sent from adb clients—all adb
clients use port 5037 to communicate with the adb server

The server then sets up connections to all running emulator/device instances.

It locates emulator/device instances by scanning odd-numbered ports in the range 5555 to 5585, the range used
by emulators/devices.
Where the server finds an adb daemon, it sets up a connection to that port.
Note that each emulator/device instance acquires a pair of sequential ports — an even-numbered port for
console connections and an odd-numbered port for adb connections.
For example:
Emulator 1, console: 5554
Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557 ...
As shown, the emulator instance connected to adb on port 5555 is the same as the instance whose console
listens on port 5554.
Once the server has set up connections to all emulator instances, you can use adb commands to
control and access those instances.

Because the server manages connections to emulator/device instances and handles commands from
multiple adb clients, you can control any emulator/device instance from any client (or from a script).

ADB quickview
Manage the state of an emulator or device
Run shell commands on a device
Manage port forwarding on an emulator or device
Copy files to/from an emulator or device

http://www.dre.vanderbilt.edu/~schmidt/android/android-4.0/out/target/common/docs/doc-
comment-check/guide/developing/tools/adb.html
How DDMS works

DDMS acts as a middleman to connect the IDE to the applications running on the device.

On Android, every application runs in its own process, each of which hosts its own virtual machine (VM). And
each process listens for a debugger on a different port.

When it starts, DDMS connects to adb and starts a device monitoring service between the two, which will notify
DDMS when a device is connected or disconnected.
When a device is connected, a VM monitoring service is created between adb and DDMS, which will notify
DDMS when a VM on the device is started or terminated. Once a VM is running, DDMS retrieves the the VM's
process ID (pid), via adb, and opens a connection to the VM's debugger, through the adb daemon (adbd) on the
device. DDMS can now talk to the VM using a custom wire protocol.
For each VM on the device, DDMS opens a port upon which it will listen for a debugger. For the first VM,
DDMS listens for a debugger on port 8600, the next on 8601, and so on. When a debugger connects to one of
these ports, all traffic is forwarded between the debugger and the associated VM. Debugging can then process
like any remote debugging session.
DDMS also opens another local port, the DDMS "base port" (8700, by default), upon which it also listens for a
debugger. When a debugger connects to this base port, all traffic is forwarded to the VM currently selected in
DDMS, so this is typically where you debugger should connect
Left Pane
The left side of the Debug Monitor shows each emulator/device currently found, with a list of all the
VMs currently running within each.

VMs are identified by the package name of the application it hosts.

Use this list to find and attach to the VM running the activity(ies) that you want to debug.

Next to each VM in the list is a "debugger pass-through" port (in the right-most column).

If you connect your debugger to one of the the ports listed, you will be connected to the corresponding
VM on the device.

However, when using DDMS, you need only connect to port 8700, as DDMS forwards all traffic here
to the currently selected VM.
(Notice, as you select a VM in the list, the listed port includes 8700.)
This way, there's no need to reconfigure the debugger's port each time you switch between VMs.
When an application running on the device calls waitForDebugger() (or you select this option in the developer
options), a red icon will be shown next to the client name, while it waits for the debugger to attach to the VM.

When a debugger is connected, the icon will turn green.

If you see a crossed-out bug icon, this means that the DDMS was unable to complete a connection between the
debugger and the VM because it was unable to open the VM's local port.

If you see this for all VMs on the device, it is likely because you have another instance of DDMS running (this
includes the Eclipse plugin).

If you see a question mark in place of an application package, this means that, once DDMS received the
application pid from adb, it somehow failed to make a successful handshake with the VM process. Try restarting
DDMS.

Right pane
On the right side, the Debug Monitor provides tabs that display useful information and some pretty cool tools.
Info
This view shows some general information about the selected VM, including the process ID, package name, and
VM version.
Threads
The threads view has a list of threads running in the process of the target VM. To reduce the amount of data sent
over the wire, the thread updates are only sent when explicitly enabled by toggling the "threads" button in the
toolbar. This toggle is maintained per VM. This tab includes the following information:
ID - a VM-assigned unique thread ID. In Dalvik, these are odd numbers starting from 3.
Tid - the Linux thread ID. For the main thread in a process, this will match the process ID.
Status - the VM thread status. Daemon threads are shown with an asterisk (*). This will be one of the following:
running - executing application code
sleeping - called Thread.sleep()
monitor - waiting to acquire a monitor lock
wait - in Object.wait()
native - executing native code
vmwait - waiting on a VM resource
zombie - thread is in the process of dying
init - thread is initializing (you shouldn't see this)
starting - thread is about to start (you shouldn't see this either)
utime - cumulative time spent executing user code, in "jiffies" (usually 10ms).
stime - cumulative time spent executing system code, in "jiffies" (usually 10ms).
Name - the name of the thread
"ID" and "Name" are set when the thread is started. The remaining fields are updated periodically (default is every
4 seconds).
VM Heap
Displays some heap stats, updated during garbage collection.
If, when a VM is selected, the VM Heap view says that heap updates are not enabled, click the
"Show heap updates" button, located in the top-left toolbar. Back in the VM Heap view, click Cause
GC to perform garbage collection and update the heap stats.
Allocation Tracker
In this view, you can track the memory allocation of each virtual machine.
With a VM selected in the left pane, click Start Tracking, then Get Allocations to view all
allocations since tracking started.
The table below will be filled with all the relevant data. Click it again to refresh the list.
Emulator Control
With these controls, you can simulate special device states and activities. Features include:
Telephony Status - change the state of the phone's Voice and Data plans (home, roaming, searching,
etc.), and simulate different kinds of network Speed and Latency (GPRS, EDGE, UTMS, etc.).
Telephony Actions - perform simulated phone calls and SMS messages to the emulator.
Location Controls - send mock location data to the emulator so that you can perform location-
aware operations like GPS mapping.To use the Location Controls, launch your application in the
Android emulator and open DDMS. Click the Emulator Controls tab and scroll down to Location
Controls
File Explorer
With the File Explorer, you can view the device file system and perform basic management, like
pushing and pulling files. This circumvents using the adb push and pull commands, with a GUI
experience

With DDMS open, select Device > File Explorer... to open the File Explorer window. You can drag-
and-drop into the device directories, but cannot drag out of them. To copy files from the device,
select the file and click the Pull File from Device button in the toolbar. To delete files, use
the Delete button in the toolbar.

Screen Capture
You can capture screen images on the device or emulator by selecting Device > Screen capture... in
the menu bar, or press CTRL-S. Be sure to select a device first.
Exploring Processes
You can see the output of ps -x for a specific VM by selecting Device > Show process status... in the
menu bar.
Cause a GC to Occur
Cause garbage collection to occur in the selected application by pressing the trash can button on the
toolbar.
Android Activity Lifecycle

As a user navigates through, out of, and back to your app, the Activity instances in your app
transition through different states in their lifecycle.

The Activity class provides a number of callbacks that allow the activity to know that a state has
changed:
that the system is creating, stopping, or resuming an activity, or destroying the process in which the
activity resides.

Android Activity Lifecycle is controlled by 7 methods of android.app.Activity class.

The android Activity is the subclass of ContextThemeWrapper class.
An activity is the single screen in android.
It is like window or frame of Java.
By the help of activity, you can place all your UI components or widgets in a single screen.
The 7 lifecycle method of Activity describes how activity will behave at different states.
Android Activity Lifecycle methods

Method Description

onCreate called when activity is first created.

onStart called when activity is becoming visible to the user.
onResume called when activity will start interacting with the user.
onPause called when activity is not visible to the user.
onStop called when activity is no longer visible to the user.
onRestart called after your activity is stopped, prior to start.
onDestroy called before the activity is destroyed.
AndroidManifest.xml:

• Every project in Android includes a manifest file, which is AndroidManifest.xml, stored in

the root directory of its project hierarchy.

• The manifest file is an important part of our app because it defines the structure and
metadata of our application, its components, and its requirements.

• This file includes nodes for each of the Activities, Services, Content Providers and Broadcast
Receiver that make the application and using Intent Filters and Permissions, determines how
they co-ordinate with each other and other applications.
The manifest file is required to declare the following:
• The components of the app, which include all activities, services, broadcast receivers, and
content providers.
• Each component must define basic properties such as the name of its Kotlin or Java class. It can
also declare capabilities such as which device configurations it can handle, and intent filters that
describe how the component can be started.
• The permissions that the app needs in order to access protected parts of the system or other
apps.
• It also declares any permissions that other apps must have if they want to access content from
this app.
• The hardware and software features the app requires, which affects which devices can install
the app from Google Play.
 Locales
• A Locale object represents a specific geographical, political, or cultural region. An operation
that requires a Locale to perform its task is called locale-sensitive and uses the Locale to tailor
information for the user.
• For example, displaying a number is a locale-sensitive operation— the number should be
formatted according to the customs and conventions of the user's native country, region, or
culture.
• The Locale class implements IETF BCP 47 which is composed of RFC 4647 "Matching
of Language Tags" and RFC 5646 "Tags for Identifying Languages" with support for the
LDML (UTS#35, "Unicode Locale Data Markup Language") BCP 47-compatible
extensions for locale data exchange.
 Supporting Multiple Screens

• Android is designed to run on a variety of devices that offer a range of screen sizes and
resolutions.
• For applications, the platform provides a consistent environment across devices and handles
much of the complexity of adapting an application's UI to the screen on which it is being
displayed.
• At the same time, the platform exposes APIs that give application developers precise control
over their application's UI when displayed on specific screen sizes and resolutions.

• Starting in Android 2.2, the platform includes support for extra high density screens (xhdpi-
dots per inch), and starting in Android 2.3, the platform includes support for extra large
screens (xlarge).
 Terms and Concepts :
• Screen size Actual physical size, measured as the screen's diagonal.
• For simplicity, Android collapses all actual screen sizes into four generalized sizes:
small, normal, large, and extra large.
• Applications can provide custom layouts for each of these four sizes — the platform
transparently handles the rendering of the layouts at the actual screen size.
• Aspect ratio The proportional relationship of the screen's physical width to its height.
Applications can provide layout resources for specific aspect ratios by using the
resource qualifiers long and not long.

• Resolution The total number of physical pixels on a screen. Although resolution is

often expressed as width x height, resolution does not imply a specific aspect ratio. In
Android, applications do not work directly with resolution.
• Density Based on the screen resolution, the spread of pixels across the physical width and height of
the screen.
A screen with lower density has fewer available pixels spread across the screen width and height,
where a screen with higher density has more — sometimes significantly more — pixels spread across
the same area.
The density of a screen is important because, other things being equal, a UI element (such as a button)
whose height and width are defined in terms of screen pixels will appear larger on the lower density
screen and smaller on the higher density screen.
For simplicity, Android collapses all actual screen densities into four generalized densities: low,
medium, large, and extra large.
Applications can provide custom resources for each of these densities — the platform handles any
necessary scaling of the resources up or down to meet the specific screen density.
Density-independent pixel (dp)A virtual pixel unit that applications can use in defining their
UI, to express layout dimensions or position in a density-independent way.

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, the
baseline density assumed by the platform (as described later in this document).

At run time, the platform transparently handles any scaling of the dp units needed, based on
the actual density of the screen in use.

The conversion of dp units to screen pixels is simple: pixels = dps * (density / 160).

For example, on 240 dpi screen, 1 dp would equal 1.5 physical pixels.

Using dp units to define your application's UI is highly recommended, as a way of ensuring

proper display of your UI on different screens.
 Range of screens supported
• Starting from Android 1.6, the platform provides support for multiple screen sizes and
resolutions, reflecting the many new types and sizes of devices on which the platform runs.

• If you are developing an application that will run on Android 1.6 or later, you can use the
compatibility features of the Android platform to ensure that your application UI renders
properly across the range of supported screen sizes and resolutions.
• To simplify the way that developers design their user interfaces for multiple devices and to
allow more devices to participate without affecting applications, the platform divides the
range of actual supported screen sizes and resolutions into:
• A set of four generalized sizes: small, normal, large, and xlarge
• A set of four generalized densities: ldpi (low), mdpi (medium), hdpi (high),
and xhdpi (extra high)
Representations of width-based window size classes.
Representations of height-based window size classes.
Screen sizes and densities of emulator skins included in the Android SDK.
The example screens below illustrate the density independence provided by the platform.
Note that both the layouts and launcher icons are displayed at the same physical sizes,
although screen sizes, aspect ratios, and densities are different.
• Java:

• The Java folder contains the Java source code files. These files are used as a controller
for controlled UI (Layout file). It gets the data from the Layout file and after
processing that data output will be shown in the UI layout. It works on the backend of
an Android application.
• drawable:

• A Drawable folder contains resource type file (something that can be drawn). Drawables may take a
variety of file like Bitmap (PNG, JPEG), Nine Patch, Vector (XML), Shape, Layers, States, Levels,
and Scale.

• layout:

• A layout defines the visual structure for a user interface, such as the UI for an Android application.
This folder stores Layout files that are written in XML language.
• <?xml version="1.0" encoding="utf-8"?>

• <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

• android:layout_width="match_parent"

• android:layout_height="match_parent"

• android:orientation="vertical" >

• <TextView android:id="@+id/text"

• android:layout_width="wrap_content"

• android:layout_height="wrap_content"

• android:text="Hello, I am a TextView" />

• <Button android:id="@+id/button"

• android:layout_width="wrap_content"

• android:layout_height="wrap_content"

• android:text="Hello, I am a Button" />

• </LinearLayout>
• mipmap:

• Mipmap folder contains the Image Asset file that can be used in Android Studio application.
You can generate the icon types like Launcher icons, Action bar and tab icons, and Notification
icons.

• colors.xml:

• colors.xml file contains color resources of the Android application. Different color values are
identified by a unique name that can be used in the Android application program.
• Below is a sample colors.xml file:

• <?xml version="1.0" encoding="utf-8"?>

• <resources>
• <color name="colorPrimary">#3F51B5</color>
• <color name="colorPrimaryDark">#303F9F</color>
• </resources>
• strings.xml:

• The strings.xml file contains string resources of the Android application. The different string
value is identified by a unique name that can be used in the Android application program. This
file also stores string array by using XML language.

• Below is a sample strings.xml file:

• <resources>
• <string name="app_name">MM Polytechnic</string>
• </resources>
• styles.xml:
• The styles.xml file contains resources of the theme style in the Android application. This file is
written in XML language. Below is a sample styles.xml file:
• <resources>
• <!-- Base application theme. -->
• <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
• <!-- Customize your theme here. -->
• <item name="colorPrimary">@color/colorPrimary</item>
• <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
• </style>
• </resources>
• build.gradle(Module: app):

• This defines the module-specific build configurations. Here you can add dependencies what you
need in your Android application.