Minor Project Report

On

“A new era of Android Application Development”

Submitted in partial fulfilment of the requirement
For the award of the degree of

Bachelor of Technology
In
Computer Science
Submitted by
Sloka Roy Devesh Kumar Pankaj Tomar Shresth Tyagi
(60196202714) (00196207215) (00296207215) (05996202714)

Under the guidance of

Ms. Ruchikaa Nayyar

Assistant Professor

DEPARTMENT OF COMPUTER SCIENCE

NORTHERN INDIA ENGINEERING COLLEGE
Shastri Park, Delhi – 110053
 Candidate’s Declaration

It is hereby certified that the work which is being presented in the B. Tech Minor Project Report
entitled "A NEW ERA OF ANDROID APPLICATION DEVOLOPMENT" in partial
fulfilment of the requirements for the award of the degree of Bachelor of Technology and
submitted in the Department of Computer Science & Engineering of Northern India
Engineering College, New Delhi (Affiliated to Guru Gobind Singh Indraprastha University,
Delhi) is an authentic record of our own work carried out during a period from August 2017 to
November 2017 under the guidance of Ms. Ruchikaa Nayyar, Assistant Professor.

The matter presented in the B. Tech Minor Project Report has not been submitted by us for the
award of any other degree of this or any other Institute.

Sloka Roy Devesh Kumar Pankaj Tomar Shresth Tyagi

60196202714 00196207215 00296207215 0599602714

This is to certify that the above statement made by the candidate is correct to the best of our
knowledge. They are permitted to appear in the External Minor Project Examination.

Ms. Ruchikaa Nayyar Dr. Anupam Kumar Sharma Dr. Saurabh Gupta
Assistant Professor Project Co - Ordinator Head, CSE Department
 Abstract

When we think about Android development, chances are one programming language immediately
springs to mind Java. While it’s true that the majority of Android apps are written in Java, when
it comes to Android development, Java isn’t your only option. May 17, 2017 @ Google I/O2017
Conference, Kotlin was picked up as the official programming language for android development.
Kotlin being the modern programming language has certainly an edge over Java but there are still
some questions and doubts revolving around the developer forums. one JVM-compatible
programming language that’s really caught the attention of the Android community is Kotlin, a
statically typed programming language from Jet Brains. One of Kotlin’s greatest strengths as a
potential alternative to Java is the sheer level of interoperability between Java and Kotlin, you can
even have Java and Kotlin code existing side by side in the same project and everything will still
compile perfectly The adoption of Kotlin for android development is still low in Asian countries.
Through this project we will be showing developers the difference between applications developed
in Kotlin and in Java by developing a similar application in both and with the help of Android
Profiler, we will be analysing both apps in terms of CPU, MEMORY and NETWORK Usage.
 Acknowledgement

We express our deep gratitude to Ms. Ruchikaa Nayyar, Assistant Professor. Department of
Computer Science & Engineering for his valuable guidance and suggestion throughout my project
work. We are thankful to Dr. Anupam Kumar Sharma, Project Co-Ordinator for their valuable
guidance.

We would like to extend my sincere thanks to Dr. Saurabh Gupta, Head of the Department,
CSE for his time to time suggestions and inspirations to complete my project work. We are also
very thankful to Prof. (Dr.) G. P. Govil, Director for providing me the facilities to carry out
my project work.

Sloka Roy Devesh Kumar Pankaj Tomar Shresth Tyagi

60196202714 00196207215 00296207215 0599602714
 List of Figures

Figure 1 - Android Profiler Shared Timeline View

Figure 2 - Android CPU Profiler
Figure 3 - Android Memory Profiler
Figure 4 - The memory count at the top of the Memory Profiler
Figure 5 - Android Network Profiler
Figure 6 - Common/UI Output (Splash Screen Application)
Figure 7 - Android Profiler Shared Timeline View (Java – Splash Screen Application)
Figure 8 - Android Profiler Shared Timeline View (Kotlin - Splash Screen Application)
Figure 9 - Common/UI Output (Option Menu Application)
Figure 10 - Android Profiler Shared Timeline View (Java – Option Menu Application)
Figure 11 - Android Profiler Shared Timeline View (Kotlin – Option Menu Application)
Figure 12 - Common/UI Output (Web View Application)
Figure 13 - Android Profiler Shared Timeline View (Java - Web View Application)
Figure 14 - Android Profiler Shared Timeline View (Kotlin - Web View Application)
Figure 15 - Common/UI Output (Earthquake Application)
Figure 16 - Android Profiler Shared Timeline View (Java - Earthquake Application)
Figure 17 - Android Profiler Shared Timeline View (Kotlin - Earthquake Application)
Figure 18 - CPU Profiler (Java - Earthquake Application at T = 5.97 Sec, 15.2 Sec, 27.7 Sec)
Figure 19 - Memory Profiler (Java - Earthquake Application at T = 5.97 Sec, 15.2 Sec, 27.7 Sec)
Figure 20 - Network Profiler (Java - Earthquake Application at T = 5.97 Sec, 15.2 Sec, 27.7 Sec)
Figure 21 - CPU Profiler (Kotlin - Earthquake Application at T = 5.3 Sec, 17.93 Sec, 30.5 Sec)
Figure 22 - Memory Profiler (Kotlin - Earthquake Application at T = 5.3 Sec, 17.93 Sec, 30.5 Sec)
Figure 23 - Network Profiler (Kotlin - Earthquake Application at T = 5.3 Sec, 17.93 Sec, 30.5 Sec)
 List of Tables

Table 1 - Application Analysis (Splash Screen Application)

Table 2 - Application Analysis (Option Menu Application)
Table 3 - Application Analysis (Web View Application)
Table 4 - Application Analysis (Earthquake Application)
 Table of Contents

Candidate Declaration I
Abstract II
Acknowledgement III

List of Figures IV
V
List of Tables
Chapter 1: Introduction
1.1 - Android OS 6
1.2 - Application Development in Android 7
1.3 - Android software development using Java 7
1.3.1 - Android SDK 8
1.4 - Kotlin 9
1.4.1 - History 9
1.4.2 - Why Kotlin? 9
1.4.3 - About our Project 10

Chapter 2: Technology Used 11

2.1 - Android Studio Canary 3.0 Beta
2.2 - Android Profiler 12
15
2.2.1 - Shared Timeline View
15
2.2.2 - CPU Profiler
17
2.2.3 - Memory Profiler
19
2.2.4 - Network Profiler 22
Chapter 3: Application Analysis
24
3.1 - Earthquake Application
3.1.1 - Splash Screen 25
3.1.2 - Option Menu 28
3.1.3 - Web View 31

Chapter 4: Result
43
Chapter 5: Conclusion
44
Chapter 6: Future Scope 45
Chapter 7: References 46
 Chapter - 1
Introduction

1.1 - Android (Operating System)

Android is a mobile operating system developed by Google, based on the Linux

kernel and designed primarily for touchscreen mobile devices such
as smartphones and tablets. Android's user interface is mainly based on direct
manipulation, using touch gestures that loosely correspond to real-world actions,
such as swiping, tapping and pinching, to manipulate on-screen objects, along with
a virtual keyboard for text input. In addition to touchscreen devices, Google has
further developed Android TV for televisions, Android Auto for cars and Android
Wear for wrist watches, each with a specialized user interface. Variants of Android
are also used on game consoles, digital cameras, PCs and other electronics.

Initially developed by Android Inc., which Google bought in 2005, Android was unveiled in 2007,
along with the founding of the Open Handset Alliance – a consortium of hardware, software, and
telecommunication companies devoted to advancing open standards for mobile devices.
Beginning with the first commercial Android device in September 2008, the operating system has
gone through multiple major releases, with the current version being 8.0 "Oreo", released in
August 2017. Android applications ‘apps’ can be downloaded from the Google Play store, which
features over 2.7 million apps as of February 2017. Android has been the best-selling OS on tablets
since 2013, and runs on the vast majority of smartphones. As of May 2017, Android has two billion
monthly active users, and it has the largest installed base of any operating system.

Android’s source code is released by Google under an open source license, although most Android
devices ultimately ship with a combination of free and open source and proprietary software,
including proprietary software required for accessing Google services. Android is popular with
technology companies that require a ready-made, low-cost and customizable operating system
for high-tech devices. Its open nature has encouraged a large community of developers and
enthusiasts to use the open-source code as a foundation for community-driven projects, which
deliver updates to older devices, add new features for advanced users or bring Android to devices
originally shipped with other operating systems. The extensive variation of hardware in Android
devices causes significant delays for software upgrades, with new versions of the operating system
and security patches typically taking months before reaching consumers, or sometimes not at all.
The success of Android has made it a target for patent and copyright litigation between technology
companies.
1.2 - Application Development in Android

Android provides a rich application framework that allows you to build innovative
apps and games for mobile devices in a Java language environment. The documents
listed in the left navigation provide details about how to build apps using Android's
various APIs.

 Apps provide multiple entry points

Android apps are built as a combination of distinct components that can be invoked
individually. For instance, an individual activity provides a single screen for a user interface,
and a service independently performs work in the background. From one component you can
start another component using an intent. You can even start a component in a different app,
such as an activity in a maps app to show an address. This model provides multiple entry points
for a single app and allows any app to behave as a user's "default" for an action that other apps
may invoke.

 Apps adapts to different devices

Android provides an adaptive app framework that allows you to provide unique resources for
different device configurations. For example, you can create different XML layout files for
different screen sizes and the system determines which layout to apply based on the current
device's screen size. You can query the availability of device features at runtime if any app
features require specific hardware such as a camera. If necessary, you can also declare features
your app requires so app markets such as Google Play Store do not allow installation on devices
that do not support that feature.

1.3 - Android Software Development using Java

Android software development is the process by which new applications are created for devices
running the Android operating system. Applications are usually developed in Java programming
language using the Android software development kit (SDK), but other development
environments are also available, some such as Kotlin support the exact same Android APIs (and
bytecode), while others such as Go have restricted API access. All Java 7 language features are
supported, and some Java 8 language features (and additionally some Java 9 code has
been backported to work).
1.3.1 - Android SDK

The Android software development kit (SDK) includes a comprehensive set of development
tools. These include a debugger, libraries, a handset emulator based on QEMU, documentation,
sample code, and tutorials. Currently supported development platforms include computers
running Linux (any modern desktop Linux distribution), Mac OS X 10.5.8 or later, and Windows
7 or later. As of March 2015, the SDK is not available on Android itself, but software development
is possible by using specialized Android applications.

Until around the end of 2014, the officially supported integrated development environment (IDE)
was Eclipse using the Android Development Tools (ADT) Plugin, though IntelliJ IDEA IDE (all
editions) fully supports Android development out of the box and NetBeans IDE also supports
Android development via a plugin. As of 2015, Android Studio, made by Google and powered by
IntelliJ, is the official IDE; however, developers are free to use others, but Google made it clear
that ADT was officially deprecated since the end of 2015 to focus on Android Studio as the official
Android IDE. Additionally, developers may use any text editor to edit Java and XML files, then
use command line tools (Java Development Kit and Apache Ant are required) to create, build and
debug Android applications as well as control attached Android devices (e.g., triggering a reboot,
installing software package(s) remotely).

Enhancements to Android's SDK go hand in hand with the overall Android platform development.
The SDK also supports older versions of the Android platform in case developers wish to target
their applications at older devices. Development tools are downloadable components, so after one
has downloaded the latest version and platform, older platforms and tools can also be downloaded
for compatibility testing.
1.4 - Kotlin
Kotlin is a statically-typed programming language that runs on the Java
virtual machine and also can be compiled to JavaScript source code or
uses the LLVM compiler infrastructure. Its primary development is from
a team of Jet Brains programmers based in Saint Petersburg, Russia.
While the syntax is not compatible with Java, Kotlin is designed to
interoperate with Java code and is reliant on Java code from the
existing Java Class Library, such as the framework. The name comes
from Kotlin Island, near St. Petersburg. Andrey Breslav mentioned that
the team decided to name it after an island just like Java was named after the Indonesian island
of Java. Kotlin is being promoted by Google for Android. Therefore, at Google I/O 2017 it was
declared as one of the official programming languages to develop Android applications along with
JAVA and C++.

1.4.1 - History
In July 2011 Jet Brains unveiled Project Kotlin, a new language for the JVM, which had been
under development for a year. Jet Brains lead Dmitry Jemerov said that most languages did not
have the features they were looking for, with the exception of Scala. However, he cited the slow
compile time of Scala as an obvious deficiency. One of the stated goals of Kotlin is to compile as
quickly as Java. In February 2012, Jet Brains open sourced the project under the Apache 2 license.
Jet Brains hopes that the new language will drive IntelliJ IDEA sales.

Kotlin v1.0 was released on February 15, 2016. This is considered to be the first officially stable
release and Jet Brains has committed to long-term backwards compatibility starting with this
version. At Google I/O 2017, Google announced first-class support for Kotlin on Android.

1.4.2 - Why Kotlin?

Kotlin is a great fit for developing Android applications, Jet Brains lead
Dmitry Jemerov said that most languages did not have the features they
were looking for, with the exception of Scala, bringing all of the
advantages of a modern language to the Android platform without
introducing any new restrictions -

 Compatibility - Kotlin is fully compatible with JDK 6, ensuring that Kotlin applications can
run on older Android devices with no issues. The Kotlin tooling is fully supported in Android
Studio and compatible with the Android build system.
 Performance - A Kotlin application runs as fast as an equivalent Java one, thanks to very
similar bytecode structure. With Kotlin's support for inline functions, code using lambdas
often runs even faster than the same code written in Java.

 Interoperability - Kotlin is 100% interoperable with Java, allowing to use all existing
Android libraries in a Kotlin application. Processing, so databinding and Dagger work too.

 Footprint - Kotlin has a very compact runtime library, which can be further reduced through
the use of ProGuard. In a real application, the Kotlin runtime adds only a few hundred
methods and less than 100K to the size of the. apk file.

 Compilation Time - Kotlin supports efficient incremental compilation, so while there's some
additional overhead for clean builds, incremental builds are fast or faster than with Java.

 Learning Curve - For a Java developer, getting started with Kotlin is very easy. The
automated Java to Kotlin converter included in the Kotlin plugin helps with the first
steps. Kotlin Koans offer a key feature of the language with a series of interactive exercises.

 Safe - Kotlin's type system is aimed at eliminating the danger of null references from code,
also known as “The Billion Dollar Mistake”. One of the most common pitfalls in many
programming languages, including Java, is that of accessing a member of a null reference,
resulting in a null reference exception.

1.4.3 - About our Project

We are making an android application using Kotlin as well as JAVA. We trying to differentiate
both the application on many criteria at same platform and device. The criteria as follows –

 Efficiency
 Optimization
 Security
 Lightweight
 Developer Friendly
 User Friendly
 Chapter - 2

Technology Used

When you are building apps for Android, you need the following essential tools.

Required –
Besides the PC, everything is free:

 Development computer
Any PC will do, since the development environment is Java. Faster is better, of course. The
Android SDK comes bundled with emulation capabilities so you can create virtual Android
devices on your PC, but they run extremely slowly.

 Java Development Kit (JDK)

 An integrated development environment (IDE)

 Android SDK

Recommended –
 At least one Android device.

Google continues to make improvements to the emulator, but there really is no comparison in
testing between an emulated device and a real one:

1. You will save time waiting for the emulator to start up.

2. Testing your application is very different from testing it on an actual device.

2.1 - Android Studio Canary 3.0 beta 7
Android Studio is the official integrated development environment (IDE) for Google’s Android
operating system, built on Jet Brains’ IDEA software and designed especially for Android
development. It is a replacement for the Eclipse Android Development Tools (ADT) as primary
IDE for native Android application development.
Android Studio was announced on May 16, 2013 at the Google I/O conference.
It was in early access preview stage starting from version 0.1 in May 2013, then
entered beta stage starting from version 0.8 which was released in June
2014. The first stable build was released in December 2014, starting from
version 1.0. The current stable version is 2.3.3, released in June 2017. Next
major update, version 3.0, is in preview stage as of September 2017. Which is
an Android Studio Canary 3.0 Beta 7.

2.1.1 - Features
New features are expected to be rolled out with each release of Android Studio. The following
features are provided in the current stable version:

 Gradle-based build support.

 Android-specific refactoring and quick fixes.
 Lint tools to catch performance, usability, version compatibility and other problems.
 ProGuard integration and app-signing capabilities.
 Template-based wizards to create common Android designs and components.
 A rich layout editor that allows users to drag-and-drop UI components, option to preview
layouts on multiple screen configurations.
 Support for building Android Wear apps.
 Built-in support for Google Cloud Platform, enabling integration with Firebase Cloud
Messaging (Earlier 'Google Cloud Messaging') and Google App Engine.
 Android Virtual Device (Emulator) to run and debug apps in the Android studio.

Android Studio's is official IDE, purpose-built for Android. The feature set in Android Studio is
focused on accelerating the application development flow and providing the latest tools built for.
To accelerate the development flow, Android Studio 3.0 includes three major features:

1. A new suite of application performance profiling tools to quickly diagnose performance

related issues.
2. Support for the Kotlin programming language.
3. Increased Gradle build speeds for large sized app projects.

Android Studio 3.0 also tightly integrates with Android platform development and with these
additional key features: support for Instant App development, inclusion of the Google Play Store
in the Android O emulator system images, and new wizards for Android O development. The main
key features of the latest android Studio from the developer point of view are listed below –

1. Kotlin Programming Language - Android Studio 3.0 now includes support for Kotlin.
With this new language support, we can seamlessly add Kotlin code next to your existing
Android app code and have access to all the great development tools found in Android
Studio.

2. Java 8 Language features - With the recent deprecation of the Jack toolchain and
migration to the javac based toolchain, we have access to features such as Instant Run for
projects using the Java 8 language features in Android Studio. To update your project to
support the new Java 8 Language toolchain, simply update your Source and Target
compatibility levels to 1.8 in the Project Structure dialog.

3. Android Things Support - With Android Studio 3.0, you can start developing on Android
Things with a new set of templates in the New Project wizard and the New Module wizard.
Android Things allows you to extend your Android development knowledge into the
Internet of Things (IoT) device category.

4. Google's Maven Repository - Android Support Library maven dependencies outside of

the Android SDK Manager in a brand-new Maven repository. For those developing with a
Continuous Integration (CI) system, this should make Maven dependency management
easier. Used in combination with the latest command line SDK Manager tool and Gradle,
CI builds should be easier to manage with Google's Maven Repository. To use the new
Maven location, add the following URL to your app module's build.gradle file.

5. App Bug Reporter in Android Emulator - To help in documenting bugs in an app, we

have an easier way to generate a bug report with all the necessary configuration settings
and space to capture your steps. Additionally, if we want to share a specific emulator bug
with the Android team, there is a link added to quickly generate a bug on the Android Issue
Tracker.

6. APK Debugging - For those of you who just want to debug an APK without building a
project in Android Studio, the Android Studio 3.0 release now has the ability to debug an
arbitrary APK. This functionally is especially helpful for those who develop their Android
C++ code in another development environment, but want to debug and analyse the APK in
the context of Android Studio. As long as we have a debugged version of our APK, we can
use the new APK Debugging features to analyse, profile & debug the APK. Moreover, if
you have access to the sources of your APK, you can link the source to the APK debugging
flow for a higher fidelity debugging process.
The latest preview version is Android Studio 3.1. The list of the new features of Android Studio
3.1 explained below –

1. New DEX compiler

 By default, Android Studio 3.1 Canary 1 and higher use a new DEX compiler called
D8, which was announced on the Android Developers Blog.

 DEX compilation is the process of transforming .class bytecode into .dex bytecode
for the Android Runtime (or Dalvik, for older versions of Android). Compared to
the current compiler, called DX, D8 compiles faster and outputs smaller DEX files,
all while having the same or better app runtime performance.
 D8 shouldn't change your day-to-day app development workflow. We can
temporarily disable D8 and use DX by including the following in your project’s
gradle.properties file.

2. Sample native processes with CPU Profiler

 The CPU Profiler now includes a default configuration to record sampled traces of
your app's native threads. We can use this configuration by deploying your app to
a device running Android 8.0 (API level 26) or higher and then selecting Sampled
(Native) from the CPU profiler's recording configurations dropdown menu. After
that, record and inspect a trace as we normally would.

 We can also change the default settings, such as the sampling interval, by creating
a recording configuration. To switch back to tracing our Java threads, select either
a Sampled (Java) or Instrumented (Java) configuration.
2.2 - Android Profiler

The new Android Profiler window in Android Studio 3.0 replaces the Android
Monitor tools. These new profiling tools provide real time data for our app's
CPU, memory, and network activity. We can perform sample-based method
tracing to time your code execution, capture heap dumps, view memory
allocations, and inspect the details of network-transmitted files. Android Studio
3.0 includes a brand-new suite of tools to help debug in your app.

They completely rewrote the previous set of Android Monitor tools, and replaced them with the
Android Profiler. Once you deploy your app to a running device or emulator, click on the Android
Profiler tab and you will now have access to a real-time & unified view of the CPU, Memory, &
Network activity for your app. Each of the performance events are mapped to the UI event timeline
which highlights touch events, key presses, and activity changes so that you have more context on
when and why a certain event happened. Click on each timeline to dig into each performance
aspect of your app.

2.2.1 - Android Profiler – Shared Timeline View

This shared timeline view only shows the timeline graphs. To access the detailed profiling tools,
click the graph that corresponds to the performance data you want to inspect. In this shared
timeline view you can inspect different activities explained below –

 Inspect CPU Activity and Method Traces with CPU Profiler

 Inspect the Java Heap and Memory Allocations with Memory Profiler
 Inspect Network Traffic with Network Profiler

Procedure to use Android Profiler – Shared Timeline View

1. Click View > Tool Windows > Android Profiler (you can also click Android Profiler in the
toolbar).
2. As you can see in Figure 1 (Shared Timeline View), at the top of the Android
Profiler window, as shown in above figure, select the device ❶ and the app process ❷ you
want to profile. If you've connected a device over USB but don't see it listed, ensure that you
have enabled USB debugging.
 Figure 1 – Android Profile – Shared Timeline View

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 now displays a shared timeline view. which includes a timeline with real-time
graphs for CPU, memory, and network usage. The window also includes timeline zoom controls
❸, a button to jump forward to the Realtime updates ❹, and an event timeline that shows activity
states, user input events, and screen rotation events ❺.
Once you start Android Profiler, it continues to collect profiling data until you either disconnect
the device or click Close.
2.2.2 - CPU Profiler
The CPU profiler helps you inspect your app’s CPU usage and thread activity in real-time, and
record method traces, so you can optimize and debug your app’s code. Minimizing your app’s
CPU usage has many advantages—such as providing a faster and smoother user experience, and
preserving device battery life. It also helps your app perform well on a variety of newer and older
devices. You can use the CPU profiler to monitor CPU usage and thread activity while interacting
with your app. However, for more detailed information about how your app executes its code, you
should record and inspect method traces.
For each thread in your app process, you can find out which methods are executed over a period
of time and the CPU resources each method consumes during its execution. You can also use
method traces to identify callers and callees. A caller is a method that invokes another method,
and a callee is one that is invoked by another method. You can use this information to determine
which methods are responsible for invoking particular resource-heavy tasks too often and try to
optimize your app’s code to avoid unnecessary work.

Figure 2 – CPU Profiler

Procedure to use CPU Profilers

Here you can see in Figure 2 (CPU Profiler), The menus are numbered and explained below -

❶ Event timeline - Shows the activities in your app as they transition through different states in
their lifecycle, and indicates user interactions with the device, including screen rotation events.
To learn more about the event timeline, including how to enable it, read Enable advanced
profiling.
❷ CPU Timeline - Shows real-time CPU usage of your app as a percentage of total available
CPU time and the total number of threads your app is using. The timeline also shows the CPU
usage of other processes (such as system processes or other apps), so you can compare it to
your app’s usage. You can inspect historical CPU usage data by moving your mouse along the
horizontal axis of the timeline.

❸ Thread activity timeline - Lists each thread that belongs to your app process and indicates
their activity along a timeline using the colors listed below. After you record a method trace,
you can select a thread from this timeline to inspect its data in the trace pane.

 Green - The thread is active or is ready to use the CPU. That is, it's in a 'running' or
'runnable' state.

 Yellow - The thread is active, but it’s waiting on an I/O operation, such as disk or
network I/O, before it can complete its work.

 Gray - The thread is sleeping and is not consuming any CPU time. This sometimes
occurs when the thread requires access to a resource that is not yet available. Either
the thread goes into voluntary sleep, or the kernel puts the thread to sleep until the
required resource becomes available.

❹ Recording configurations - Allows you to select one of the following options to determine
how the profiler records a method trace.

 Sampled - A default configuration that captures your app’s call stack at frequent
intervals during your app’s execution. The profiler compares sets of captured data to
derive timing and resource usage information about your app’s code execution. An
inherent issue of sampled-based tracing is that if your app enters a method after a
capture of the call stack and exits the method before the next capture, that method
call is not logged by the profiler.

 Instrumented - A default configuration that instruments your app at runtime to

record a timestamp at the beginning and end of each method call. Timestamps are
collected and compared to generate method tracing data, including timing
information and CPU usage. Additionally, if your app executes a large number of
methods in short amount of time, the profiler may quickly exceed its file size limit
and not be able to record any further tracing data.

 Edit configurations - Allows you to change certain defaults of the sampled and
instrumented recording configurations described above, and save them as a custom
configuration.
❺ Record button - Starts and stops recording a method trace. To learn more, go to the section
about recording and inspecting method traces.

2.2.3 - Memory Profiler

The Memory Profiler is a component in the Android Profiler that helps you identify memory leaks
and memory churn that can lead to stutter, freezes, and even app crashes. It shows a real-time graph
of your app's memory use, lets you capture a heap dump, force garbage collections, and track
memory allocations.
Android provides a managed memory environment when it determines that your app is no longer
using some objects, the garbage collector releases the unused memory back to the heap. How
Android goes about finding unused memory is constantly being improved, but at some point, on
all Android versions, the system must briefly pause your code. Most of the time, the pauses are
imperceivably. However, if your app allocates memory faster than the system can collect it, your
app might be delayed while the collector frees enough memory to satisfy your allocations. The
delay could cause your app to skip frames and cause visible slowness.
To help prevent these problems, you should use the Memory Profiler to do the following:
 Look for undesirable memory allocation patterns in the timeline that might be causing
performance problems.
 Dump the Java heap to see which objects are using up memory at any given time. Several heap
dumps over an extended period of time can help identify memory leaks.
 Record memory allocations during normal and extreme user interaction to identify exactly
where your code is either allocating too many objects in a short time or allocating objects that
become leaked.

Procedure to use Memory Profiler

As indicated in above Figure 3 (Memory Profiler), the default view for the Memory Profiler
includes the following:

❶ A button to force a garbage collection event.

❷ A button to capture a heap dump.

❸ A button to record memory allocations. This button appears only when connected to a device
running Android 7.1 or lower.

❹ Buttons to zoom in/out of the timeline.

❺ A button to jump forward to the live memory data.

❻ The event timeline, which shows the activity states, user input events, and screen rotation
events.

❼ The memory use timeline, which includes the following:

Figure 3 - Memory Profiler

 A stacked graph of how much memory is being used by each memory category, as indicated
by the y-axis on the left and the colors key at the top.

 A dashed line indicates the number of allocated objects, as indicated by the y-axis on the
right.

 An icon for each garbage collection event.

However, if you're using a device running Android 7.1 or lower, not all profiling data is visible by
default. If you see a message that says, "Advanced profiling is unavailable for the selected
process," you need to enable advanced profiling to see the following:
 Event timeline
 Number of allocated objects
 Garbage collection events
How Memory is counted?
The numbers you see at the top of the Memory Profiler are based on all the private memory pages
that your app has committed, according to the Android system. This count does not include pages
shared with the system or other apps.

Figure 4 - The memory count at the top of the Memory Profiler

The categories in the memory count in Figure 4 are as follows:

 Java - Memory from objects allocated from Java or Kotlin code.
 Native - Memory from objects allocated from C or C++ code.
Even if you're not using C++ in your app, you might see some native memory used here because
the Android framework uses native memory to handle various tasks on your behalf, such as
when handling image assets and other graphics—even though the code you've written is in Java
or Kotlin.

 Graphics - Memory used for graphics buffer queues to display pixels to the screen, including
GL surfaces, GL textures, and so on. (Note that this is memory shared with the CPU, not
dedicated GPU memory.)
 Stack - Memory used by both native and Java stacks in your app. This usually relates to how
many threads your app is running.
 Code - Memory that your app uses for code and resources, such as dex bytecode, optimized or
compiled dex code, so libraries, and fonts.
 Other - Memory used by your app that the system isn't sure how to categorize.
 Allocated - The number of Java/Kotlin objects allocated by your app. This does not count
objects allocated in C or C++.

When connected to a device running Android 7.1 and lower, this allocation count starts only at the
time the Memory Profiler connected to your running app. So, any objects allocated before you start
profiling are not accounted for. However, Android 8.0 includes an on-device profiling tool that
keeps track of all allocations, so this number always represents the total number of Java objects
outstanding in your app on Android 8.0 and higher.
2.2.4 - Network Profiler
The Network Profiler displays real-time network activity on a timeline, showing data sent and
received, as well as the current number of connections. This lets you examine how and when your
app transfers data, and optimize the underlying code appropriately.
When your app makes a request to the network, the device must use the power-hungry mobile or
WIFI radios to send and receive packets. The radios not only use power to transfer data, but also
use extra power to turn on and to stay awake.
Using the Network Profiler, you can look for frequent, short spikes of network activity, which
mean that your app requires the radios to turn on frequently, or to stay awake for long periods to
handle many short requests close together. This pattern indicates that you may be able to optimize
your app for improved battery performance by batching network requests, thereby reducing the
number of times the radios must turn on to send or receive data. This also allows the radios to
switch into low-power mode to save battery in the longer gaps between batched requests.

Figure 5 – Network Profiler

Procedure to use Network Profiler
To open the Network Profiler, follow these steps –
1. Click View > Tool Windows > Android Profiler (you can also click Android Profiler in the
toolbar).
2. Select the device and app process you want to profile from the Android Profiler toolbar. If
you've connected a device over USB but don't see it listed, ensure that you have enabled USB
debugging.
3. Click anywhere in the Network timeline to open the Network Profiler.
At the top of the window of Figure 5 (Network Profiler), you can see the event timeline and
❶ radio power state (high/low) vs Wi-Fi. On the timeline, you can ❷ click and drag to select a
portion of the timeline to inspect the traffic. The ❸ windows below then show files sent and
received during the selected portion of the timeline, including file name, size, type, status, and
time. You can sort this list by clicking any of the column headers. You also see a detailed
breakdown of the selected portion of the timeline, showing when each file was sent or received.
Click a connection's name to view ❹ detailed information about a selected file sent or received.
Click the tabs to view the response data, header information, or the call stack.
 Chapter - 3

Application Analysis

In this section, we are going to analysis patterns of both Java and Kotlin application in terms of
CPU, Memory and Network Usage. In CPU Usage, Live application consuming CPU per second.
In Memory, we are going to compare the Memory Usage while running the live application and in
terms of network, the possibility is going to be mapped. We are also going to conclude the Lines
of Code of the application in both Java and Kotlin and also Application Sizes will be computed.

3.1 - Earthquake Application

Live application which uses network calls to fetch the data from the webserver and displays it in
the mobile app are more common these days. Form shopping cart applications like Flipkart,
Amazon to gaming applications like Clash of Clans uses networking. With the help of earthquake
app, we will compare Kotlin and Java applications on the basis of effectiveness of using network
calls.
Earthquake application displays about all the earthquakes occurred in the subcontinent or within
the range of India’s Latitude and Longitude. It displays magnitude of the earthquake, location of
the epicenter, time, date. It can show upto 100 results at a time, starting from 1st of January 2017.
As an additional feature, the user of the application can set the minimum magnitude according to
his desire, also he can sort the results on the basis of magnitude/most recent.
The application uses network calls and fetches data form the USGS (United states geological
survey) website. Realtime Data on the USGS website is created by the satellite of America. We
are parsing geoJSON data which is an extension of JSON (JavaScript object notation) in the
application. Of most of all, with the help of this application we will be able to see the Networking
Capabilities of Kotlin and Java and compare them on the basis of parameters defined by us.
Earthquake application consists of 4 major components –
1. Splash Screen
2. Option Menu
3. Networking
4. Web Browser

For achieving our goal i.e. Comparing the networking capabilities of the whole app, it’s important
to visualize and analyze each component individually. In the below sub section, we will be looking
at detailed overview and analysis of these components –
3.1.1 - Splash Screen
A splash screen is a graphical control element consisting of a window containing an image, a logo,
and the current version of the software. A splash screen usually appears while a game or program
is launching. A splash page is an introduction page on a website. A splash screen may cover the
entire screen or web page; or may simply be a rectangle near the centre of the screen or page. The
splash screens of operating systems and some applications that expect to be run in full screen
usually cover the entire screen. Splash screens are typically used by particularly large applications
to notify the user that the program is in the process of loading. They provide feedback that a lengthy
process is underway. Occasionally, applications a progress bar within the splash screen indicates
the loading progress. A splash screen disappears when the application's main window appears.
Splash screens applications typically serve to enhance the look and feel of an application or web
site, hence applications are often visually appealing. They may also have animations, graphics,
and sound.

Figure 6 – Common/UI Output (Splash Screen Application)

Parameters Java Kotlin

Lines of code 28 26

Application Size 5.36 MB 7.64 MB

Android Profiler
CPU App – 7.7% Others – 23.15% App – 6.46% Others – 64.58%
Memory 28.11 MB at 8.76 Sec 27.01 MB at 9.53 Sec
Network - -

Table 1 - Application Analysis (Splash Screen Application)

Android Profiler Timeline View

Figure 7 - Android Profiler Shared Timeline View (Java – Splash Screen Application)

Figure 8 – Android Profiler Shared Timeline View (Kotlin - Splash Screen Application)
3.1.2 – Option Menu
Menus are a common user interface component in many types of applications. To provide a
familiar and consistent user experience, you should use the Menu APIs to present user actions and
other options in your activities. The options menu is the primary collection of menu items for an
activity. It's where you should place actions that have a global impact on the app, such as "Search,"
"Compose email," and the "Settings." f you've developed your application for Android 3.0 (API
level 11) and higher, items from the options menu are available in the app bar. By default, the
system places all items in the action overflow, which the user can reveal with the action overflow
icon on the right side of the app bar. The options menu is the primary collection of menu items for
an activity. the contents of your options menu appear at the bottom of the screen when the user
presses the Menu button, as shown in figure 1. When opened, the first visible portion is the icon
menu, which holds up to six menu items. If your menu includes more than six items, Android
places the sixth item and the rest into the overflow menu, which the user can open by selecting
More. The options menu is the primary collection of menu items for an activity.

Figure 9 – Common/UI Output (Option Menu Application)

Parameters Java Kotlin

Lines of code 27 24

Application Size 4.79 MB 7.98MB

Android Profiler
CPU App – 7.84% Others - 31.72% App – 13.8% Others – 28.8%
Memory 10.54 MB at 22.99 Sec 12.74 MB at 14.31 Sec
Network - -

Table 2 - Application Analysis (Option Menu Application)

Android Profiler Timeline View

Figure 10 - Android Profiler Shared Timeline View (Java – Option Menu Application)

Figure 11 – Android Profiler Shared Timeline View (Kotlin – Option Menu Application)
3.1.3 – Web View

Android WebView is used to display web page in android. The web page can be loaded from same
application or URL. It is used to display online content in android activity. Android WebView uses
web kit engine to display web page. The android.webkit.WebView is the subclass of Absolute
Layout class. The loadUrl() and loadData() methods of Android WebView class are used to load
and display web page. A WebView is like a tab in a browser. You load pages into a WebView,
interact with it, and display it in some pre-defined manner. The web page can be loaded from same
application or URL. It is used to display online content in android activity. Android WebView uses
web kit engine to display web page. Windowed Views are rendered directly to a platform window
(HWND, NSView, etc.) and capture all input themselves.

Figure 12 – Common/UI Output (Web View Application)

Parameters Java Kotlin

Lines of code 13 12

Application Size 6.15 MB 7.98 MB

Android Profiler
CPU App – 29.81% Others - 13.14% App – 30.87% Others – 27.94%
Memory 38.07 MB at 4.67 Sec 30.89 MB at 3.48 Sec
Network Sent – 0.33 KB/S Sent – 14.66 KB/S
Received – 126.77 KB/S Received – 170.99 KB/S

Table 3 - Application Analysis (Web View Application)

Android Profiler Timeline View

Figure 13 - Android Profiler Shared Timeline View (Java – Web View Application)

Figure 14 – Android Profiler Shared Timeline View (Kotlin – Web View Application)
Explained above about the components, it’s time to move on the Full-Fledged Application
Earthquake. As we already talked about the Earthquake application. Here are some brief
introduction about the application.

Live application which uses network calls to fetch the data from the webserver and displays it in
the mobile app are more common these days. Form shopping cart applications like Flipkart,
Amazon to gaming applications like Clash of Clans uses networking.
The application uses network calls and fetches data form the USGS (United states geological
survey) website. Realtime Data on the USGS website is created by the satellite of America.

Figure 15 – Common/UI Output (Earthquake Application)

Parameters Java Kotlin

Lines of code

Earthquake 15 2

EarthquakeActivity 76 72

EarthquakeAdapter 99 64

EarthquakeLoader 18 13

QueryUtils 89 74

SettingsActivity 38 35

Splash 21 21

Total Lines of Code 356 281

Application Size 6.64 MB 4.63 MB

ProGuard Size – 2.35 MB ProGuard Size – 2.23 MB

Android Profiler

T1 At T = 5.97 Sec. At T = 5.31 Sec.

CPU App - 7.82% Others – 45.63% App – 6.92% Others – 47.77%

Memory 19.01 MB 14.81 MB

Network Sent – 4.72 KB/S Sent – 1.82 KB/S

Received – 45.56 KB/S Received – 11.03 KB/S

T2 At T = 15.02 Sec. At T = 17.92 Sec.

CPU App – 7.64% Others – 30.82% App – 4.28% Others – 13.43%

Memory 24.34 MB 20.96 MB

Network Sent – 1.44 KB/S Sent – 0.53 KB/S

Received – 33.46 KB/S Received – 11.47 KB/S

T3 At T = 25.78 Sec. At T = 30.54 Sec.

CPU App – 8.22% Others – 54.47% App – 3.51% Others – 67.61%

Memory 18.68 MB 16.44 MB

Network Sent – 2.74 KB/S Sent – 1.98 KB/S

Received – 33.56 KB/S Received – 11.76 KB/S

Table 4 - Application Analysis (Earthquake Application)

Android Profiler Timeline View

Figure 16 - Android Profiler Shared Timeline View (Java – Earthquake Application)

Figure 17 - Android Profiler Shared Timeline View (Kotlin – Earthquake Application)

CPU Profiler

Figure 18 – CPU Profiler (Java – Earthquake Application at T = 5.97 Sec, 15.2 Sec, 27.78 Sec)
Memory Profiler

Figure 19 – Memory Profiler (Java – Earthquake Application at T = 5.97 Sec, 15.2 Sec, 27.78
Sec)
Network Profiler

Figure 20 – Network Profiler (Java – Earthquake Application at T = 5.97 Sec, 15.2 Sec, 27.78
Sec)
CPU Profiler

Figure 21 – CPU Profiler (Kotlin – Earthquake Application at T = 5.30 Sec, 17.93 Sec, 30.53
Sec)
Memory Profiler

Figure 22 – Memory Profiler (Kotlin – Earthquake Application at T = 5.30 Sec, 17.93 Sec, 30.53
Sec)
Network Profiler

Figure 23 – Network Profiler (Kotlin – Earthquake Application at T = 5.30 Sec, 17.93 Sec, 30.53
Sec)
 Result

In the Table 4, if we look at Total Lines of Code, Java = 356 whereas Kotlin = 281
If we look at percentage of code minimized is (356 - 281) / 637 * 100 = 11.77%
And so, does for the other single feature application, On an Average Kotlin code generates 10%
less code than Java.
There is not much difference in the size of Earthquake Application, developed in Java and Kotlin,
after using ProGuard.
Java - Earthquake Application (Actual Size) – 6.64 MB, (ProGuard Size) – 2.35 MB
Kotlin - Earthquake Application (Actual Size) – 4.63 MB, (ProGuard Size) – 2.23 MB
In Table 4, T1, T2, T3 are the three-time Instances where the network call has been made.
CPU Time, at every Instant where network call has been made in the application is more enhanced
in Kotlin as shown in Table 4
If we take the average of app percentage usage at three-time instances.
Java = 7.90% compared to Kotlin = 4.92% only.
Memory Usage at Runtime,
Java = (19.01 + 24.34 + 18.68) / 3 = 20.68 MB
Kotlin = (14.81 + 20.96 + 16.44) / 3 = 17.40 MB
Kotlin again has an edge over Java by (20.68 - 17.40) / 38.08 * 100 = 8.6%
Network Usage, is dependent on the internet connection. So, no comparison can be possible.
 Conclusion

While Java is one of the worlds most widely used programming language and is pretty much the
official language of Android development, there are many reasons why Java might not always be
the best option for your Android projects. Java is often being “scolded” for the complexity in visual
perception of some coding constructions. Kotlin is far more advanced in this regard, fitting all the
required commands into one line compared to more than ten lines in Java. As we have observed
in our Earthquake Application which was designed in both Kotlin and Java, Kotlin seems to be
more progressive and comfortable language for working due to its conciseness and
simplicity. With around 11% of reduced code in Kotlin, it has made our application more concise
and easy to read than Java. It is a solution to create a simpler, more readable, and concise program
code with compact syntax and fast compilation which makes it more favorable for the fellow
developers. While comparing the application sizes, there isn’t much difference between Kotlin and
java after using ProGuard. Both application have sizes nearly the same Java - 2.35 and Kotlin –
2.23, here Kotlin slightly has slightly the upper hand but that doesn’t make any difference in real
life scenario but if we see the single feature application Java leads the race in application size. One
of the reasons why Java application sizes are low compared to Kotlin is that Kotlin uses all the
Java libraries and its own libraries which make the application bigger. An import statement in
Kotlin contains more classes and methods than Java. In terms of CPU time Kotlin has exceeded
Java application at every instant where the network call has been made. As showed in results the
average percentage app usage in Kotlin was less than Java by around 3% which was incredible. A
user needs less CPU consumption so that his phone does not gets hanged and with less CPU time
consumption also leads to less battery usage. This means due to Kotlin application effectiveness,
the battery life of the phone will be better than Java apps. In terms of memory usage at the run
time Kotlin has again an edge of Java by 8.6% in the earthquake application. Less memory
consumption leads to better optimized application.
 Future Scope

 Earthquake application mainly deals with network calls form a given API (USGS here)
related concepts but there are also major areas in android like Testing, connectivity to
cloud, Firebase Online DB, maps etc. where this sort of comparison can be done.

 This application is built for Android phones only this can be further extended for wearable
devices, TV, Auto, Chrome OS etc.

 Building our own API and then handling network calls is mainly done in organizations,
this sort of format can be followed for the comparison between Kotlin and Java.

 The number of test cases can be improved to get more confidence while concluding the
work.

 Pro Guard minimizes the application size; this could be followed in single feature
application as it could show different results.

 Android Studio 3 is not the stable version for better results we have to wait for the stable
release.
 References

1. https://www.udemy.com/the-complete-kotlin-developer-course
2. https://kotlinlang.org
3. https://kotlinlang.org/docs/reference/basic-syntax.html
4. https://kotlinlang.org/api/latest/jvm/stdlib/index.html
5. https://try.kotlinlang.org
6. http://shop.oreilly.com/product/kotlin-programming.org
7. https://teamtreehouse.com/library/kotlin-for-java-developers
8. https://www.manning.com/books/kotlin-in-action
9. https://leanpub.com/kotlin-for-android-developers
10. https://kotlinlang.org/community
11. http://talkingkotlin.com
12. https://www.udemy.com/kotlin-course
13. https://kotlinlang.org/docs/kotlin-docs.pdf
14. https://kotlinlang.org/docs/reference/keyword-reference.html
15. https://kotlinlang.org/docs/reference/grammer.html
16. https://kotlinlang.org/docs/reference/compatibility.html
17. https://wiki.jvmlangsummit.com/images/6/6e/jetbrains-kotlin.pdf
18. https://yowconference.com.au/slides/yowconneed/GoulineKotlinPragmeticLanguageAndroid.pdf