Topic 1 - Native Android Application

A native mobile app is a smartphone application that is coded in a specific programming

language, such as Objective C for iOS or Java for Android operating systems. Native mobile
apps provide fast performance and a high degree of reliability. They also have access to a
phone's various devices, such as its camera and address book. In addition, users can use some
apps without an internet connection.

The two main mobile OS platforms are Apple's iOS and Google's Android. Native apps are
written in the code preliminarily used for the device and its OS. For example, developers write
iOS applications in Objective-C or Swift, while they create Android-native apps in Java.

Native apps work with the device's OS in ways that enable them to perform faster and more
flexibly than alternative application types. If the app is marketed to users of various device
types, developers create a separate app version for each one.

For example, the Facebook application was once written in HTML5 to use the same code for
iOS, Android and mobile web. However, the app was slower for iOS users, leading Facebook's
app developers to create separate code for iOS. Complex tasks can be rebalanced, such as
networking done in the background of the main thread or program, which drives the UI.

Topic 2 - Native application pros and cons

Advantages of native applications include:

• Broad functionalities due to using the capabilities of the underlying device

• Fast and responsive software performance

• Push notifications

• A UI that better matches with user experiences of the OS

• Quality assurance though ratings in application stores.

Disadvantages of native applications include:

• Multiple code bases because each device has its own version of the app
• The cost for additional developers to build and manage a code base for each platform.

• Time spent on multiple builds for separate platforms in each feature update.

Native vs. Web apps

A web app is an application that the user does not download and instead accesses via a web
browser over a network. Example web browsers include Google Chrome, Safari and Mozilla
Firefox. Web apps provide functionality from bank account access to YouTube video viewing
via, for example, Safari on an iPhone.

While native apps are written to the specific device, a majority of web applications can be
written in JavaScript, CSS and the standard version of HTML for universal use across various
browsers. Web apps can use a single code base because they are not designed around a specific
device. Web apps are fast and simple to build but are not as versatile and quick as native apps.

Native vs. hybrid apps

Hybrid applications are a combination of native and web apps. The inner workings of a hybrid
application are similar to a web app, but it installs like a native app. Hybrid applications have
access to internal device APIs, which means they can use resources such as the camera, storage
and GPS. Yelp and Instagram are examples of hybrid apps.

Hybrid applications are built with HTML and CSS. Developers create one code base, then
make small changes to tailor the app to each platform. Fewer developers are dedicated to each
platform with a hybrid app than with a fully native app. Hybrid apps typically run a web app
through a container or WebView, a browser that can be contained inside of a mobile app.

Hybrid applications perform differently than native apps in several ways. Hybrid applications
are based on web apps and contain the same navigational elements as web applications.
Additionally, there is no offline mode for a hybrid application -- it only works with an internet
connection. Native apps, by contrast, can operate offline.
 Cost differences between native and hybrid applications are minimal. In both application types,
developers must write code to launch on multiple platforms. In general, if the development
time of an application is less than four to six months, a hybrid application is preferable, as you
can construct them faster.

Topic 2 - SDK Features

A software development kit that enables developers to create applications for the Android
platform. The Android SDK includes sample projects with source code, development tools,
an emulator, and required libraries to build Android applications. Applications are written
using the Java programming language and run on Dalvik, a custom virtual machine designed
for embedded use which runs on top of a Linux kernel.

Short for software development kit, a programming package that enables a programmer to
develop applications for a specific platform. Typically an SDK includes one or more APIs,
programming tools, and documentation.

A self-contained operating environment that behaves as if it is a separate computer. For

example, Java applets run in a Java virtual machine (VM) that has no access to the
host operating system. This design has two advantages:

• System Independence: A Java application will run the same in any Java VM, regardless of
the hardware and software underlying the system.

• Security: Because the VM has no contact with the operating system, there is little possibility
of a Java program damaging other files or applications.

The second advantage, however, has a downside. Because programs running in a VM are
separate from the operating system, they cannot take advantage of special operating system
features.

The Android software development kit (SDK) includes everything you need to initiate
development, testing and debugging of android applications.

Following are included in the SDK

The Android APIs: The core of the SDK (Software Development Kit) is the Android API
libraries that provide developer to access to the Android stack. These are the same libraries
used at Google to create native Android applications.

Development Tools: To turn Android source code into executable Android applications and
the SDK includes several development tools that let us of the compile and debug our Android
applications.

The Android Emulator: The Android Emulator is a fully communicating Android device
emulator featuring several alternative skins. Using the emulator that we can see how our
applications can will look and behave on a real Android device (That is not a virtual concept).
All Android applications run within the Dalvik Virtual Machine so that the software emulator
is a brilliant situation. It is very vital point that devices are hardware neutral. This device is also
providing a better independent test environment than any single hardware implementation.

Full Documentation: The SDK (Software Development Kit) includes extensive code-level
reference information detailing from exactly which we included in each package and class and
also know that the using procedure them. In addition to the code documentation and Android’s
reference certification explicates process to get started and gives the detailed explanations of
the fundamentals behind Android development System.

Sample Code: The Android SDK (Software Development Kit) includes a selection of sample
applications that prove some of the possibilities available using Android the process also as
simple programs that highlight how to use individual API (Application Programming
Interfaces) features.

Online Support: Online support is no doubt very vital point that despite it’s relative to youth.
Android has generated a vibrant developer community. The Google Groups at groups are active
forums for the Android developers with regular input from the Android development team at
Google.

Topic 3 - The Open Handset Alliance.

The Open Handset Alliance (OHA) is a consortium whose goal is to develop open standards
for mobile devices, promote innovation in mobile phones and provide a better experience for
consumers at a lower cost.
 The Open Handset Alliance is made up of over 30 telecom-related entities, including wireless
carriers, semiconductor companies, handset manufacturers and software companies. However,
several major wireless companies and manufacturers are absent from the coalition, including
Nokia, Symbian, Apple, RIM, Microsoft, Verizon and Cingular.

The OHA introduced a mobile device operating system called Android Symbian operating
system.

Topic 4 - Development

Android is one of the greatest mobile platforms universally used for mobile application
development. This development platform has the capability to run on different mobile phones,
giving support to thousands of games and apps. An Android operating system provides a huge
marketplace to the developers for performing Android application development to deploy the
apps they have created and make them available on different smartphones and other mobile
devices.

Topic 5 - Application Fundamentals

Android apps can be written using Kotlin, Java, and C++ languages. The Android SDK tools
compile your code along with any data and resource files into an APK, an Android package,
which is an archive file with an .apk suffix. One APK file contains all the contents of an
Android app and is the file that Android-powered devices use to install the app.

Each Android app lives in its own security sandbox, protected by the following Android
security features:

• The Android operating system is a multi-user Linux system in which each app is a different
user.

• By default, the system assigns each app a unique Linux user ID (the ID is used only by the
system and is unknown to the app). The system sets permissions for all the files in an app so
that only the user ID assigned to that app can access them.

• Each process has its own virtual machine (VM), so an app's code runs in isolation from other
apps.
• By default, every app runs in its own Linux process. The Android system starts the process
when any of the app's components need to be executed, and then shuts down the process when
it's no longer needed or when the system must recover memory for other apps.

The Android system implements the principle of least privilege. That is, each app, by default,
has access only to the components that it requires to do its work and no more. This creates a
very secure environment in which an app cannot access parts of the system for which it is not
given permission. However, there are ways for an app to share data with other apps and for an
app to access system services:

• It's possible to arrange for two apps to share the same Linux user ID, in which case they can
access each other's files. To conserve system resources, apps with the same user ID can also
arrange to run in the same Linux process and share the same VM. The apps must also be signed
with the same certificate.

• An app can request permission to access device data such as the device's location, camera, and
Bluetooth connection. The user has to explicitly grant these permissions.

• The rest of this document introduces the following concepts:

• The core framework components that define your app.

• The manifest file in which you declare the components and the required device features for
your app.

• Resources that are separate from the app code and that allow your app to gracefully optimize
its behaviour for a variety of device configurations.

APP COMPONENTS

App components are the essential building blocks of an Android app. Each component is an
entry point through which the system or a user can enter your app. Some components depend
on others.

There are four different types of app components:

• Activities

• Services
• Broadcast receivers

• Content providers

Each type serves a distinct purpose and has a distinct lifecycle that defines how the component
is created and destroyed. The following sections describe the four types of app components.

Activities

An activity is the entry point for interacting with the user. It represents a single screen with a
user interface. For example, an email app might have one activity that shows a list of new
emails, another activity to compose an email, and another activity for reading emails. Although
the activities work together to form a cohesive user experience in the email app, each one is
independent of the others. As such, a different app can start any one of these activities if the
email app allows it. For example, a camera app can start the activity in the email app that
composes new mail to allow the user to share a picture. An activity facilitates the following
key interactions between system and app:

• Keeping track of what the user currently cares about (what is on screen) to ensure that
the system keeps running the process that is hosting the activity.

• Knowing that previously used processes contain things the user may return to (stopped
activities), and thus more highly prioritize keeping those processes around.

• Helping the app handle having its process killed so the user can return to activities with
their previous state restored.

• Providing a way for apps to implement user flows between each other, and for the
system to coordinate these flows. (The most classic example here being share.)

You implement an activity as a subclass of the Activity class. For more information
about the Activity class, see the Activities developer guide.

Services

A service is a general-purpose entry point for keeping an app running in the background for all
kinds of reasons. It is a component that runs in the background to perform long-running
operations or to perform work for remote processes. A service does not provide a user interface.
For example, a service might play music in the background while the user is in a different app,
or it might fetch data over the network without blocking user interaction with an activity.
Another component, such as an activity, can start the service and let it run or bind to it in order
to interact with it. There are actually two very distinct semantics services tell the system about
how to manage an app: Started services tell the system to keep them running until their work
is completed. This could be to sync some data in the background or play music even after the
user leaves the app. Syncing data in the background or playing music also represent two
different types of started services that modify how the system handles them:

• Music playback is something the user is directly aware of, so the app tells the system
this by saying it wants to be foreground with a notification to tell the user about it; in
this case the system knows that it should try really hard to keep that service's process
running, because the user will be unhappy if it goes away.

• A regular background service is not something the user is directly aware as running, so
the system has more freedom in managing its process. It may allow it to be killed (and
then restarting the service sometime later) if it needs RAM for things that are of more
immediate concern to the user.

Bound services run because some other app (or the system) has said that it wants to
make use of the service. This is basically the service providing an API to another
process. The system thus knows there is a dependency between these processes, so if
process A is bound to a service in process B, it knows that it needs to keep process B
(and its service) running for A. Further, if process A is something the user cares about,
then it also knows to treat process B as something the user also cares about. Because of
their flexibility (for better or worse), services have turned out to be a really useful
building block for all kinds of higher-level system concepts. Live wallpapers,
notification listeners, screen savers, input methods, accessibility services, and many
other core system features are all built as services that applications implement and the
system binds to when they should be running.

A service is implemented as a subclass of Service. For more information about

the Service class, see the Services developer guide.

Broadcast receivers
A broadcast receiver is a component that enables the system to deliver events to the app
outside of a regular user flow, allowing the app to respond to system-wide broadcast
announcements. Because broadcast receivers are another well-defined entry into the app, the
system can deliver broadcasts even to apps that aren't currently running. So, for example, an
app can schedule an alarm to post a notification to tell the user about an upcoming event... and
by delivering that alarm to a Broadcast Receiver of the app, there is no need for the app to
remain running until the alarm goes off. Many broadcasts originate from the system—for
example, a broadcast announcing that the screen has turned off, the battery is low, or a picture
was captured. Apps can also initiate broadcasts—for example, to let other apps know that some
data has been downloaded to the device and is available for them to use. Although broadcast
receivers don't display a user interface, they may create a status bar notification to alert the user
when a broadcast event occurs. More commonly, though, a broadcast receiver is just
a gateway to other components and is intended to do a very minimal amount of work. For
instance, it might schedule a JobServiceto perform some work based on the event
with JobScheduler

A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is

delivered as an Intent object. For more information, see the BroadcastReceiver class.

Content providers

A content provider manages a shared set of app data that you can store in the file system, in a
SQLite database, on the web, or on any other persistent storage location that your app can
access. Through the content provider, other apps can query or modify the data if the content
provider allows it. For example, the Android system provides a content provider that manages
the user's contact information. As such, any app with the proper permissions can query the
content provider, such as ContactsContract.Data, to read and write information about a
particular person. It is tempting to think of a content provider as an abstraction on a database,
because there is a lot of API and support built in to them for that common case. However, they
have a different core purpose from a system-design perspective. To the system, a content
provider is an entry point into an app for publishing named data items, identified by a URI
scheme. Thus an app can decide how it wants to map the data it contains to a URI namespace,
handing out those URIs to other entities which can in turn use them to access the data. There
are a few particular things this allows the system to do in managing an app:
 • Assigning a URI doesn't require that the app remain running, so URIs can persist after
their owning apps have exited. The system only needs to make sure that an owning app
is still running when it has to retrieve the app's data from the corresponding URI.

• These URIs also provide an important fine-grained security model. For example, an
app can place the URI for an image it has on the clipboard, but leave its content provider
locked up so that other apps cannot freely access it. When a second app attempts to
access that URI on the clipboard, the system can allow that app to access the data via a
temporary URI permission grant so that it is allowed to access the data only behind that
URI, but nothing else in the second app.

Content providers are also useful for reading and writing data that is private to your app
and not shared.

A content provider is implemented as a subclass of ContentProvider and must

implement a standard set of APIs that enable other apps to perform transactions. For
more information, see the Content Providers developer guide.

Topic – 7 Device compatibility overviews

Android is designed to run on many different types of devices, from phones to tablets and
televisions.

As a developer, the range of devices provides a huge potential audience for your app. In order
for your app to be successful on all these devices, it should tolerate some feature variability
and provide a flexible user interface that adapts to different screen configurations.

To facilitate your effort toward that goal, Android provides a dynamic app framework in which
you can provide configuration-specific app resources in static files (such as different XML
layouts for different screen sizes).

Android then loads the appropriate resources based on the current device configuration. So
with some forethought to your app design and some additional app resources, you can publish
a single application package (APK) that provides an optimized user experience on a variety of
devices.
If necessary, however, you can specify your app's feature requirements and control which types
of devices can install your app from Google Play Store. This page explains how you can control
which devices have access to your apps, and how to prepare your apps to make sure they reach
the right audience. For more information about how you can make your app adapt to different
devices, read Supporting Different Devices.

What does "compatibility" mean?

As you read more about Android development, you'll probably encounter the term
"compatibility" in various situations. There are two types of compatibility: device
compatibility and app compatibility.

Because Android is an open source project, any hardware manufacturer can build a device that
runs the Android operating system. Yet, a device is "Android compatible" only if it can
correctly run apps written for the Android execution environment. The exact details of the
Android execution environment are defined by the Android compatibility program and each
device must pass the Compatibility Test Suite (CTS) in order to be considered compatible.

As an app developer, you don't need to worry about whether a device is Android compatible,
because only devices that are Android compatible include Google Play Store. So you can rest
assured that users who install your app from Google Play Store are using an Android
compatible device.

However, you do need to consider whether your app is compatible with each potential device
configuration. Because Android runs on a wide range of device configurations, some features
are not available on all devices. For example, some devices may not include a compass sensor.
If your app's core functionality requires the use of a compass sensor, then your app is
compatible only with devices that include a compass sensor.

Topic – 8 Permissions overview

The purpose of a permission is to protect the privacy of an Android user. Android apps must
request permission to access sensitive user data (such as contacts and SMS), as well as certain
system features (such as camera and internet). Depending on the feature, the system might
grant the permission automatically or might prompt the user to approve the request.
A central design point of the Android security architecture is that no app, by default, has
permission to perform any operations that would adversely impact other apps, the operating
system, or the user. This includes reading or writing the user's private data (such as contacts or
emails), reading or writing another app's files, performing network access, keeping the device
awake, and so on.

Permission approval

An app must publicize the permissions it requires by including <uses-permission> tags in

the app manifest. For example, an app that needs to send SMS messages would have this line
in the manifest:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.snazzyapp">

<uses-permission android:name="android.permission.SEND_SMS"/>

<application ...>
...
</application>
</manifest>

If your app lists normal permissions in its manifest (that is, permissions that don't pose much
risk to the user's privacy or the device's operation), the system automatically grants those
permissions to your app.

If your app lists dangerous permissions in its manifest (that is, permissions that could
potentially affect the user's privacy or the device's normal operation), such as
the SEND_SMS permission above, the user must explicitly agree to grant those permissions.

Request prompts for dangerous permissions

Only dangerous permissions require user agreement. The way Android asks the user to grant
dangerous permissions depends on the version of Android running on the user's device, and the
system version targeted by your app.