Android Emulator

Requirements and recommendations

The Android Emulator has additional requirements beyond the basic system requirements for
Android Studio, which are described below:

 SDK Tools 26.1.1 or higher

 64-bit processor
 Windows: CPU with UG (unrestricted guest) support
 HAXM 6.2.1 or later (HAXM 7.2.0 or later recommended)-Hardware Acceleration Executive
Manager

The use of hardware acceleration has additional requirements on Windows and Linux:

 Intel processor on Windows or Linux: Intel processor with support for Intel VT-x, Intel EM64T (Intel
64), and Execute Disable (XD) Bit functionality
 AMD processor on Linux: AMD processor with support for AMD Virtualization (AMD-V)
and Supplemental Streaming SIMD Extensions 3 (SSSE3)
 AMD processor on Windows: Android Studio 3.2 or higher and Windows 10 April 2018 release or
higher for Windows Hypervisor Platform (WHPX) functionality

To work with Android 8.1 (API level 27) and higher system images, an attached webcam must
have the capability to capture 720p frames.

Run the Android Emulator directly in Android Studio

File > Settings > Tools > Emulator (Android Studio > Preferences > Tools > Emulator on macOS) and
deselect Launch in a tool window.

Install and add files

To install an APK file on the emulated device, drag an APK file onto the emulator screen. An APK
Installer dialog appears. When the installation completes, you can view the app in your apps list.

To add a file to the emulated device, drag the file onto the emulator screen. The file is placed in
the /sdcard/Download/ directory.

Extended controls, settings, and help

To open the Extended controls window, click More in the emulator panel.

Extended controls details:

Location: The emulator lets you simulate "my location" information: the location where the emulated device is
currently located. For example, if you click My Location in Google Maps and then send a location, the map
shows it.

Controls for the device's location information are organized under two tabs: Single points and Routes.

Displays The emulator allows you to deploy your app to multiple displays, which support customizable
 dimensions and can help you test apps that support multi- window and multi- display.

Cellular The emulator lets you simulate various network conditions. You can approximate the
network speed for different network protocols, or you can specify Full, which transfers data as
quickly as your computer allows. Specifying a network protocol is always slower than Full. You can
also specify the voice and data network status, such as roaming. The defaults are set in the AVD.
Battery You can simulate the battery properties of a device to see how your app performs under different
conditions. Like None, AC charger, Battery Health: Good , dead etc
Phone The emulator lets you simulate incoming phone calls and text messages.

Virtual sensors: Accelerometer, Ambient temperature: This environmental sensor measures ambient air
temperature.

Magnetic field: This position sensor measures the ambient magnetic field on the X, Y, and Z axes, respectively. The
values are in microteslas (μT).

Proximity: This position sensor measures the distance from an object; for example, it can notify a phone that a face
is close to it to make a call. The proximity sensor must be enabled in your AVD to use this control.

Light: This environmental sensor measures illuminance. The values are in lux units.

Pressure: This environmental sensor measures ambient air pressure. The values are in millibar (hPa) units.

Relative Humidity: This environmental sensor measures ambient relative humidity.

Settings > General

Emulator window theme: Select Light or Dark.

Send keyboard shortcuts to: By default, some keyboard combinations will trigger emulator control shortcuts. If you’re
developing an app that includes keyboard shortcuts, such as one targeted at devices with Bluetooth keyboards, you
can change this setting to send all keyboard input to the virtual device, including input that would be a shortcut in the
emulator.

Screenshot save location: Click the folder icon to specify a location to save screenshots of the emulator screen.

Use detected ADB location: If you're running the emulator from Android Studio, you should select this setting (the
default). If you run the emulator from outside Android Studio and want it to use a specific adb executable, deselect
this option and specify the SDK Tools location. If this setting is incorrect, features such as screenshot capture and
drag-and-drop app installation won't work.

When to send crash reports: Select Always, Never, or Ask.

Show window frame around device: By default, emulators with device skin files are shown without a surrounding
window frame.

Settings > Proxy

By default, the emulator uses the Android Studio HTTP proxy settings, but this screen allows you to manually define
an HTTP proxy configuration for the emulator. For more information, see Using the emulator with a proxy.

Settings > Advanced

OpenGL ES renderer: Select the graphics acceleration type. (This is equivalant to the -gpu command line option).

Autodetect based on host: Let the emulator choose hardware or software graphics acceleration based on your
computer setup. It checks if your GPU driver matches a list of known faulty GPU drivers, and if it does, the emulator
disables graphics hardware emulation and instead uses the CPU.

ANGLE: (Windows only.) Use ANGLE Direct3D to render graphics in software. (Almost Native Graphics Layer
Engine)

SwiftShader: Use SwiftShader to render graphics in software.

Desktop native OpenGL: Use the GPU on your host computer. This option is typically the fastest. However, some
drivers have issues with rendering OpenGL graphics, so it might not be a reliable option.

OpenGL ES API level: Select the maximum version of OpenGL ES to use in the emulator.

Autoselect: Let the emulator choose the OpenGL ES version based on the host and guest support.

Renderer maximum (up to OpenGL ES 3.1): Attempt to use the maximum version of OpenGL ES.

Compatibility (OpenGL ES 1.1/2.0): Use the version of OpenGL ES that is compatible with most environments.

Limitations
The Android Emulator doesn't include virtual hardware for the following:

 Bluetooth
 NFC
 SD card insert/eject
 Device-attached headphones
 USB

Logcat command-line tool

The Android logging system provides a mechanism for collecting and viewing system debug
output. Logs from various applications and portions of the system are collected in a series of
circular buffers, which then can be viewed and filtered by the logcat command. You can
use logcat from an ADB shell to view the log messages.
Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an
emulator instance or connected 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

Write and View Logs with Logcat

The Logcat window in Android Studio displays system messages, such as when a garbage collection
occurs, and messages that you added to your app with the Log class. It displays messages in real time
and keeps a history so you can view older messages.
 To display just the information of interest, you can create filters, modify how much information is displayed
in messages, set priority levels, display messages produced by app code only, and search the log. By
default, logcat shows the log output related to the most recently run app only.
When an app throws an exception, logcat shows a message followed by the associated stack trace
containing links to the line of code.
As of Android Studio 2.2, the Run window also displays log messages for the current running app. Note
that you can configure the logcat output display, but not the Run window.

View your app logs

To display the log messages for an app:

1. Build and run your app on a device.

2. Click View > Tool Windows > Logcat

The Logcat toolbar provides the following buttons:

1. Clear logcat : Click to clear the visible log.

2. Scroll to the end : Click to jump to the bottom of the log and see the latest log messages. If you
then click a line in the log, the view pauses scrolling at that point.

3. Up the stack trace and Down the stack trace : Click to navigate up and down the stack
traces in the log, selecting the subsequent filenames (and viewing the correspnding line numbers in
the editor) that appear in the printed exceptions. This is the same behavior as when you click on a
filename in the log.

4. Use soft wraps : Click to enable line wrapping and prevent horizontal scrolling (though any
unbreakable strings will still require horizontal scrolling).

5. Print : Click to print the logcat messages. After selecting your print preferences in the dialog that
appears, you can also choose to save to a PDF.

6. Restart : Click to clear the log and restart logcat. Unlike the Clear logcat button, this recovers
and displays previous log messages, so is most useful if Logcat becomes unresponsive and you don't
want to lose your log messages.

7. Logcat header : Click to open the Configure Logcat Header dialog, where you can customize
the appearance of each logcat message, such as whether to show the date and time.

8. Screen capture : Click to capture a screenshot.

9. Screen record : Click to record a video of the device (for a maximum of 3 minutes).

Write log messages

The Log class allows you to create log messages that appear in logcat. Generally, you should use
the following log methods, listed in order from the highest to lowest priority (or, least to most
verbose):
 Log.e(String, String) (error)
 Log.w(String, String) (warning)
 Log.i(String, String) (information)
 Log.d(String, String) (debug)
 Log.v(String, String) (verbose)

Ex. private static final String TAG = "MyActivity";

...
Log.i(TAG, "MyClass.getView() — get item number " + position);

Set the log level

You can control how many messages appear in logcat by setting the log level. You can display all
messages, or just the messages indicating the most severe conditions.

Remember that logcat continues to collect all messages regardless of the log level setting. The
setting just determines what logcat displays.

In the Log level menu, select one of the following values:

 Verbose: Show all log messages (the default).

 Debug: Show debug log messages that are useful during development only, as well as the message levels
lower in this list.
 Info: Show expected log messages for regular usage, as well as the message levels lower in this list.
 Warn: Show possible issues that are not yet errors, as well as the message levels lower in this list.
 Error: Show issues that have caused errors, as well as the message level lower in this list.
 Assert: Show issues that the developer expects should never happen.

Filter logcat messages

One way to reduce the log output to a manageable level is to restrict it by using a filter.

To define and apply a filter:

1. In the filter menu, select a filter option:

 Show only selected application: Display the messages produced by the app code only (the
default). Logcat filters the log messages using the PID of the active app.
 No Filters: Apply no filters. Logcat displays all log messages from the device, regardless of which
process you selected.
 Edit Filter Configuration: Create or modify a custom filter. For example, you could create a filter
to view log messages from two apps at the same time.

Read garbage collection messages

Sometimes when a garbage collection event occurs, they're printed to logcat.
 DDMS
Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding
services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state
information, incoming call and SMS spoofing, location data spoofing, and more. This page provides a modest
discussion of DDMS features; it is not an exhaustive exploration of all the features and capabilities.

It is a debugging tool from the Android software development kit (SDK). Able to monitor operations in the emulator as well as
real devices, DDMS reports the details of each processing thread and time spent whether in the app or Android OS.

The Android Profiler

The Android Profiler in Android Studio 3.0 and higher replaces the Android Monitor tools. The Android Profiler tools provide
real-time data to help you to understand how your app uses CPU, memory, network, and battery resources.

To open the Profiler window, choose View > Tool Windows > Profiler or click Profile in the toolbar. If
prompted by the Select Deployment Target dialog, select the device on which to profile your app. If you've
connected a device over USB but don't see it listed, ensure that you have enabled USB debugging. If you're using the
Android Emulator or a rooted device, the Android Profiler lists all running processes, even though they might not be
debuggable. When you launch a debuggable app, that process is selected by default.

Android Profiler continues to collect profiling data until you disconnect the device or click End Session.

1 Android Profiler shows the process and device currently being profiled.

2 In the Sessions pane, choose which session to view, or start a new profiling session.

3 Use the zoom buttons to control how much of the timeline to view, or use the Attach to live button to jump to the
real-time updates.

4 The event timeline shows events related to user input, including keyboard activity, volume control changes, and
screen rotations.

5 The shared timeline view, which includes graphs for CPU, memory, network, and energy usage.

This shared timeline view only shows the timeline graphs. To access the detailed profiling tools, click the graph that
corresponds to the performance data that you want to inspect. For example, to access tools to inspect the heap and
track memory allocations, click the Memory graph.

Not all profiling data is visible by default. If you see a message that says "Advanced profiling is unavailable for the
selected process," you can enable advanced profiling in your run configuration to view the additional data.

Sessions

You can save Profiler data as sessions, which are retained until you quit Android Studio. By recording profiling
information in multiple sessions and switching between them, you can compare resource usage in various scenarios.

Enable additional support for older devices (API level < 26)

To show you additional profiling data when running a device with Android 7.1 or lower, Android Studio must inject
monitoring logic into your compiled app.

To enable additional support for older devices, follow these steps:

1. Select Run > Edit Configurations.

2. Select your app module in the left pane.

3. Click the Profiling tab, and then check Enable additional support for older devices (API level < 26).

4. Build and run your app again.

 Enabling additional support for older devices makes the build process slower, so you should enable it only when you
want to start profiling your app.

Run standalone profilers

The standalone Android Studio Profilers allow you to profile your app without running the full Android Studio IDE.

To run the standalone profilers, do the following:

1. Make sure the profiler is not currently running inside of Android Studio.

2. Go to the installation directory and navigate to the bin directory:

Windows/Linux: <studio-installation-folder>/bin

macOS: <studio-installation-folder>/Contents/bin
3. Depending on your OS, run profiler.exe or profiler.sh. The Android Studio splash screen appears.

4. Start the Android emulator or connect an Android device and wait for the home screen to load.

Start another activity

When you complete the previous lesson, you have an app that shows an activity that consists of a single screen with a text field
and a Send button. In this lesson, you add some code to the MainActivity that starts a new activity to display a message when
the user taps the Send button.

Build an intent

An Intent is an object that provides runtime binding between separate components, such as two activities.
The Intent represents an app’s intent to do something. You can use intents for a wide variety of tasks, but in this
lesson, your intent starts another activity.

1. Create the Activities

2. Add the Activities to the app’s Manifest

<activity android:name=".SecondActivity"></activity>

3. Create an Intent referencing the Activity class you want to switch to

Intent intent = new Intent(this, SecondActivity.class);
startActivity(intent);

4. Call the startActivity(Intent) method to switch to the Activity

public void onClick(View view) {

switchActivities();

}) }

private void switchActivities() {

Intent switchActivityIntent = new Intent(this, SecondActivity.class);

startActivity(switchActivityIntent) }

5. Create a back button on the new Activity and call the finish() method on an Activity when the back button
is pressed
 UI screen components

A typical user interface of an android application consists of action bar and the application content area.

 Main Action Bar

 View Control
 Content Area
 Split Action Bar
These components have also been shown in the image below −

Understanding Screen Components

The basic unit of android application is the activity. A UI is defined in an xml file. During compilation, each element in
the XML is compiled into equivalent Android GUI class with attributes represented by methods.
View and ViewGroups
An activity is consist of views. A view is just a widget that appears on the screen. It could be button e.t.c. One or
more views can be grouped together into one GroupView. Example of ViewGroup includes layouts.
Types of layout
There are many types of layout. Some of which are listed below −

 Linear Layout
 Absolute Layout
 Table Layout
 Frame Layout
 Relative Layout
Linear Layout
Linear layout is further divided into horizontal and vertical layout. It means it can arrange views in a single column or
in a single row. Here is the code of linear layout(vertical) that includes a text view.

<?xml version=”1.0” encoding=”utf-8”?>

<LinearLayout xmlns:android=”http://schemas.android.com/apk/res/android”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
android:orientation=”vertical” >

<TextView
android:layout_width=”fill_parent”
android:layout_height=”wrap_content”
android:text=”@string/hello” />
</LinearLayout>
AbsoluteLayout
The AbsoluteLayout enables you to specify the exact location of its children. It can be declared like this.

<AbsoluteLayout
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
xmlns:android=”http://schemas.android.com/apk/res/android” >

<Button
android:layout_width=”188dp”
android:layout_height=”wrap_content”
android:text=”Button”
android:layout_x=”126px”
android:layout_y=”361px” />
</AbsoluteLayout>
TableLayout
The TableLayout groups views into rows and columns. It can be declared like this.

<TableLayout
xmlns:android=”http://schemas.android.com/apk/res/android”
android:layout_height=”fill_parent”
android:layout_width=”fill_parent” >

<TableRow>
<TextView
android:text=”User Name:”
android:width =”120dp”
/>

<EditText
android:id=”@+id/txtUserName”
android:width=”200dp” />
</TableRow>

</TableLayout>
RelativeLayout
The RelativeLayout enables you to specify how child views are positioned relative to each other.It can be declared
like this.

<RelativeLayout
android:id=”@+id/RLayout”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
xmlns:android=”http://schemas.android.com/apk/res/android” >
</RelativeLayout>
FrameLayout
The FrameLayout is a placeholder on screen that you can use to display a single view. It can be declared like this.

<?xml version=”1.0” encoding=”utf-8”?>

<FrameLayout
android:layout_width=”wrap_content”
android:layout_height=”wrap_content”
android:layout_alignLeft=”@+id/lblComments”
android:layout_below=”@+id/lblComments”
android:layout_centerHorizontal=”true” >

<ImageView
android:src = “@drawable/droid”
android:layout_width=”wrap_content”
android:layout_height=”wrap_content” />
</FrameLayout>

Apart form these attributes, there are other attributes that are common in all views and ViewGroups. They are listed
below −

Sr.No View & description

1
layout_width

Specifies the width of the View or ViewGroup

2
layout_height

Specifies the height of the View or ViewGroup

3
layout_marginTop

Specifies extra space on the top side of the View or ViewGroup

4
layout_marginBottom

Specifies extra space on the bottom side of the View or ViewGroup

5
layout_marginLeft

Specifies extra space on the left side of the View or ViewGroup

6
layout_marginRight

Specifies extra space on the right side of the View or ViewGroup

7
layout_gravity

Specifies how child Views are positioned

8
layout_weight

Specifies how much of the extra space in the layout should be allocated to the View

Units of Measurement

When you are specifying the size of an element on an Android UI, you should remember the following units of
measurement.

Sr.No Unit & description

1
dp

Density-independent pixel. 1 dp is equivalent to one pixel on a 160 dpi screen.

2
sp

Scale-independent pixel. This is similar to dp and is recommended for specifying font sizes

3
pt

Point. A point is defined to be 1/72 of an inch, based on the physical screen size.

4
px

Pixel. Corresponds to actual pixels on the screen

Screen Densities

Sr.No Density & DPI

1
Low density (ldpi)

120 dpi

2
Medium density (mdpi)

160 dpi

3
High density (hdpi)
 240 dpi

4
Extra High density (xhdpi)

320 dpi

Optimizing layouts

Here are some of the guidelines for creating efficient layouts.

 Avoid unnecessary nesting

 Avoid using too many Views
 Avoid deep nesting

dp or dip ( Density-independent Pixels) — an abstract unit that is based on the physical density of the screen.

These units are relative to a 160 dpi screen, so one dp is one pixel on a 160 dpi screen. The ratio of dp-to-pixel will

change with the screen density, but not necessarily in direct proportion. Note: The compiler accepts both “dip” and

“dp”, though “dp” is more consistent with “sp”.

sp (Scaleable Pixels OR scale-independent pixels) — this is like the dp unit, but it is also scaled by the user’s font

size preference. It is recommended you use this unit when specifying font sizes, so they will be adjusted for both the

screen density and user’s preference. Note, the Android documentation is inconsistent on what sp actually stands for,

one doc says “scale-independent pixels”, the other says “scaleable pixels”.

Density-independent pixel (dp)

A virtual pixel unit that you should use when defining UI layout, 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, which is the
baseline density assumed by the system for a “medium” density screen. At runtime, the system transparently handles
any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to
screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels.
You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with
different densities

Density Bucket -> Screen Display => Physical Size => Pixel Size

ldpi -> 120 dpi => 0.5 x 0.5 in => 0.5 in * 120 dpi = 60x60 px

mdpi -> 160 dpi => 0.5 x 0.5 in => 0.5 in * 160 dpi = 80x80 px

hdpi -> 240 dpi => 0.5 x 0.5 in => 0.5 in * 240 dpi = 120x120 px

xhdpi -> 320 dpi => 0.5 x 0.5 in => 0.5 in * 320 dpi = 160x160 px

xxhdpi -> 480 dpi => 0.5 x 0.5 in => 0.5 in * 480 dpi = 240x240 px

xxxhdpi -> 640 dpi => 0.5 x 0.5 in => 0.5 in * 640 dpi = 320x320 px