Publishing Android Application

Android application publishing is a process that makes your Android applications available to
users. Infect, publishing is the last phase of the Android application development process.

Android development life cycle

Launching your Android application –

Step1: Regression Testing Before you publish your application, you need to make sure that its
meeting the basic quality expectations for all Android apps, on all of the devices that you are
targeting. So perform all the required testing on different devices including phone and tablets.

Step2: Application Rating When you will publish your application at Google Play, you will
have to specify a content rating for your app, which informs Google Play users of its maturity
level. Currently available ratings are (a) Everyone (b) Low maturity (c) Medium maturity (d)
High maturity.

Step3: Targeted Regions Google Play lets you control what countries and territories where your
application will be sold. Accordingly you must take care of setting up time zone, localization or
any other specific requirement as per the targeted region.

Step4: Application Size Currently, the maximum size for an APK published on Google Play is
50 MB. If your app exceeds that size, or if you want to offer a secondary download, you can use
APK Expansion Files, which Google Play will host for free on its server infrastructure and
automatically handle the download to devices.
Step5: SDK and Screen Compatibility It is important to make sure that your app is designed to
run properly on the Android platform versions and device screen sizes that you want to target.

Step6: Application Pricing Deciding whether you app will be free or paid is important because,
on Google Play, free app's must remain free. If you want to sell your application then you will
have to specify its price in different currencies.

Step7: Promotional Content It is a good marketing practice to supply a variety of high-quality

graphic assets to showcase your app or brand. After you publish, these appear on your product
details page, in store listings and search results, and elsewhere.

Step8: Build and Upload release-ready APK The release-ready APK is what you you will
upload to the Developer Console and distribute to users. You can check complete detail on how
to create a release-ready version of your app: Preparing for Release.

Step9: Finalize Application Detail Google Play gives you a variety of ways to promote your app
and engage with users on your product details page, from colourful graphics, screen shots, and
videos to localized descriptions, release details, and links to your other apps. So you can
decorate your application page and provide as much as clear crisp detail you can provide.

Export Android Application Process

Apk development process

Before export

ting the apps, you must some of tools

 Dx tools(Dalvik executable tools ): It going to convert .class file to .dex file. it has useful
for memory optimization and reduce the boot-up speed time
 AAPT(Android assistance packaging tool):it has useful to convert .Dex file to.Apk
 APK(Android packaging kit): The final stage of deployment process is called as .apk.
Publish an Android app on the Google Play Store

Step 1 – Google Play Console Developer Account.

fill out all the credentials asked while creating the account.
Step 2 – Set-up up a Google Merchant Account.

Step 3 – Create Application

 Click on – Menu > All applications
 Select the ‘Create Application’ option.

the play console will ask you to enter some basic app details. For instance,

 App Name – You must enter a 30-character long name in this field which will be
displayed on the Google Play Console. However, this app name can be changed afterward.
 Default language – Another essential field is the setup of the app language. You can
navigate to the drop-down menu and set a default language for your app.
 App or game – The next step is to define whether you upload an app or a game, but this
can again be revised afterward from the store settings.
 Free or paid – Define whether your app will be available free of cost or will require the
user to pay for it. The free or paid section can be updated from the Paid app page later, but only
until you publish your app. Once the app is live, you cannot transform your app from free to
paid.
Step 4. App Store Listing Details

The Google Play Console will enquire about the following:

 App name – As you have already entered the app name in the previous step, you need not
enter the same name again; however, if you wish to revise the title, this is where you can change
the name.
 Short description – This field requires you to enter an 80-character-long description that
best describes your app.
 Full description – The following field to the short description enables you to explain your
app in detail. You can expand the word limit to 4000 characters and leverage your targeted
keywords to lead Google to share your app with the relevant audience.
Step 5 – Content Rating
Step 6 – Create & Upload Android App to Google Play
Android Fragments

Android Fragment is the part of activity, it is also known as sub-activity. There can be more
than one fragment in an activity. Fragments represent multiple screen inside one activity.

Android fragment lifecycle is affected by activity lifecycle because fragments are included in
activity.

Each fragment has its own life cycle methods that is affected by activity life cycle because
fragments are embedded in activity.

The FragmentManager class is responsible to make interaction between fragment objects.

Android Fragment Lifecycle

The lifecycle of android fragment is like the activity lifecycle. There are 12 lifecycle methods
for fragment.
Android Fragment Lifecycle Methods
1. onAttach(Activity): it is called only once when it is attached with activity.
2. onCreate(Bundle): It is used to initialize the fragment.
 3. onCreateView(LayoutInflater, ViewGroup, Bundle): creates and returns view
hierarchy.
4. onActivityCreated(Bundle): It is invoked after the completion of onCreate()
method.
5. onViewStateRestored(Bundle): It provides information to the fragment that all the
saved state of fragment view hierarchy has been restored.
6. onStart():makes the fragment visible
7. onResume():makes the fragment interactive.
8. onPause():is called when fragment is no longer interactive.
9. onStop():is called when fragment is no longer visible.
10. onDestroyView():allows the fragment to clean up resources.
11. onDestroy():allows the fragment to do final clean up of fragment state.
12. onDetach():It is called immediately prior to the fragment no longer being
associated with its activity.

Intents
An Intent is a messaging object you can use to request an action from another app component.
Although intents facilitate communication between components in several ways, there are three
fundamental use cases:

 Starting an activity
An Activity represents a single screen in an app. You can start a new instance of an Activity by
passing an Intent to startActivity(). The Intent describes the activity to start and carries any
necessary data.
If you want to receive a result from the activity when it finishes, call startActivityForResult().
Your activity receives the result as a separate Intent object in your
activity's onActivityResult() callback.

Starting a service

A Service is a component that performs operations in the background without a user interface.
With Android 5.0 (API level 21) and later, you can start a service with JobScheduler. For
versions earlier than Android 5.0 (API level 21), you can start a service by using methods of
the Service class. You can start a service to perform a one-time operation (such as downloading
a file) by passing an Intent to startService(). The Intent describes the service to start and carries
any necessary data.
If the service is designed with a client-server interface, you can bind to the service from another
component by passing an Intent to bindService()

Delivering a broadcast

A broadcast is a message that any app can receive. The system delivers various broadcasts for
system events, such as when the system boots up or the device starts charging. You can deliver
a broadcast to other apps by passing an Intent to sendBroadcast() or sendOrderedBroadcast()

Intent types

There are two types of intents:

Implicit intents Using implicit Intent, components can’t be specified. An action to be

performed is declared by implicit intent. Then android operating system will filter out
components that will respond to the action.
In the above example, no component is specified, instead, an action is performed i.e. a
webpage is going to be opened. As you type the name of your desired webpage and click on
the ‘CLICK’ button. Your webpage is opened.

Explicit Intent
Using explicit intent any other component can be specified. In other words, the targeted
component is specified by explicit intent. So only the specified target component will be
invoked.

In the above example, There are two activities (FirstActivity, and SecondActivity). When you
click on the ‘GO TO OTHER ACTIVITY’ button in the first activity, then you move to the
second activity. When you click on the ‘GO TO HOME ACTIVITY’ button in the second
activity, then you move to the first activity. This is getting done through Explicit Intent.

Introduction to activities
The Activity class is a crucial component of an Android app, and the way activities are
launched and put together is a fundamental part of the platform's application model. The
mobile-app experience differs from its desktop counterpart in that a user's interaction with the
app doesn't always begin in the same place. The Activity class is designed to facilitate this
paradigm. When one app invokes another, the calling app invokes an activity in the other app,
rather than the app as an atomic whole. In this way, the activity serves as the entry point for an
app's interaction with the user. You implement an activity as a subclass of the Activity class.
An activity provides the window in which the app draws its UI. This window typically fills the
screen, but may be smaller than the screen and float on top of other windows. Generally, one
activity implements one screen in an app. Most apps contain multiple screens, which means
they comprise multiple activities. Typically, one activity in an app is specified as the main
activity, which is the first screen to appear when the user launches the app. Each activity can
then start another activity in order to perform different actions.
Although activities work together to form a cohesive user experience in an app, each activity is
only loosely bound to the other activities; there are usually minimal dependencies among the
activities in an app. In fact, activities often start up activities belonging to other apps. For
example, a browser app might launch the Share activity of a social-media app.
Configuring the manifest: For your app to be able to use activities, you must declare the
activities, and certain of their attributes, in the manifest.

Declare activities: To declare your activity, open your manifest file and add
an <activity> element as a child of the <application> element.

<manifest ... >

<application ... >
<activity android:name=".ExampleActivity" />
...
</application ... >
...
</manifest >
The only required attribute for this element is android:name, which specifies the class name of
the activity. You can also add attributes that define activity characteristics such as label, icon, or
UI theme.

Declare intent filters

Intent filters are a very powerful feature of the Android platform. They provide the ability to
launch an activity based not only on an explicit request, but also an implicit one. You can take
advantage of this feature by declaring an <intent-filter> attribute in the <activity> element. The
definition of this element includes an <action> element and, optionally, a <category> element
and/or a <data> element. These elements combine to specify the type of intent to which your
activity can respond.
<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="text/plain" />
</intent-filter>
</activity>

Declare permissions
You can use the manifest's <activity> tag to control which apps can start a particular activity. A
parent activity cannot launch a child activity unless both activities have the same permissions in
their manifest. If you declare a <uses-permission> element for a parent activity, each child
activity must have a matching <uses-permission> element.

<manifest>
<activity android:name="...."
android:permission=”com.google.socialapp.permission.SHARE_POST”

/>
Then, to be allowed to call SocialApp, your app must match the permission set in SocialApp's
manifest:

<manifest>
<uses-permission android:name="com.google.socialapp.permission.SHARE_POST" />
</manifest>

Managing the activity lifecycle

Over the course of its lifetime, an activity goes through a number of states. You use a series of
callbacks to handle transitions between states. The following sections introduce these callbacks.
onCreate()
You must implement this callback, which fires when the system creates your activity. Your
implementation should initialize the essential components of your activity: Most importantly,
this is where you must call setContentView() to define the layout for the activity's user
interface.

When onCreate() finishes, the next callback is always onStart().

onStart()
As onCreate() exits, the activity enters the Started state, and the activity becomes visible to the
user. This callback contains what amounts to the activity’s final preparations for coming to the
foreground and becoming interactive.

onResume()
The system invokes this callback just before the activity starts interacting with the user. At this
point, the activity is at the top of the activity stack, and captures all user input. Most of an app’s
core functionality is implemented in the onResume() method.

The onPause() callback always follows onResume().

onPause()
The system calls onPause() when the activity loses focus and enters a Paused state. This state
occurs when, for example, the user taps the Back or Recents button. 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 the activity will soon enter
the Stopped or Resumed state.
An activity in the Paused state may continue to update the UI if the user is expecting the UI to
update.
You should not use onPause() to save application or user data, make network calls, or execute
database transactions. Once onPause() finishes executing, the next callback is
either onStop() or onResume(), depending on what happens after the activity enters the Paused
state.

onStop()

The system calls onStop() when the activity is no longer visible to the user. This may happen
because the activity is being destroyed, a new activity is starting, or an existing activity is
entering a Resumed state and is covering the stopped activity. In all of these cases, the stopped
activity is no longer visible at all.

The next callback that the system calls is either onRestart(), if the activity is coming back to
interact with the user, or by onDestroy() if this activity is completely terminating.

onRestart()
The system invokes this callback when an activity in the Stopped state is about to
restart. onRestart() restores the state of the activity from the time that it was stopped.
This callback is always followed by onStart().
onDestroy()
The system invokes this callback before an activity is destroyed.
This callback is the final one that the activity receives. onDestroy() is usually implemented to
ensure that all of an activity’s resources are released when the activity, or the process containing
it, is destroyed.
Activity-lifecycle concepts

Activity state changes:

Different events, some user-triggered and some system-triggered, can cause an Activity to
transition from one state to another.
Configuration change occurs
There are a number of events that can trigger a configuration change. Perhaps the most
prominent example is a change between portrait and landscape orientations. Other cases that
can cause configuration changes include changes to language settings or input device.
When a configuration change occurs, the activity is destroyed and recreated. This triggers the
following callbacks in the original activity instance:
1. onPause()
2. onStop()
3. onDestroy()
A new instance of the activity is created, and the following callbacks are triggered:
1. onCreate()
2. onStart()
3. onResume()
Use a combination of ViewModel instances, the onSaveInstanceState() method, or persistent
local storage to preserve an activity’s UI state across configuration changes. Deciding how to
combine these options depends on the complexity of your UI data, use cases for your app, and
consideration of the speed of retrieval versus memory usage.
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.N
View & description
o

layout_width
1 Specifies the width of the View or
ViewGroup
layout_height
2 Specifies the height of the View or
ViewGroup
layout_marginTop
3 Specifies extra space on the top side of
the View or ViewGroup
layout_marginBottom
4 Specifies extra space on the bottom
side of the View or ViewGroup
layout_marginLeft
5 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
layout_gravity
7 Specifies how child Views are
positioned
layout_weight
8 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.N
Unit & description
o

dp
1 Density-independent pixel. 1 dp is
equivalent to one pixel on a 160 dpi
screen.
sp
2 Scale-independent pixel. This is similar
to dp and is recommended for
specifying font sizes
pt
3 Point. A point is defined to be 1/72 of
an inch, based on the physical screen
size.
px
4 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
Notifications overview: A notification is a message that Android displays outside your app's
UI to provide the user with reminders, communication from other people, or other timely
information from your app. Users can tap the notification to open your app or take an action
directly from the notification.

Appearances on a device
Notifications automatically appear to users in different locations and formats. A notification
appears as an icon in the status bar, a more detailed entry in the notification drawer, and a badge
on the app's icon. Notifications also appear on paired wearables.
Status bar and notification drawer
When you issue a notification, it first appears as an icon in the status bar.

Figure 1. Notification icons appear on the left side of the status bar.
Users can swipe down on the status bar to open the notification drawer, where they can view
more details and take actions with the notification.

Users can swipe down on the status bar to open the notification drawer, where they can view
more details and take actions with the notification.
Figure 2. Notifications in the notification drawer.
Users can drag down on a notification in the drawer to reveal the expanded view, which shows
additional content and action buttons, if provided. Starting in Android 13, this expanded view
includes a button that lets users stop an app that has ongoing foreground services.
A notification remains visible in the notification drawer until it's dismissed by the app or user.
Heads-up notification
Beginning with Android 5.0, notifications can briefly appear in a floating window called
a heads-up notification. This behavior is normally for important notifications that the user needs
to know about immediately, and it only appears if the device is unlocked.

Figure 3. A heads-up notification appears in front of the foreground app.

The heads-up notification appears when your app issues the notification. It disappears after a
moment, but it remains visible in the notification drawer as usual.
Conditions that might trigger heads-up notifications include the following:
 The user's activity is in fullscreen mode, such as when the app uses fullScreenIntent.
 The notification has high priority and uses ringtones or vibrations on devices running
Android 7.1 (API level 25) and lower.
 The notification channel has high importance on devices running Android 8.0 (API level
26) and higher.
Lock screen
Beginning with Android 5.0, notifications can appear on the lock screen.
You can programmatically set whether notifications posted by your app show on a secure lock
screen and, if so, the level of detail visible.
Users can use the system settings to choose the level of detail visible in lock screen notifications
or to disable all lock screen notifications. Starting with Android 8.0, users can disable or enable
lock screen notifications for each notification channel.

Figure 4. Notifications+ on the lock screen with sensitive content hidden.

App icon badge
In supported launchers on devices running Android 8.0 (API level 26) and higher, app icons
indicate new notifications with a colored badge known as a notification dot on the
corresponding app launcher icon.
Users can touch & hold an app icon to see the notifications for that app. Users can dismiss or
act on notifications from that menu, similar to the notification drawer.

Figure 5. Notification badges and the touch & hold menu.

Wear OS devices

If the user has a paired Wear OS device, all your notifications appear there automatically,
including expandable detail and action buttons.

You can enhance the experience by customizing the appearance of your notifications on
wearables and by providing different actions, including suggested replies and voice input
replies.

Notifications automatically appear on a paired Wear OS device.

Notification anatomy

The design of a notification is determined by system templates, and your app defines the
contents for each portion of the template. Some details of the notification appear only in the
expanded view.

Figure 7. A notification with basic details.

The most common parts of a notification are indicated in figure 7, as follows:

 1. Small icon: required; set using setSmallIcon().
2. App name: provided by the system.
3. Time stamp: provided by the system, but you can override it using setWhen() or hide it
using setShowWhen(false).
4. Large icon: optional; usually used only for contact photos. Don't use it for your app icon.
Set using setLargeIcon().
5. Title: optional; set using setContentTitle().
6. Text: optional; set using setContentText().

We strongly recommend using system templates for proper design compatibility on all devices.
If necessary, you can create a custom notification layout.

For more information about how to create a notification with these features and more,
read Create a notification.

Notification actions

Although it's not required, it's a good practice for every notification to open an appropriate app
activity when it's tapped. In addition to this default notification action, you can add action
buttons that complete an app-related task from the notification—often without opening an
activity—as shown in figure 8.

Figure 8. A notification with action buttons.

Starting in Android 7.0 (API level 24), you can add an action to reply to messages or enter other
text directly from the notification.

Starting in Android 10 (API level 29), the platform can automatically generate action buttons
with suggested intent-based actions.