GNSS Compare: a novel software framework for

processing raw GNSS measurements on an Android

smartphone
Mateusz Krainski
European Space Agency
ESTEC
Noordwijk, the Netherlands
mateusz@krainski.eu
Sebastian Ciuban Dominika Perz Mareike Burba
European Space Agency European Space Agency European Space Agency
ESTEC ESTEC ESTEC
Noordwijk, the Netherlands Noordwijk, the Netherlands Noordwijk, the Netherlands
ciuban.sebastian@gmail.com dominika.perz@gmail.com mareikeburba@hotmail.de

Abstract—GNSS Compare is an open-source Android applica-
tion, the purpose of which is to ease the efforts of researchers
who are interested in processing the raw Global Navigation
Satellite Systems observables on a smartphone. It is an easy to use
and easy to extend Android-based framework for estimating the
Position, Velocity, and Time based on raw GNSS measurements.
This paper describes the software engineering principles
implemented in GNSS Compare’s software framework. This
description shall come to the aid of the researchers or students
interested in adopting GNSS Compare to their needs. This
could include precise positioning algorithms, sensor fusion, or
smartphone integrity monitoring.
Index Terms—GNSS processing, software engineering, An-
droid, smartphone
This paper focuses on GNSS Compare’s software frame-
work, describes the implemented abstract classes, interfaces,
and the relations between them. For a detailed description of
the implemented algorithms, please refer to [3].
Section II describes the features of the application. Section
III describes in details the software architecture of the imple-
mented solution. Section IV describes shortly what activities a
software developer needs to undertake to fully integrate their
software into the presented application. Section V discusses
potential benefits for identified user groups. Section VI pro-
vides a short summary, conclusions and future work directions.

I. I NTRODUCTION
With the release of Android Application Programming
Interface (API) 24 (Android 7.0) in August 2016, Android
application developers have gained access to the smartphone’s
raw measurements of Global Navigation Satellite Systems
(GNSS) signals [1]. With that, every modern smartphone can
be turned into a low-cost, mobile GNSS signal processing
laboratory. Even further, in 2018, Xiaomi, one of the major
smartphone manufacturers, has released the first smartphone
with a dual-frequency GNSS receiver. This has proven to
increase the positioning accuracy [2] and open new research
possibilities. Other manufacturers are expected to follow this
Fig. 1. GNSS Compare running on a smartphone
example.
Despite the availability of the raw GNSS measurements on
a smartphone, there are some barriers in the exploitation of II. F UNCTIONAL D ESCRIPTION
this functionality. On one side it could be used by Android This section describes GNSS Compare from the functional
app developers, who have advanced knowledge on the An- point of view. It provides an overview and justification of the
droid system. On the other side, it could be used by GNSS features.
researchers, who have advanced knowledge in understanding After starting the application, the user is welcomed by
and processing the raw GNSS measurements. However, to the main User Interface (UI) display shown in Fig. 2. It
fully use and utilize the wide range of possibilities, both those provides a summary of visible and used satellites, as well as
skill-sets are critical. GNSS Compare, as shown in Fig. 1, results of the Position, Velocity, and Time (PVT) estimations.
has been designed to resolve this issue and complement the The unique feature of GNSS Compare is that it allows the
research field in Android raw GNSS measurements processing. user to calculate the result (position) using multiple different
It defines a novel software framework, which makes the raw algorithms in parallel, based on the same input data. So
GNSS measurements API more accessible to both groups. the user can e.g., calculate the position using only Global

Fig. 2. Main Viewer of the GNSS Compare User Interface
Positioning System (GPS) satellites and, at the same time,
calculate the result using combined measurements from both
Galileo and GPS satellites. Up to ten such processing flows,
or Calculation Modules, can be defined by the user. They can
vary with their implementations of the algorithms used for
satellite data processing, computing pseudorange corrections,
PVT estimations, and formatting of the log file storing results
of the calculations. In the example shown in Fig. 2, the user
can compare results achieved when using:
• Galileo E1 signals,
• Galileo E5a signals,
• Galileo E1 and E5a signals combined in an ionosphere-
free configuration [4],
• GPS L1 signals,
• GPS L5 signals,
• GPS L1 and L5 signals combined in an ionosphere-free
configuration for the GPS constellation [4].
By swiping over the screen, the user will change the active
Data Viewer. Those are GNSS Compare’s visual interfaces,
meant to display algorithms’ internal data and various results.
Currently implemented Data Viewers allow the user to view a
summary of the estimations (as shown in Fig. 2), display the
signal strength of the satellites used in calculations, display the
NAVITEC 2018
positioning error with respect to the phone’s internal estimated
location (FINE location is used for comparison [5]), or view
the current position estimations on a map. If needed, the list of
available Data Viewers can be easily extended by a software
developer familiar with Android’s Fragments [6].
After opening the menu on the top right corner of the
screen, the user can add a new Calculation Module, modify
preferences of the existing ones or start a raw data log. When
adding a new Calculation Module, the user is required to select
the implementations for:
• constellation data processing,
• applied pseudorange corrections,
• PVT estimation algorithm,
• log format
from a list of available options. Afterwards, the Calculation
Module is created and the position calculations start. The
implementation of each of the steps is described in detail in
Section III.
After having chosen to modify the existing Calculation
Modules, the user is presented with a summary view of the
created Modules. The user can pause the calculations of each
of the Modules separately, start logging the results to a file
(also separately for each Module), or delete ones which are
no longer needed. The user can also modify the preferences
of existing Calculation Modules, meaning that the realization
of any of the processing steps can be changed. For example,
the user can, while the application is running, disable chosen
pseudorange corrections or change the PVT method. Upon
returning to the main screen of the application, the calculations
will be resumed.
III. T HE S OFTWARE F RAMEWORK
A. Generic Framework for GNSS Observables Processing
As presented in [7], a generic software framework for pro-
cessing Android’s raw GNSS observables can be structured as
follows. First the measurements are retrieved from the receiver.
In the context of Android raw GNSS measurements, this
includes a number of parameters related to the satellite time,
time of measurement, tags describing from which constellation
and satellite the measurement has been received, and a set of
status flags. These raw measurements are then processed to
retrieve the important time measurements: the satellite time
when the signal has been transmitted and the receiver time
when the signal has been received. Pseudoranges to all visible
satellites and satellite positions are calculated afterwards. The
latter calculation also requires satellite ephemeris data and
an approximate user position. Let us assume that an external
ephemeris data provider is used — Google’s Secure User Plane
Location (SUPL) server. With satellite positions calculated,
it is possible to calculate the pseudorange corrections and
to apply them. Finally, based on corrected pseudoranges and
derived satellite positions, the user’s position can be calculated.
This result may be then stored in a file or displayed to the user.
The whole process can be illustrated with a block diagram, as
shown in Fig. 3.
 and location updates. These callbacks are registered upon
calling the registerForGnssUpdates(...) method of the
CalculationModuleArrayList class. The GNSS Core Ser-
vice then subscribes to the CalculationModuleArrayList
with a poseListener. The listener’s onPoseUpdated callback
method is called whenever all Calculation Modules finish their
calculations. This pose listener then sends out an observer
notification [9], which is received by the Main Activity, which
in turn calls the Data Viewer update methods.
The raw GNSS measurement callback results in invoking a
few methods from the Calculation Module, which are used to
update the measurements and calculate a new pose estimate.
Each of the Calculation Modules contains a set of objects,
each of which is implementing a different step of the raw
GNSS measurement processing flow. The objects are of type
extending one of the GNSS Core’s abstract classes:

1) Constellation: any class extending the

Fig. 3. Generic processing flow for raw GNSS measurements processing.
B. GNSS Compare Framework
The design of GNSS Compare follows the principles of
Object Oriented Programming (OOP) [8], Strategy Design
Pattern, and the Observer Design Pattern [9]. The framework
presented above is divided into a number of classes, which
interact with each other. There interactions are implemented
in a class called the CalculationModule. Conceptually, the
architecture of GNSS Compare can be divided into two parts:
1) GNSS Core - implemented as an Android Service [11],
that performs all of the Calculation Module calculations,
2) User Interface - Android Activities [12], that implement
GNSS Compare’s UI and menus.
Upon creation, GNSS Core Service creates a list of Cal-
culation Modules, a CalculationModuleArrayList object,
which implements callbacks for raw GNSS measurements
Constellation abstract class is responsible for
performing satellite-specific calculations, which can
vary between different constellations. This class
implements the preprocessing of time data, calculates
pseudoranges and satellite positions. This class also
has to include a method for retrieving the ephemeris
data (either from an external server or from the
measurements) and it has to provide a definition
of a few accessor methods that will be used to
extract the data, e.g. by the PVT estimator or Data
Viewers. The method updateMeasurements(...)
is responsible for preprocessing the time data
and calculating pseudoranges. Similarly, the
calculateSatPosition(...) method is responsible
for calculating the satellite positions and pseudorange
corrections. To store the measurements, this class uses
list of SatelliteParameters objects. This list can be
later accessed via the getSatelliteParameters(...)
accessor method.
2) Correction: any class extending the Correction ab-
stract class is responsible for calculating the value
of a specific pseudorange correction, e.g. the tropo-
spheric correction. This class has to implement the
calculateCorrection(...) method, which calculates
the value of the correction, based on the time of signal
reception, the approximated position of the receiver,
satellite coordinates, and available ephemeris data. It
also has to implement a few accessor methods to retrieve
the calculated parameters.
3) PvtMethod: any class extending the PvtMethod abstract
class is responsible for calculating the user’s position.
It has to implement the calculatePose(...) method,
which is responsible for calculating user’s position based
on calculated satellite parameters. During calculations,
this class has to take into account the pseudorange
corrections.
4) FileLogger: any class extending the FileLogger ab-
stract class is responsible for retrieving correct data from

NAVITEC 2018
 any required object and storing it to a file. This is meant
for implementing various logging formats. This could be
e.g. a simple Comma Separated Values (CSV) format,
or the National Marine Electronics Association (NMEA)
format.
Additionally, in the User Interface part of the application,
a DataViewer abstract class is defined. It implements the
aforementioned Data Viewer functionality. Any class extend-
ing DataViewer is responsible for implementing a Fragment
interface and displaying the data to the user. Data Viewers have
two callbacks. One of them is called by any worker thread and
is meant to update the internal data of the Data Viewer. The
second one is executed on the application’s UI thread [10] and
is meant to update the graphics displayed to the user. To keep
the application running smoothly, it is advised to keep heavy
calculations outside of the UI thread.
By default, the GNSS Core Service creates the Calculation
Modules as presented in Table I. For phones supporting dual-
frequency signals, the configuration presented in Table II is
used instead. This setup is currently hard-coded. However,
efforts are now underway to make it possible to load the
settings from a configuration file instead. This would allow the
users to change the default configuration without recompiling
the application.
Following the description above, the implementation of
the graph shown in Fig. 3 can be presented as in Fig. 4.
For the simplicity of the diagram, some features and checks
performed by the software were omitted. The approxi-
mate receiver position for initializing the algorithms is the
phone’s FINE location. It is being retrieved by one of the
CalculationModuleArrayList’s callbacks.
It is also worth mentioning, that currently efforts are being
made to further decouple the User Interfaces of GNSS Com-
pare from the GNSS Core Service, so that it would be possible
to use the GNSS Core Service as a standalone Android library.
At the time of writing, any software developer wishing to
use the GNSS Core Service in their application, still needs
to manually include the code as a module or package in their
application.
IV. F RAMEWORK F LEXIBILITY
Due to the implementation of the Strategy Design Pattern,
the user of the application can, on runtime, change the used
algorithms for any selected component of any Calculation
Module. This section provides more details on the implemen-
tation and other benefits of using the strategy pattern [9].
The four abstract classes defining the interfaces for the
calculations (Constellation, Correction, PvtMethod and
FileLogger) are also using Java’s Reflection [13] to stat-
ically store references to any classes which are extending
them. Currently it is the developer’s responsibility to reg-
ister the developed class, by calling a proper register
method (e.g. Constellation.register(Galileo.class,
"Galileo") would register the Galileo class as an avail-
able constellation). With that, the newly developed class is Fig. 4. Generic processing flow for raw GNSS measurements processing.
added to the registry of available classes. Classes can be

NAVITEC 2018
 TABLE I
D EFAULT C ALCULATION M ODULES

Name Constellation Corrections PVT Method File Logger

Shapiro Correction,
Galileo Galileo Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction
Shapiro Correction,
GPS GPS Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction
Shapiro Correction,
Galileo + GPS Galileo + GPS Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction

TABLE II
D EFAULT C ALCULATION M ODULES FOR DUAL FREQUENCY PHONES

Name Constellation Corrections PVT Method File Logger

Shapiro Correction,
Galileo E1 Galileo E1 Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction
Shapiro Correction,
Galileo E5a Galileo E5a Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction
Shapiro Correction,
Galileo IF Galileo Ionosphere-Free Dynamic Extended Kalman Filter NMEA format
Tropospheric Correction
Shapiro Correction,
GPS L1 GPS L1 Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction
Shapiro Correction,
GPS L5 GPS L5 Tropospheric Correction, Dynamic Extended Kalman Filter NMEA format
Klobuchar Ionospheric Correction
Shapiro Correction,
GPS IF GPS Ionosphere-Free Dynamic Extended Kalman Filter NMEA format
Tropospheric Correction

retrieved from the registry by using the corresponding super- method.

class’s static method getClassByName(...) and the name
of the retrieved class – the same as the one used when
registering the class. For example, a call to the static method
Constellation.getClassByName("Galileo"), would return
a reference to the Galileo class registered before. This would
be an object of type Class <? extends Constellation>.
This object can be later used to create a new Constellation-
subtype object by calling the newInstance() method.
All menus displayed in the application are using the names
of the registered classes as names of the implemented calcu-
lation steps. This means that after registering the class to its
superclass, that class is available for the user to be selected
from the settings. When creating a new Calculation Module
or modifying an existing one, the user is asked to select the
implementation of each component from a list. That list of
possibilities is automatically generated based on registered
classes. This means, that aside of implementing the class and
registering it, the developer does not need to perform any
additional actions to make the new class fully available in
GNSS Compare. The registration should be performed in the
initialize() method of the superclass, which is called by
the GNSS Core Service when starting the application.
This is slightly different for the Data Viewer objects. In that
case, the developer is required to create a new object of the
developed class in the DataViewerAdapter’s initialize()
Developers wishing to implement their own algorithms are
required to write a new class, which will extend a proper super
class (as described in III and implement all abstract methods
defined for that class. This includes methods for processing
the data, but also accessor methods for internal parameters.
For example, when implementing a Constellation subclass,
the developer needs to implement the methods performing
the actual calculations (i.e. updateMeasurements(...) and
calculateSatPosition(...), as described in section III),
but also few accessor methods, e.g.:
• getConstellationId(), which should return the con-
stellation ID, using either GnssStatus’s constella-
tions types or constellation types implemented in
Constellation
• getRxPos(), which should return the coarsely estimated
receiver’s position,
• getUsedConstellationSize(), which should return the
number of satellites used for calculations.
Full list of methods which are needed to be implemented can
be easily derived using an Integrated Development Environ-
ment (IDE), e.g. Android Studio [14]. When writing a new
implementation of a class, the IDE will suggest what methods
need to be implemented after writing the basic declaration of
a new class:

NAVITEC 2018
public class MyConstellation extends
Constellation {
/* *
* Implementation goes here
*/
} est will increase, more efforts will be taken to standardize the
Then, after writing the method declaration, the IDE will also
provide a short description on what the method should be
doing.
If the developer wishes to just use GNSS Compare’s Core
Service for their GNSS measurements processing, they need
to start the GNSS Core service in the main activity of their
application. If the application uses more than one activity that
needs the access to the calculation results, it is advised to
use GNSS Compare as a Started-Bound service [11]. This
means that the service is first started by the main activity and
then bound/unbound when other activities come into focus.
If just one activity will be using the service, it can be used
as a Bound service. In both cases, the developer has to
provide an implementation of a ServiceConnection object. In
that object’s onServiceConnected(...) method, the activity
can subscribe to the GNSS Core Service’s observable: the
second argument of the onServiceConnected(...) method
(an IBinder object) can be cast to a GNSS Core Service’s
GnssCoreBinder type and an observer can be added by
invoking the .addObserver(...) method. Example of such
implementation can be found in the Main Activity of GNSS
Compare.
V. B ENEFITS
In the introduction, it has been mentioned that GNSS
Compare provides benefits to two groups of users – software
developers and GNSS Scientists. This section briefly describes
the benefits for each group.
A. Benefits for Software Developers
In a standard scenario, when Android software developers
would be required to use the raw GNSS measurements API for
more than just retrieval of raw measurements, they would need
to implement at least some of the steps described in Section
III. This might prove challenging, as even the most compact
description is still very technical and requires understanding of
advanced mathematics and GNSS theorems [7]. When using
GNSS Compare’s framework — the GNSS Core Service —
the software developer gains access to a set of building blocks,
from which they can select ones which fit their needs best.
They needs to worry not about the implementation details
or the mathematics behind each of them, but more about the
functionalities they provide and their operational requirements.
As an example, let us consider different possible im-
plementations of the PVT estimator. The Weighted Least
Squares (WLS) method is one of the standard PVT estimators
available. It provides reliable results with moderate accuracy,
it works fine with good satellite visibility and uses little
computational resources. On the other hand, some hypothet-
ical, more advanced algorithms, tightly coupling the GNSS
NAVITEC 2018
measurements and phone’s sensors could provide significantly
more accurate results, use more computational resources, and
work fine even with limited satellite visibility, including short-
term GNSS signal outages as presented e.g. in [15] or [16].
As the number of available implementations and user inter-
descriptions and evaluation of said methods.
Software developers can in turn provide inputs and im-
provements to the software architecture of the implemented
framework.
B. Benefits for GNSS Scientists
The main benefit for GNSS Scientists is the reduced com-
plexity when implementing and testing their algorithms on
Android smartphones. With GNSS Compare, they need not
implement a whole Android application — they can just focus
on developing their algorithm. After the development, real-
time test campaigns are also simplified, as GNSS Compare
allows for real-time comparison of results of multiple different
realizations of the processing chain. Modern-day smartphones
are very powerful computing devices, which are additionally
equipped with multiple sensors, e.g. Inertial Measurements
Units (IMUs) and provide access to the Internet. This opens
many new research possibilities without the necessity to ac-
quire costly, specialized equipment. Additionally, it has been
suggested multiple times, that such application is a great tool
for GNSS students, student projects and initial studies.
GNSS Scientists can in turn provide implementations of
their algorithms for GNSS Compare. This would allow for
easy comparison of algorithm performance between different
scientific groups. Such community might be highly stimulating
for the general community of satellite navigation or even
navigation in general. At the moment of writing, these modules
would have to open-source. Efforts are taken however to
assess the possibility of adding closed-source modules to the
application, as well as whether it is possible to add such
modules without the necessity to rebuild the whole application.
VI. S UMMARY
The GNSS Compare application is currently published on
the Play Store [17], where it is available for free download.
The source code, published on the Apache License 2.0, is
available on GitHub [18], with documentation available on
Read the Docs [19]. At the moment of writing, the application
has a rating of 4.0, over 3,600 downloads and over 2,000
users. To the authors’ knowledge, there are currently two
applications being developed using GNSS Compare’s software
framework; one example is Callisto – Galileo’s Spaceship
[20]. An exemplar work of research performed using GNSS
Compare has also been presented in a different paper at the
same conference [3].
The general reception of the application is very positive
in both scientific and software developer communities. So far,
the application has been awarded first place in European Space
Agency’s internal Galileo App Challenge [21], the European
Satellite Navigation Competition’s (ESNC) Living Lab prize
[22], and second place in the ESNC’s Czech Republic Chal- [10] Google, “Processes and threads overview”, 2018. [Online]. Available:
lenge [23]. It is worth noting that some of those challenges https://developer.android.com/guide/components/processes-and-threads.
[Accessed: 10.10.2018]
not only evaluated the technical aspects of the idea, but also [11] Google, “Service”, 2018. [Online]. Available: https://developer.android.
the business potential. com/reference/android/app/Service. [Accessed: 10.10.2018]
In the near future, we plan to use the described software [12] Google, “Activity”, 2018. [Online]. Available: https://developer.android.
com/reference/android/app/Activity. [Accessed: 10.10.2018]
framework to evaluate the benefits of sharing low-level GNSS [13] G. McCluskey, “Using Java Reflection”, 1998. [Online].
data over the internet between multiple users. This idea, Available: https://www.oracle.com/technetwork/articles/java/
somehow similar to Cooperative Intelligent Transportation javareflection-1536171.html. [Accessed: 10.10.2018]
[14] Google, “Android Studio”, 2018. [Online]. Available: https://developer.
Systems (C-ITS) [24], it may improve positioning accuracy, android.com/studio/. [Accessed: 20.10.2018]
reliability, availability and robustness of satellite navigation [15] S. Godha, G. Lachapelle, and M.E. Cannon, “Integrated GPS/INS
systems, especially in challenging, highly populated areas with System for Pedestrian Navigation in a Signal Degraded Environment”,
ION GNSS 2006, September 2006.
high signal obstruction. We also plan to utilize the prizes from [16] A. Noureldin, T. B. Karamat, M.D. Eberts, and A. El-Shafie, “Perfor-
the ESNC (which include business mentoring) and focus more mance Enhancement of MEMS-Based INS/GPS Integration for Low-
on the business side of the presented idea. Cost Navigation Applications”, IEEE Transactions on Vehicular Tech-
nology, March 2009.
ACKNOWLEDGEMENTS [17] TFI Systems, “GNSS Compare”, 2018. [Online]. Available: https://play.
google.com/store/apps/details?id=com.galfins.gnss_compare. [Accessed:
The developers of GNSS Compare would like to thank the 10.10.2018]
Directorate of Navigation and the Directorate of Technology, [18] TFI Systems, “GNSS Compare”, 2018. [Online]. Available: https://
github.com/TheGalfins/GNSS_Compare. [Accessed: 10.10.2018]
Engineering and Quality of the European Space Agency (ESA) [19] TFI Systems, “GNSS Compare documentation”, 2018. [Online].
for organizing the Galileo App Challenge, which has brought Available: https://gnss-compare.readthedocs.io/en/latest/. [Accessed:
our team together. Special thanks to ESA employees who are 10.10.2018]
[20] The ChocolaTeam, “Callisto - Galileo’s Spaceship”, 2018.
sharing their knowledge and experience with us: Paolo Crosta, [Online]. Available: https://play.google.com/store/apps/details?id=
Nityaporn Sirikan, Gaetano Galluzzo, Paolo Zoccarato, and com.chocolateam.galileogame. [Accessed: 10.10.2018]
Tim Watterton. Your insights are highly valued by us and you [21] European Space Agency, “ESA trainees compete in
inaugural Galileo app contest”, 2018. [Online]. Available:
are helping us move the project forward. https://www.esa.int/Our_Activities/Navigation/ESA_trainees_compete_
We would like to also thank ESA for the promotion of in_inaugural_Galileo_app_contest. [Accessed: 10.10.2018]
the application on social media and during ESTEC’s Open [22] European Satellite Navigation Competition, “GNSS Living Lab Prize”,
2018. [Online]. Available: https://www.esnc.eu/prize/living-lab/. [Ac-
Day. Those two acts have alone aggregated more than 3,000 cessed: 10.10.2018]
downloads of the application, which in turn motivates us to [23] European Satellite Navigation Competition, “Czech Republic
continue the work. Challenge”, 2018. [Online]. Available: https://www.esnc.eu/prize/
czech-republic/. [Accessed: 10.10.2018]
Finally, special thanks to Matej Poliacek and Peter Vanik [24] European Transport Safety Council, “Cooperative Intelligent Transport
from the ChocolaTeam, who have trusted the framework we’ve Systems (C-ITS) ”, November 2017.
developed and are using it as the calculation back-end of their
application [20].
R EFERENCES
[1] Google, “Raw GNSS Measurements”, 2018. [Online]. Available:
https://developer.android.com/guide/topics/sensors/gnss. [Accessed:
10.10.2018]
[2] Marco Fortunato, “Initial tests of the Xiaomi Mi 8 dual frequency
GNSS smartphone”, 2018. [Online]. Available: https://www.nsl.eu.com/
nsl-jcms/about-nsl/nsl-blog/15-products-and-services/55-xiaomi-mi8.
[Accessed: 11.10.2018]
[3] S. Ciuban, M. Krainski, D. Perz, and M. Burba, “GNSS Compare:
Performance assessment of real-time PVT algorithms using raw GNSS
measurements on an Android smartphone”, Navitec 2018, December
2018.
[4] P. Crosta, P. Zoccarato, and R. Lucas Rodriguez, “Dual Frequency Mass-
market Chips: Test Results and Ways to Optimize PVT Performance”,
ION GNSS+ 2018, September 2018.
[5] Google, “Location Strategies”, 2018, [Online]. Available:
https://developer.android.com/guide/topics/location/strategies.
[Accessed: 10.10.2018]
[6] Google, “Fragments”, 2018, [Online]. Available: https://developer.
android.com/guide/components/fragments. [Accessed: 10.10.2018]
[7] GSA GNSS Raw Measurements Task Force, “Using GNSS Raw Mea-
surements on Android Devices”, European GNSS Agency, 2017
[8] A. Sinicki, “What is Object Oriented Programming?”,
2017. [Online]. Available: https://www.androidauthority.com/
object-oriented-programming-755216/. [Accessed: 10.10.2018]
[9] E. Gamma, R. Helm, R. Johnson, J. Vlissides, “Design Patterns – Ele-
ments of Reusable Object-Oriented Software”, Addison-Wesley, March
2009.

NAVITEC 2018