Characterizing Bugs in Login Processes of Android Applications: An Empirical Study

Abstract

The login functionality, being the gateway to app usage, plays a critical role in both user experience and application security. As Android apps increasingly incorporate login functionalities, they support a variety of authentication methods with complicated login processes, catering to personalized user experiences. However, the complexities in managing different operations in login processes make it difficult for developers to handle them correctly. In this paper, we present the first empirical study of login issues in Android apps. We analyze 361 issues from 44 popular open-source Android repositories, examining the root causes, symptoms, and trigger conditions of these issues. Our findings indicate that the vast majority of the login issues are induced by the improper handling of complex state transitions during the login process, which can prevent users from logging in or misdirect them to incorrect subsequent actions. Additionally, we observed that issues related to this cause typically require the convergence of multiple trigger conditions to manifest. These findings can help developers to model the login processes which can help them to identify the causes of issues and design targeted test cases and precise test oracles. Our dataset has been made openly available to facilitate future research in this area.

Full text

Characterizing Bugs in Login Processes of Android
Applications: An Empirical Study
Zixu Zhou
McGill University
Montreal, Canada
zixu.zhou@mail.mcgill.ca
Rufeng Chen
McGill University
Montreal, Canada
rufeng.chen@mail.mcgill.ca
Junfeng Chen
Southern University of Science and Technology
Shenzhen, China
chenjf@mail.sustech.edu.cn
Yepang Liu
Southern University of Science and Technology
Shenzhen, China
liuyp1@sustech.edu.cn
Lili Wei
McGill University
Montreal, Canada
lili.wei@mcgill.ca
Abstract—The login functionality, being the gateway to app
usage, plays a critical role in both user experience and appli-
cation security. As Android apps increasingly incorporate login
functionalities, they support a variety of authentication methods
with complicated login processes, catering to personalized user
experiences. However, the complexities in managing different
operations in login processes make it difficult for developers to
handle them correctly. In this paper, we present the first empirical
study of login issues in Android apps. We analyze 361 issues from
44 popular open-source Android repositories, examining the root
causes, symptoms, and trigger conditions of these issues. Our
findings indicate that the vast majority of the login issues are
induced by the improper handling of complex state transitions
during the login process, which can prevent users from logging in
or misdirect them to incorrect subsequent actions. Additionally,
we observed that issues related to this cause typically require
the convergence of multiple trigger conditions to manifest. These
findings can help developers to model the login processes which
can help them to identify the causes of issues and design targeted
test cases and precise test oracles. Our dataset has been made
openly available to facilitate future research in this area.
Index Terms—Login, Empirical Study, Android, Issue
I. INTRODUCTION
Login plays a critical role in Android apps, typically rep-
resenting the first point of interaction between the application
and the users [1]. Issues in login processes can significantly
degrade the user experience [2]–[5]. Studies have shown that
first-time login failures can lead to a direct and immediate
drop in user engagement by as much as 25% [2], [6]. Such
statistics highlight the critical nature of robust login processes
and demonstrate their potential economic impact on software
developers, emphasizing the need for improved reliability in
the login processes.
Existing studies have extensively explored a wide spec-
trum of software defects and usability challenges in An-
droid applications [1], [6], [7]. Studies were conducted to
characterize diverse issues in the Android ecosystem ranging
Yepang Liu is affiliated with both the Research Institute of Trustworthy
Autonomous Systems and Department of Computer Science and Engineering.
from compatibility issues [8]–[11], WebView problems [12]–
[14], cross-platform usability challenges [15]–[17] to specific
security vulnerabilities [18]–[24]. Some related studies analyze
vulnerabilities related to Android app authentication, an impor-
tant component in the login process [25]–[28]. For example,
Philippaerts et al. [25] proposed Oauch, which can measure
how well individual identity providers (IdPs) implement the
security specifications defined in the OAuth standard and
provide development suggestions to developers. Jannett et
al. [26] conducted an empirical study on Single Sign-On (SSO)
and developed a tool, Sok, focusing on testing SSO in Android
by large-scale dual-window analysis. Shi et al. [27] developed
MoSSOT, a backbox tester for the OAuth process in Android.
Furthermore, Tamjid et al. [28] conducted an empirical study
on the usage of OAuth APIs and their implications for mobile
security, leading to the development of OAUTHLINT, a tool to
identify vulnerabilities in OAuth implementations for Android
apps. These studies mainly focused on vulnerabilities arising
from the authentication process. However, the login process
extends beyond authentication.
The login processes can be briefly described in three stages:
Pre-login, login, and post-login. Initially, in the Pre-Login
phase, the app checks for an existing valid token to either
bypass or prompt for user credentials. During the Login phase,
the app assesses the credentials and, if necessary, proceeds
with multi-factor authentication before granting access. Once
authentication is successful, the Post-Login phase commences,
granting the user full access to the app’s features. Developing
reliable and robust login processes requires the app developers
to properly manage complicated interactions between the app,
the users and the servers. In addition, such interactions can
interfere with the Android system events. Such complexities
make it especially challenging to implement the login pro-
cesses correctly.
No existing studies have systematically characterized the
various issues in the login processes of Android apps. This
paper presents an empirical analysis of the root causes, symp-
toms, and trigger conditions of login issues in Android apps
arXiv:2502.04200v1 [cs.SE] 6 Feb 2025

to address this research gap. Our investigation is structured
around the following research questions:
•RQ1: (Root Causes of Login Issues): What are the
common root causes of login issues in Android apps?
•RQ2: (Symptoms of Login Issues): What symptoms are
commonly observed when login issues occur, and how do
they impact user experience?
•RQ3: (Trigger Conditions of Login Issues): Under
what conditions are login issues likely triggered?
Answering these research questions offers practical benefits
to both developers and researchers. RQ1 characterizes the
common root causes of login issues in Android apps to
understand how the issues are induced comprehensively. RQ2
and RQ3 investigate the symptoms and trigger conditions of
login issues and can guide developers to generate targeted test
cases and effective test oracles.
We analyzed 361 login issues across 44 open-source An-
droid apps to answer our research questions. This analysis
leads to several key findings. We proposed using state ma-
chines to model the complicated login processes. We disclosed
that the majority (62%) of the login issues can be attributed
to errors in managing the states and their transitions. For
example, Home Assistant [29] requires users to input a URL
for login to access remote services. The issue [30] arose
because developers inadequately managed the login process’s
state; they did not properly store and update the new URL
provided by the user, leading to a blank screen even with
the correct credentials entered. This observation suggests that
future research can focus on addressing such login flow errors.
Our proposed state machine can guide the test generation for
exposing these errors. In addition, our study reveals that login
flow errors can induce various consequences, including failures
in the authentication process, crashes, etc. These observations
can help define the test oracles for effective login flow error
detection.
To summarize, this paper makes the following major con-
tributions:
•Login issues dataset: We carried out the first empirical
study on login issues within real-world Android apps.
Our dataset includes 361 login issues sourced from 44
popular repositories. We have made this dataset available
to support further research [31].
•Comprehensive Categorization: We systematically
identified and categorized the root causes, symptoms, and
trigger conditions of login issues in Android apps.
•Bridging Theory and Practice: By exploring the im-
plications of our findings, this research not only can aid
developers in modeling the login process but also help
them to design targeted test cases and precise test oracles.
All datasets and scripts used in this study are open-sourced
and available, further enabling the community to replicate our
findings and extend our work [31].
II. BACKGROU ND
A. Android Authentication Methods
Android apps utilize various authentication methods to
manage user access and ensure security. Authentication is
a critical component of the login process, serving as the
method by which applications verify user identity to grant
access to their features and ensure security. The most common
approaches include traditional username and password login,
social media integration, and biometrics such as fingerprint
scanning and facial recognition [32]. Each method offers
distinct advantages and disadvantages. For instance, username
and password combinations are widely used due to their
simplicity and familiarity but are vulnerable to brute force
attacks and phishing. Social media logins such as Google
Lgoin [33] and Facebook Login [34] offer convenience by
allowing users to sign in with existing accounts, reducing
password fatigue and streamlining the user experience. How-
ever, they can raise concerns about privacy and data security.
Biometric methods provide robust security and a quick au-
thentication process but require specialized hardware and can
be affected by environmental factors or changes in the user’s
physical condition. To further enhance security, Multi-Factor
Authentication (MFA) [35] is increasingly being implemented,
which requires users to provide multiple verification factors,
significantly reducing the risk of unauthorized access.
B. States in the Login Process
The login process in Android apps can be divided into three
distinct phases: pre-login, login, and post-login.
Pre-login Phase: This initial stage involves checking
whether the user has previously logged in and if there is a valid
token present. If no valid token is found, the user is prompted
to select a login approach and enter the corresponding creden-
tials. This stage is crucial for determining the starting point of
the authentication process, ensuring that returning users can
proceed faster if they have valid sessions.
Login Phase: During this phase, the submitted credentials
are validated to verify correctness. Additionally, if Multi-
Factor Authentication (MFA) is enabled, the user is required
to provide an MFA code. This code is then validated to ensure
an extra layer of security. This phase is critical as it directly
impacts the security of the user’s access and the integrity of
the application.
Post-login Phase: After successful verification, this phase
grants the user access to the app’s resources. It marks the
transition from authentication to actual usage of the applica-
tion, where the user interacts with the app’s features based
on their access level and permissions. This phase is essential
for a seamless transition and ensuring the user’s experience is
smooth and secure.
III. EM PR IC AL S TU DY SE TU P
A thorough understanding and categorization of these prob-
lems is essential to address the pervasive login issues in
Android apps. We followed the process adopted by exist-
ing work [11], [13], [36], [37] to prepare the dataset for

our empirical study. Our research began with an extensive
examination of Android-related repositories on GitHub [38]
using specific keywords such as “android-app, “android” and
“android-library,” among others, to select repositories likely to
contain relevant data on login issues. All keywords used are
available on our GitHub repository [31].
A. Data Collection
Our study involved a meticulous selection process for
identifying repositories that are both relevant and exhibit high
quality based on the following criteria: 1) Recent Activity:
Repositories must have had their last commit after January
1, 2023, indicating active development; 2) Community En-
gagement: Repositories were required to have more than 50
stars, reflecting a certain level of community endorsement;
3) Substantial Contribution: Each repository should have
over 200 commits, demonstrating significant developer invest-
ment; 4) Programming Language: Repositories needed to
predominantly use Java or Kotlin, which are commonly used
for Android development.
To efficiently gather data, we utilized the GitHub Search
API [39], which imposes a cap of 1,000 results per query.
The query example is shown in Listing 1. To circumvent this
limitation and ensure comprehensive data retrieval, we adopted
an iterative querying approach [11], [40], [41]. By sorting
repositories by their most recent update and progressively
refining our search with the ‘pushed’ filter, we were able to
compile a complete list of repositories fitting our criteria. This
methodological rigor enabled us to amass a total of 2,675
repositories. Fig 1 shows the overview of the data collection
and selection process.
GitHub
2675 Repositories
50201 Issues From 2569 Repositories
2398 Issues From 89 Repositories
361 Issues From 44 Repositories
Step 1:GitHub Search
Step 2: Keywords Filter
Step 3: TF-IDF Keywords Filter
Step 4: Advanced Criteria Filter
Fig. 1. The process of dataset collection
The repositories’ metadata and the complete list of reposito-
ries have been preserved and are accessible within our study’s
digital artifacts [31].
1query := keyword
2+" stars:>50"
3+" pushed:>=2023-01-01"
4+" language:java language:kotlin"
Listing 1. GitHub Search Query Example
In the subsequent phase, our objective was to pinpoint login-
specific issues within the amassed repositories. Initially, to
refine our search and reduce extraneous data, we excluded
repositories with names suggesting a focus on coding in-
terviews or algorithmic challenges, such as those containing
“interview” or “leetcode”. After the filter, we obtained 2,569
repositories.
To enhance search performance and avoid triggering rate
limits of the GitHub search API, we downloaded all closed
issues from 2,569 repositories. We then conducted a keyword
analysis using TF-IDF [42] and stopwords [43] to identify and
extract key terms frequently appearing in login-related issues.
Initially, we manually selected 10 login-related issues and used
TF-IDF in conjunction with stopwords to determine the top
10 most frequent terms within these issues. These keywords
were then employed to search through all downloaded issues,
focusing on the titles and descriptions. Subsequently, we
applied TF-IDF analysis again to the issues that contained
these top 10 terms, such as “login”. To keep the login relevance
of results issues, we only extracted the top 100 terms, such
as “auth”, “sign in” and “MFA” that were used as search
keywords. We manually verified each term to ensure the
relevance of the login process. This refined list of keywords
guided our secondary search through the GitHub issues API,
leading us to identify 2,398 issues across 189 repositories.
To ensure the scientific validity and reliability of our study,
we applied rigorous filters to the identified issues: 1) Fix
Commit Link: Each issue had to include a link to a commit
that purportedly resolved the issue, ensuring that we could
verify and analyze the resolution approaches; 2) Accessibility
of Commit Links: The commit links associated with the
issues had to be accessible, allowing us to review the actual
code changes made.
After applying these filters, our final dataset comprised 361
issues from 44 repositories. As detailed in Table I, which only
contains the repositories that have more than 10 issues, our
dataset includes highly popular Android apps, evidenced by
significant GitHub stars and download numbers on Google
Play. This diverse set encompasses a wide range of app cate-
gories, ensuring a comprehensive analysis across various user
experiences and functionalities. For instance, WordPress [44]
serves as a content management app, NextCloud [45] is
utilized for file synchronization and cloud storage, and El-
ement [46] functions as a secure messaging platform. This
breadth of app types, from productivity to social interaction,
enhances the relevance and applicability of our findings to
real-world usage scenarios.
B. Data Analysis
The study observes that precise categorizations of issues
play a vital role in the development of Android apps [7].
We employed an open coding methodology to address the
classification of 361 identified login issues into root causes,
symptoms, and trigger conditions. This approach facilitated a
systematic and structured classification process, enhancing the
depth and accuracy of our analysis.
1) Stage I Initial Categorization: The first stage involved
a preliminary analysis where 10% of the issues, totaling 36

TABLE I
SUMMARY OF ANDROID OPEN-SOURCE REPOSITORIES WITH
SIGNIFICANT LOGI N ISSU ES( WE O NLY LI STE D RE POS ITO RI ES TH AT
CONTAIN MORE THAN 10 ISS UE S)
Repository Issues Stars Downloads
thunderbird/thunderbird-android [47] 41 10.9k 50k+
woocommerce/woocommerce-android [48] 37 277 1M+
nextcloud/android [45] 35 4.3k 1M+
firebase/FirebaseUI-Android [49] 25 4.6k N/A
fossasia/open-event-attendee-android [50] 17 2k 500k+
element-hq/element-android [46] 16 3.4k 1M+
home-assistant/android [29] 16 2.3k 1M+
tuskyapp/Tusky [51] 15 2.5k 500k+
commons-app/apps-android-commons [52] 14 1k 100k+
ankidroid/Anki-Android [53] 11 8.7k 10M+
fossasia/phimpme-android [54] 11 2.6k 1M+
element-hq/element-x-android [55] 10 1.1k 10k+
bitfireAT/davx5-ose [56] 10 1.5k 100k+
distinct issues, were randomly selected for initial coding. Two
researchers independently reviewed each issue’s description,
developer replies, and fix commits. The objective was to
identify broad categories under the three aspects: (1) Root
Causes: Fundamental reasons that initiate the login issues;
(2) Symptoms: Observable effects or behaviors resulting from
the issues; (3) Trigger Conditions: Specific scenarios or
conditions under which the issues occur. A combination of
several conditions can trigger one issue. So, one issue can only
have one label for the root cause and symptom but multiple
for trigger conditions.
Each researcher independently assigned issues to prelimi-
nary categories, ensuring that the initial classification captured
the diversity and complexity of the login issues.
Following the independent phase, the two authors convened
to discuss their findings and reconcile any differences in
category assignment. A third author resolved any conflicts
between the initial two authors.
2) Stage II Extensive Categorization and Category Refine-
ment: With the foundational categories established, the second
stage extended the categorization process to an additional
30% of the issues. This larger sample allowed for a robust
application of the categorization framework. The two authors
continued to work independently, applying the categories to
new issues and meeting regularly to discuss their findings.
These discussions allowed for continuous refinement of the
categories: (1) Identifying new categories that emerged from
the data; (2) Modifying existing categories to reflect the
data better; (3) Ensuring consistency and accuracy in the
application of categories across all analyzed data.
This iterative categorization and discussion cycle was re-
peated until all issues in the sample had been classified. The
open coding procedure facilitated a dynamic adaptation of the
categorization framework, accommodating the complexities
and nuances of the login issues encountered.
3) Final Review and Consensus: The final stage of the
open coding process involved a comprehensive review and
consensus discussion to confirm the accuracy of category
assignments and finalize the taxonomy of login issues. The
TABLE II
SUMMARY OF ROOT CAUS ES AN D ISS UE COUNTS
No. Root Causes #Issues
1 Login Flow Error 214
1.1 Improper Error State Handling 57
1.2 Interference with Other State Machines 57
1.3 Missing Login Flow 52
1.4 Incorrect Login Flow 48
2 API Misuse 63
3 Null Object Check Omission 39
4 Improper Encoding Algorithm 23
5 Wrong Environment Dependency 22
categorization’s reliability was highlighted by high agreement
levels among researchers, quantified by Cohen’s Kappa: 0.88
for Root Causes, 0.82 for Symptoms, and 0.55 for Trigger
Conditions. The relatively lower Kappa for Trigger Conditions
is attributed to the complexity and variability in identifying
multiple conditions per issue, where exact agreement on the
type and number of conditions is required, reflecting substan-
tial inter-rater reliability.
IV. EMPIRICAL STU DY
This section presents the findings of our empirical analysis
of the 361 login issues.
A. RQ1:Root Causes
Understanding root causes is vital as it lays the groundwork
for developing a more robust login process in Android apps.
Through a meticulous process of open coding, our study cate-
gorized these root causes into five groups, each characterized
by distinct patterns and contributing factors. Table II shows an
overview of all the categories.
1) Login Flow Errors: The login processes in Android apps
typically require a dedicated sequence of operations (the login
flow) involving the apps, the users, and some backend services.
These operations can include user inputs, authentication, or
error handling. For example, checking for the presence of a
valid token will decide whether to transfer apps into logged-in
or ask the user to input credentials. Subsequently, suppose the
user inputs the correct credentials. In that case, the app will
prompt the user for MFA processes or log in directly to the
user, depending on whether the user activates MFA.
We propose to leverage state machines to model this compli-
cated process. Figure 2 illustrates our proposed state machine,
which is structured into three composite states:Pre-Login,
Login, and Post-Login. The format denotes each transition
between states: Trigger[Guard]/Action, signifying that if the
condition specified in the Guard is met following a Trigger,
the app executes the corresponding Action. Initially, the app
checks for a valid token from the Initial State within the Pre-
Login phase; if a valid token is present, it transitions directly
to the Logged In state, thus bypassing the credential input.
The app transfers to the Credential Input state if no valid
token exists, prompting the user to input login credentials.
Subsequently, if the credentials are incorrectly formatted, the

Pre-Login
ch1
-[]/CheckToken
Credential
Input
TokenValid[]/LoginSuccess
TokenInvalid[]/PromptUserForCredentials
ch2
-[]/EncodeCredential
Credential
Format Error
SubmitCredentials
[InvalidFormat]/
PromptFormatError
-[]/Retry
SubmitCredentials
[ValidFormat]/Authenticate
Login
ch4
Authenticating
-[]/CheckCredentials
ch5
-[ValidCredentials]/CheckMFASetting
Invalid
Credentials
-[InvalidCredentials]/
-[MFARequired]/RequestMFA
ch3
-[ServiceAvailable]/
Service
Unavailable
-[ServiceUnavailable]/
MFA Code
Pending
MFA
Verification
-[MFANotRequired]/LoginSuccess
ch6
-[]/SentMFA Code
ServiceUnavailable[]/
SubmitMFACode
ServiceAvailable[]/VerifyMFA
ch7
ServiceUnavailable[]/
ch8
ServiceAvailable[]/
CheckMFA
MFA
Error
MFAInvalid[]/RetryMFA
-[]/Retry
MFAValid[]/LoginSuccess
Post-Login
Logged In
Initial
State
Final
State
Check
Point
Notation
Trigger[Guard]/Action
Transition Basic
State
Composite
State
Fig. 2. State Machine for Login Process
state transitions to Credential Format Error; otherwise, the
app proceeds to authenticate in the Authenticating state under
the Login phase. During authentication, the app moves to
the Service Unavailable state if the service is unavailable.
Upon successful credential verification, and if multi-factor
authentication (MFA) is required, the app transitions to the
MFA Code Pending state; if MFA is not required, or once MFA
verification is complete without errors, the app then transitions
to the Logged In state. However, if MFA verification fails, the
app enters the MFA Error state. The Post-Login phase consists
solely of the Logged In state, indicating successful access to
the app.
We proposed this state machine based on analyzing the
login processes defined in our 44 analyzed Android apps. We
initially examined the login methods supported by each app,
discovering that 38 repositories utilize username and password
authentication, and 18 of these also support MFA. We down-
loaded all available repositories from Google Play to derive
this state machine. We performed login actions for each app
on an Android emulator using Appium [57], a tool designed to
facilitate UI automation that helps identify the current activity
and corresponding method of an app. Subsequent analysis of
the relevant source code revealed the complete process and
the methods involved. We then abstracted the states and their
transitions based on transitions between different methods, the
conditions triggering these method calls, and the subsequent
action. While different apps can have variations in the login
process (e.g. NextCloud [45] allows users to use their domain
name to login), our state machine captures the general login
processes of the Android apps. Login flow errors refer to
improper handling of states or transitions in the login flow.
They were divided into four subcategories, each reflecting
challenges in maintaining the integrity of the login process
through proper state transitions and error handling.
a) Improper Error State Handling: Improper Error State
Handling induced 57 issues where the app did not correctly
handle errors that arose in the login process. An example is is-
sue #7437 from WordPress [44], where users were incorrectly
informed that their email was not registered when a network
error occurred during the login process. This problem was
addressed in a subsequent pull request, correcting the behavior
by displaying a generic network error message instead.
b) Interference with Other State Machines: Android apps
are fundamentally built around the concept of lifecycles, which
manage how activities within the app are created, paused,
and destroyed based on user interactions and system events.
The Android lifecycle can be viewed as a state machine [58],
where each lifecycle state represents a node, and transitions
between these states are triggered by lifecycle events. The
login flow can easily interfere with the lifecycle events as
it involves intensive transitions between Activities. 57 issues
in our dataset were induced by failures to consider such
interference. For example, in Thunderbird [47] and Wikimedia
Commons Android apps [52], users frequently encounter data
loss issues when rotating their devices. Specifically, in Thun-
derbird issue #4936 and Wikimedia Commons issue #3973,
users lose selected account information or entered credentials
because the apps do not save the user input data during
the lifecycle state transitions. When the device is rotated,
the login activity will be destroyed and then recreated. The
data will be lost if the user input data are not stored via
onSaveInstanceState().
c) Missing Login Flow: This category represented 52
issues in which essential steps or states in the login flow
are missing. For example, issue #4462 from NextCloud [45],
which supports user login with multiple accounts, demon-
strated that users could not add a new account without
replacing the previous one. This occurred because app never
updated the boolean variable isFirstRun, a flag to identify
whether it’s the first time to log into the app. As a result, the
app mistakenly believed that it was always the first run, and
consequently, the new account information will overwrite the
previous logged-in information.
d) Incorrect Login Flow: This category involved 48
instances in which an app transits to a state or branch that does

not align with expected behavior, leading to an incorrect login
flow. Incorrect app transition implementations often cause
these issues. A relevant example is issue #219 from Home
Assistant [29]: users encounter a white screen after logging
in. This problem stems from the application’s handling of
PREF_REMOTE_URL, which stores the redirecting URL after
use log in. This issue occurs when a null value is passed
to PREF_REMOTE_URL (e.g. when no URL was input from
a user). Instead of using the existing default URL, the null
value overrides the default one and leads to a white screen,
representing a wrong consequence of the state transition.
2) API Misuse: The misuse of APIs, particularly those
related to authentication, such as Google or Facebook lo-
gin APIs, emerged as a significant root cause. This cate-
gory includes 63 identified issues where developers often
use login-related APIs or their return values incorrectly.
For instance, issue #8525 in NextCloud showed the app
crashing when attempting to login when trying to access a
null token. The issue was induced by using a wrong API
(peekAuthToken) from Android AccountManager. The
developers overlooked that peekAuthToken will immedi-
ately return null if no token is cached for the app. To fix the
issue, blockingGetAuthToken is used instead to ensure
that the application does not proceed without a valid token.
3) Null Object Check Omission: The omission of null
object checks accounts for 39 issues where developers failed to
verify whether an object was null before accessing it. For ex-
ample, in NextCloud [45], issue #9971 reported a crash when
sharing content to NextCloud without a prior login. Previously,
the app directly called getUser(), but this method did not
include a null check. The crash was resolved by updating
the code first to check getUser().isPresent() before
proceeding, ensuring that user information is available.
4) Improper Encoding Algorithm: Incorrect application
of encoding algorithms, such as URL or Base64 en-
coding, induced 23 issues in our dataset. Problems of-
ten arose when an app did not adequately encode spe-
cial characters in user credentials, leading to authentica-
tion errors. For example, in ownCloud [59], issue #2451
involved a login failure when the password contained the
special character “§”. Initially, the code did not specify the
character encoding when creating basic credentials, using
Credentials.basic(mUsername, mPassword). As
a result, this character cannot be encoded. The issue was
fixed by modifying the code to explicitly use UTF-8 en-
coding, changing to Credentials.basic(mUsername,
mPassword, Util.UTF_8), thereby ensuring that all
characters can be correctly handled in the credentials.
5) Wrong Environment Dependency: Finally, 22 issues
were attributed to incorrect environment dependencies,
where login functionalities failed due to being executed
in unsuitable or misconfigured environments, such as spe-
cific Android versions. For example, in Thunderbird issue
#2146 [47], users could not log in and encountered an
SSLHandshakeException after updating to Android 7.0.
The developer explained that this was expected, as SSL
TABLE III
SUMMARY OF LOGI N ISSU E SYMPTOMS
No. Symptoms #Issues
1 Crash 85
2 Login Delays or Timeout 57
3 Incorrect Navigation Flow 51
4 Account Management Function Break 48
5 Credential Rejection 41
6 User Interface Error 40
7 Inaccurate Error Message Displayed 39
cryptography in Android 7.0 is “broken” due to the absence
of certain widely used elliptic curves. They advised users to
upgrade to Android 7.1.1 or higher to resolve the issue.
Answer to RQ1: We identified five categories of common
root causes for login issues in Android apps. The most
prevalent root cause is Login Flow Errors, where the
login flows in the apps are broken due to missing steps,
incorrect state transitions, improper error handling, or
interference with other Android-native state machines such
as the Activity lifecycles.
B. RQ2: Symptoms
Understanding the symptoms of login issues can help de-
velopers design effective test oracles. In investigating login
issues in Android apps, we carefully examined the descriptions
of issues, developer responses, and the differences between
the buggy and fixed code snippets. We identified seven major
categories of symptoms manifested by login issues. The results
are shown in Table III.
1) Crash: 85 of our studied issues are crashes. They
frequently occur due to unhandled exceptions within the login
process, significantly disrupting user experience and under-
mining the application’s reliability. For example, issue #109
of Home Assistant [29] identified that the app crashed when
users tried to paste their username or password into the login
screen. This issue was caused by conflicts with the Localise
SDK, which interfered with clipboard functionality, leading to
unhandled exceptions.
2) Login Delay or Timeout: We documented 57 instances
where users experienced significant delays or timeouts during
the login process. These issues predominantly involve exces-
sive waiting time or complete failures to log in, which can
significantly hinder user experience and service access. For
instance, issue #10043 from WooCommerce [48] mentions a
scenario where users attempting to login Jetpack [60] using
usernames and passwords encounter a premature dismissal of
the WebView before they can approve the connection. This
abrupt interruption prevents successful authentication, leading
to timeouts and disrupting the overall login process.
3) Incorrect Navigation Flow: 51 issues induced incorrect
navigation flows, where users are not directed to the cor-
rect screen after successfully logging in. For example, The
Open Event Attendee Android application [61], developed by
FOSSASIA [50], is designed to facilitate event participation

by allowing users to view event details, book tickets, and
more, directly from their mobile devices. Issue #1762 occurs
when users cannot resume their previous activities, such as
viewing tickets, after successfully logging in. This problem
arises because the application fails to keep track of the user’s
progress. To remedy this, developers need to ensure that the
app retains the user’s last activity state through the login
process, allowing them to return to their actions seamlessly
after authentication.
4) Account Management Function Break: We identified
48 issues as account management function breaks. These
issues are failures in account management functionalities such
as adding or managing multiple accounts. An example is
discussed in Section IV-A1c, where a user is unable to add
a new account.
5) Credential Rejection: 41 issues were reported as creden-
tial rejections where valid login credentials were entered but
mistakenly denied by the apps. For example, issue #10170
from NextCloud [45] demonstrates that the login process
fails when users try to login with the credentials containing
whitespaces. This was induced by the wrong encoding method
of the app.
6) User Interface Error: We identified 40 issues related to
User Interface (UI) errors. UI errors include interface freezes
that prevent user interaction and malfunctioning UI elements,
collectively blocking the login process. For example, issue
#1920 of Open Event Attendee Android [61] exhibits UI
freezing, where the app becomes non-responsive to user input
following Google login initiation. Similarly, issue #1104 of
PocketHub [62] demonstrates UI element malfunction through
an inactive authorization control, where the authorization
button remains disabled during credential submission.
7) Inaccurate Error Message Displayed: 39 issues were
identified where users receive inaccurate or misleading error
messages. These incorrect messages often do not reflect the
underlying problem accurately, inducing user confusion and
frustration. For example, in LibreTube [63], an open-source
video streaming app, issue #3104 documented three scenarios
displaying incorrect error messages when handling authentica-
tion errors. Scenario (A) involved a user incorrectly clicking
the login button without an account, leading to an HTTP 401
displayed. Instead, a user-friendly warning should have been
displayed to explain the problem. In scenario (B), errors occur
when users attempt to re-access the already deleted accounts.
However, the error message indicated that this was a network
error. Scenario (C) described an HTTP 401 displayed when
a user attempted to re-register with the same username and
password. The core issue of all these three scenarios was
the absence of appropriate error messages corresponding to
underlying problems.
To summarize, despite the fact that crashes are the most
prevalent symptoms, they only account for 23.54% of the
studied issues. In other words, around 80% of the login
issues cannot be detected by simply using crashes as the test
oracle. This indicates the need for effective oracles specific
to the login issues. Our symptom categories can serve as
AMFB CR Crash IEMD INF LDT UIE
Symptoms
API Misuse
Improper Encoding Algorithm
Login Flow Error
Null Object Check Omission
Wrong Environment Dependency
Root Causes
3 4 16 2 5 24 9
1 16 0 1 1 3 1
42 19 31 35 41 22 24
2 1 33 0111
0151375
Heatmap of Root Causes vs. Symptoms
0
10
20
30
40
Fig. 3. Heatmap between Root Causes and Symptoms. Abbreviations: AMFB
(Account Management Function Break), Crash (Crash), IEMD (Inaccurate Er-
ror Message Displayed), INF (Incorrect Navigation Flow), UIE(User Interface
Error), CR(Credential Rejection), LDT(Login Delays or Timeout).
TABLE IV
SUMMARY OF TRIGGER CONDITIONS
No. Trigger Conditions #Issues
1 Specific Login Approach 122
2 Account Management Operation 93
3 Specific User Input 86
4 Communication Failure with the Cloud 37
5 Specific Device 30
6 Setting Change 20
7 Orientation Change 18
8 User Re-Login 15
9 No Specific Trigger Conditions 38
the guideline for designing such oracles. Figure 3 depicts a
heatmap between root causes and symptoms analysis. Notably,
in every category of symptoms, login flow errors are always
the leading cause, demonstrating their significance in ensuring
the reliability of the login processes in Android apps.
Answer to RQ2: Our analysis results indicate that login
issues can exhibit a variety of symptoms. Around 80% of
the login issues do not exhibit crashes when triggered. This
highlights the importance of designing effective test oracles
to expose login issues. Our categories can serve as the
guidelines for designing such test oracles.
C. RQ3:Trigger Conditions of Login Issues
Understanding the trigger conditions of login issues is cru-
cial for designing effective test cases to expose login issues. In
RQ3, we aim to identify the trigger conditions of login issues
by analyzing the bug reports, code revisions, and discussions
between users and developers within our dataset.
Unlike root causes and symptoms,a single issue can require
multiple conditions to trigger. As a result, the categories of
trigger conditions for an issue are not mutual exclusive. This
approach resulted in nine common trigger conditions, with a
summary shown in Table IV.
1) Specific Login Approach: The most frequent trigger
condition was associated with specific login approaches, ac-

counting for 122 issues. Issues in this category can only be
triggered under specific login approaches (e.g., using specific
third-party login services or using MFA). For example, issue
#4393 in Tusky [51] described how selecting the Akkoma
account type for login led to an app crash. This example
highlights the necessity of comprehensive test coverage for
each supported login approach to prevent functional disrup-
tions across different authentication scenarios.
2) Account Management Operation: Account management
operations triggered 93 issues, where account management
actions such as account creation, deletion, and account
switch triggered problems. For example, issue #6481 from
NextCloud [45] is triggered when users try to add a new
account to the app. This suggests the importance of covering
the different account management operations in testing login
issues.
3) Specific User Input: 86 issues required specific inputs to
trigger. These issues often arose from scenarios where special
characters or unexpected data types in login forms. The issue
we discussed in Section IV-B5 is an example. The developers
may not anticipate all the variants of the user input, and such
issues are triggered. Consequently, test cases including special
characters or data types are necessary for login issue testing.
4) Communication Failure with the Cloud: Communication
failures with cloud services triggered 37 issues. These issues
often occur during synchronization processes or when fetching
authentication tokens. This trigger condition indicates the
dependency on external cloud infrastructures and the need for
effective handling of network-related uncertainties.
5) Specific Device: Device-specific conditions accounted
for 30 issues involving various hardware configurations or
operating system versions. These issues are essentially com-
patibility issues occurring in the login process [?], [37]. This
highlights the challenges in developing robust applications
across diverse hardware and software ecosystems. To avoid
issues triggered by device-specific conditions, developers must
execute all test cases on a range of devices with different
operating system versions before releasing updates.
6) Setting Changes: 20 issues were triggered by changes
in the app settings, including privacy setting updates or
security configurations that inadvertently impacted the login
functionality. This calls for testing the login functionalities
under different settings.
7) Orientation Change: 18 issues required device orienta-
tion changes to trigger, illustrating problems that occur when
apps fail to handle changes in device orientation (i.e., changes
in Activity lifecycles) during login processes. This condition
highlights the need for responsive design strategies that ensure
seamless user experiences regardless of device orientation. It
also calls for the developers to properly handle the interference
between the login flow and the Activity lifecycles.
8) User Re-Login: 15 issues were triggered only when
users make a second attempt to log into the app. This includes
situations where users aim to change the account or add a
new account. This trigger condition points to the necessity of
designing test cases to re-login in a short period.
9) No Specific Trigger Conditions: Finally, there are 38
issues that do not require any specific trigger conditions. These
issues can be triggered by any user login attempts.
AMFB CR Crash IEMD INF LDT UIE
Symptoms
Account Management Operation
Communication Failure with the Cloud
No Specific Trigger Conditions
Orientation Change
Setting Changes
Specific Device
Specific Input
Specific Login Approach
User Re-Login
Trigger Conditions
41 121 9 11 4 6
3 2 8 7 4 10 3
2 2 11 5 11 3 4
0060714
2383103
0 1 13 0 1 11 4
427 14 13 8 12 9
10 16 25 12 19 25 15
3000660
Heatmap of Trigger Conditions vs. Symptoms
0
5
10
15
20
25
30
35
40
Fig. 4. Heatmap between Trigger Conditions and Symptoms. Abbreviations:
AMFB (Account Management Function Break),Crash (Crash), IEMD (Inac-
curate Error Message Displayed), INF (Incorrect Navigation Flow), UIE(User
Interface Error), CR(Credential Rejection), LDT(Login Delays or Timeout).
Our results show that the majority (89.7%) of the login
issues require complicated conditions to trigger. This high-
lights the complexity in testing login issues. Furthermore, the
heatmap presented in Figure 4 correlates trigger conditions
with symptoms, guiding developers in designing effective test
cases. For instance, the heatmap suggests that login delays or
timeouts can be tested through a combination of four main
conditions: specific login approaches, specific input, specific
device and communicating with could failures. Developers are
advised to create test cases that incorporate special character
inputs across all designated login approaches and execute
these under diverse network scenarios to simulate and address
potential failures.
Answer to RQ3: The majority (89.7%) of the studied login
issues require complicated conditions to trigger, highlight-
ing the difficulties in triggering and testing login issues in
Android apps. Our analysis identified nine common trigger
conditions. The predominant conditions include specific
login approaches, account management operations and
specific inputs. Our summarized trigger conditions can
guide developers to better test their app login processes.
D. Implications
The findings from our study emphasize the importance of
login flow errors in the context of login issues within Android
apps. Login flow errors are the primary root causes for our
studied issues, accounting for 59.28%. In this section, we fur-
ther investigate the impact of login flow errors by correlating
them with the issue symptoms and trigger conditions.
1) Root Causes and Symptoms: As shown in Figure 3,
unlike other root causes that typically correspond to specific
symptoms (e.g., null object check omission always induce
crashes), login flow errors can trigger every type of symptom
identified in our study. This broad impact suggests that issues

in login flows can manifest in various detrimental ways. Here
we use examples to illustrate how login flow errors induced
two types of symptoms as examples:
1Incorrect Navigation Flow: Login flow errors induced
41 incidents of incorrect navigation flow. The issue mentioned
in Section IV-B3 reports that users are unable to resume their
previous activities after logging in. The root cause of this
issue is Interference with Other State Machines. The app did
not use savedInstanceState to save the activity before
starting to login, resulting in information loss. To fix this
issue, the developers implemented a solution where the user’s
current activity state is saved before authentication. Upon
successful login, the application restores the previously saved
state, allowing users to seamlessly continue from where they
left off.
2Inaccurate Error Messages: 35 inaccurate error mes-
sage issues were induced by login flow errors. In Sec-
tion IV-B7, we discussed an issue in LibreTube where error
messages do not match the underlying root causes. The root
cause of this issue is Improper Error State Handling. The login
flow transits to incorrect error states and the app did not give
precise error messages in the the error-handling logic.
2) Root Causes and Trigger Conditions: As shown in
Figure 4, login flow errors can be triggered by all kinds of con-
ditions. In addition, they often require a confluence of multiple
trigger conditions to manifest, suggesting their complex nature
in issue triggering. Here are two examples where multiple
conditions are required simultaneously to trigger login flow
issues:
1Thunderbird [47] is an open-source email client de-
veloped by Mozilla that supports multiple email accounts,
management, and protocols, making it popular for personal
and professional communication. In email systems, the port
number is critical as it dictates the communication endpoint for
a server. Different email services use specific ports to handle
various email protocols. For instance, IMAP typically uses
port 143 or the encrypted 993. The root cause of issue #5088
in Thunderbird [64] is identified as Missing Login Flow. The
developers missed the process in the login flow to update the
port number according to the protocol set by the new account
when users switch between email accounts. This problem
can be triggered when three conditions are satisfied: 1) the
user adds a new account (Account Management Operation),
2) initially sets up the account using the IMAP protocol
(Specific Login Approach), and 3) inputs a specific server
address (Specific input). These steps inadvertently lead to a
situation where the port number from the previous account
setup persists, causing connection issues or incorrect email
data retrieval.
2AntennaPod [65] is an open-source podcast manager
that allows users to sync their podcast data across devices
using various login and synchronization methods, including
NextCloud [45]. Issue #5841 has been documented within An-
tennaPod’s integration with NextCloud [66]. This integration
requires users to provide a server URL for syncing data. In
this issue, despite users entering the correct server URL, they
encounter persistent login failures. The root cause is identified
as Missing Login Flow because the developers did not design
the login flow for the input URLs with different certificates.
This problem is triggered when three conditions are satisfied:
1)the device must have Gpoddersync installed (Specific
Device), 2) NextCloud selected as the sync and login approach
(Specific Login Approach), and 3) the entered URL must
support HTTPS certificates (Specific Input). The necessity for
an HTTPS-supportive URL suggests that security protocols,
particularly those related to SSL/TLS certificate verification,
may be obstructing the login process. This issue can lead
to unsuccessful authentication and synchronization, severely
affecting the user experience and functionality of the app.
In conclusion, our study results reveal the pivotal role
of login flow errors in compromising the functionality and
security during the login process of Android applications.
3) Findings: To summarize, the login flow errors can cause
a wide range of symptoms, from login delays or timeouts
to system crashes, and require the intersection of multiple
conditions to trigger. This indicates that further research should
focus on login flow errors when testing for login issues in An-
droid apps. First, to tackle these issues, it is essential to under-
stand the states and transitions involved in the login flow and
develop models that accurately represent these dynamics. Our
proposed state machine (Figure 2) is a first attempt to achieve
this goal. Second, our results assist developers in identifying
the causes of problems and designing targeted test cases. For
instance, if users report an Incorrect Navigation Flow issue,
developers should focus on login flow errors and verify the
logical sequence of state transitions. Additionally, developers
can design tests that include special character inputs for all
supported login methods and incorporate device orientation
changes to assess the Incorrect Navigation Flow. Third, our
taxonomy of issue symptoms can help define effective test
oracles. For instance, we identified 39 issues of “Inaccurate
Error Message Displayed”. This indicates that developers can
design test oracles to verify whether error messages accurately
correspond to actual failures like invalid credentials or expired
sessions. Such test cases not only confirms issue fidelity for
users but also ensures that the application’s logic proactively
manages these errors, thus improving both the reliability and
user experience of the apps’ login process.
V. RE LATED WORKS
A. Empirical Study On Other Issues in Android
Several studies have explored the challenges and bugs in
Android apps, focusing on issues related to user accessi-
bility [67], GUI [68], and configuration [69]. Additionally,
numerous investigations into Android testing have been con-
ducted. Fabiano et al. [70], Lin et al. [71], and Xiong et al. [36]
provide empirical studies on functional bugs in Android apps,
though their focus remains predominantly on common bugs
rather than specific login-related issues which critically im-
pact user login. Ardito et al. [72] present an automated test
selection framework for Android apps based on APK and

activity classification, while Yan et al. [73] propose a multiple-
entry testing framework by constructing activity-launching
contexts. Furthermore, Bose et al. [74] propose a systematic
callback exploration framework for Android testing. Despite
the advancements in testing techniques, these tools often do
not fully address the complex features of login processes, such
as authentication and session management, which are critical
areas that our study specifically targets.
These studies, while comprehensive in their scope, often
overlook the nuanced complexities of login mechanisms and
their repercussions on security and usability. Our research
aims to fill this gap by focusing specifically on the systematic
analysis of login issues, offering new insights into their causes,
symptoms, and triggers that can inform more effective testing
and development practices for login processes.
B. Studies On Android Authentication Problems
Several studies have also focused on the authentication
processes in Android apps, yet none have conducted a com-
prehensive and systematic investigation of the entire login
process. Wan et al. [75] attempt to test user interfaces (UIs)
within mobile applications, including those for login screens.
However, their tools are unable to adequately handle UIs that
require user input, such as entering usernames and passwords,
posing significant challenges in fully automating the testing
process for such critical components. Song et al. [76] devel-
oped VPDroid, a platform designed to test the automatic login
features of Android apps. While their approach effectively
evaluates the security of apps that rely on device consistency
checks for auto-login functionalities, it does not extend to
other login scenarios such as Google login or server address
authentication, which are covered in our study. Several studies
focus on specific login approaches, Ma et al. [77] conducted
an empirical study on one-time password authentication in
Android. Jannett et al. [26] developed a tool called SoK
focused on Single Sign-on in Android. Shi et al. [27] propose
MoSSOT, a black box tester for OAuth. In addition, Tamjid
et al. [28] conducted an empirical study on the usage of
OAuth APIs and their implications for mobile security, leading
to the development of OAUTHLINT, a tool that employs
query-driven static analysis to identify vulnerabilities in OAuth
implementations on the Google Play marketplace. While these
studies offer significant insights into various aspects of login
and authentication mechanisms within Android apps, they
typically focus on specific components or security aspects.
This narrow focus often bypasses the comprehensive chal-
lenges presented by the entire login process, particularly in
how different authentication methods integrate and operate
under diverse conditions. Our research seeks to bridge this
gap by conducting a systematic and holistic analysis of the
login process across authentication scenarios, not just limited
to OAuth or single sign-on systems. By doing so, we aim to
provide a more complete understanding of the functionality
issues that can arise during user login in Android apps.
VI. TH RE ATS TO VALIDITY
Data Source and Diversity: While we have exclusively
sourced our repositories from GitHub and all are open-
sourced, this may limit the generalizability of our findings.
However, our dataset includes a diverse array of app cate-
gories, enhancing its representativeness. For example, we have
categorized apps into productivity tools like Orgzly [78] and
nextcloud [45], social media apps such as Duckduckgo [79]
and Facebook Android SDK [80], multimedia applications like
Pocket Casts [81] and AntennaPod [65], and security-focused
apps including Password Store [82] and Aegis [83]. Accord-
ing to Table 1, the selected repositories are highly popular,
evidenced by high numbers of GitHub stars and extensive
download numbers on Google Play. These repositories are also
well-maintained, further attesting to the reliability of our data.
Classification Subjectivity: The categorization of apps was
performed manually, which could introduce bias. To mitigate
this, we employed an open coding approach, with discrepan-
cies resolved through discussions among the research team.
The inter-rater reliability, measured by Cohen’s kappa, was
0.81, indicating substantial agreement and reliability in our
classification method.
Platform Specificity: Our study focuses solely on Android
apps. While this provides in-depth insights into state man-
agement issues within this platform, the findings may also
apply to other platforms due to the generic nature of login
functionalities. This suggests that the problems identified,
while analyzed in the context of Android, could potentially
manifest in similar ways on other operating systems, thus
providing a broader relevance to our conclusions.
VII. CONCLUSION AND FUTURE WOR KS
In this paper, we conduct an empirical study of 361 login
issues from 44 widely-used open-source Android apps. Our
research discloses the common root causes and symptoms
of Android login issues and explores the various factors that
trigger these problems. The insights gained from our study are
crucial for guiding future research into testing and diagnosing
Android login issues. Moving forward, we aim to expand our
dataset for a larger-scale empirical analysis. Building on our
current findings, we also plan to develop a dynamic analysis
tool that models the login processes using state-machines. In
addition, we plan to generate both test oracles and test cases,
aligning with the patterns identified in our study.
VIII. ACKNOWLEDGMENT
We thank the anonymous reviewers for their insightful
comments on the paper. This work was supported by Nat-
ural Sciences and Engineering Research Council of Canada
Discovery Grant (Grant No. RGPIN-2022-03744 and Grant
No. DGECR-2022-00378), FRQNT/NSERC NOVA program
(Grant No. 2024-NOVA-346499) and National Natural Science
Foundation of China (Grant No. 62372219).

REFERENCES
[1] B. Alsanousi, A. S. Albesher, H. Do, and S. Ludi, “Investigating the user
experience and evaluating usability issues in ai-enabled learning mobile
apps: An analysis of user reviews,” International Journal of Advanced
Computer Science and Applications, vol. 14, no. 6, 2023.
[2] N. Bozovic. (2023) First-time user experience (ftue): Why it matters &
how to improve it. [Online]. Available: https://www.chameleon.io/blog/
first-time- user-experience
[3] M. Vilina. (2022) 5 reasons users fail to engage
with your app. [Online]. Available: https://tracker.my.com/blog/
5-reasons- users-fail- to-engage-with-your-app?lang=en
[4] C. Laura. (2024) Mobile app usage - statistics &
facts. [Online]. Available: https://www.statista.com/topics/1002/
mobile-app- usage/#topicOverview
[5] P. Weichbroth, “Usability of mobile applications: A systematic literature
study,” IEEE Access, vol. 8, pp. 55 563–55 577, 2020.
[6] S. McElroy, “Identifying android banking malware through measurement
of user interface complexity,” in CSR, 2024, pp. 348–353.
[7] G. Sciarretta, R. Carbone, S. Ranise, and L. Vigan`
o, “Formal analysis
of mobile multi-factor authentication with single sign-on login,” ACM
Trans. Priv. Secur., vol. 23, no. 3, Aug. 2020. [Online]. Available:
https://doi.org/10.1145/3386685
[8] H. Huang, C. Xu, M. Wen, Y. Liu, and S.-C. Cheung, “Conffix:
Repairing configuration compatibility issues in android apps,” in ISSTA,
2023, pp. 514–525.
[9] T. Mahmud, M. Che, and G. Yang, “Detecting android api compatibility
issues with api differences,” TSE, vol. 49, no. 7, pp. 3857–3871, 2023.
[10] S. Yang, S. Chen, L. Fan, S. Xu, Z. Hui, and S. Huang, “Compatibil-
ity issue detection for android apps based on path-sensitive semantic
analysis,” in ICSE. IEEE, 2023, pp. 257–269.
[11] J. Chen, K. Li, Y. Chen, L. Wei, and Y. Liu, “Demystifying device-
specific compatibility issues in android apps,” in ICSME, 2024.
[12] T. Luo, H. Hao, W. Du, Y. Wang, and H. Yin, “Attacks on webview in
the android system,” in ACSAC, 2011, pp. 343–352.
[13] J. Hu, L. Wei, Y. Liu, S.-C. Cheung, and H. Huang, “A tale of two cities:
How webview induces bugs to android applications,” in ASE, 2018, pp.
702–713.
[14] J. Hu, L. Wei, Y. Liu, and S.-C. Cheung, “ωtest: Webview-oriented
testing for android applications,” in ISSTA, 2023, pp. 992–1004.
[15] M. Steinb ¨
ock, J. Bleier, M. Rainer, T. Urban, C. Utz, and M. Lindorfer,
“Comparing apples to androids: Discovery, retrieval, and matching of ios
and android apps for cross-platform analyses,” in MSR. IEEE, 2024,
pp. 348–360.
[16] H. Chen, D. Chen, Y. Liu, X. Sun, and L. Li, “Are your android app
analyzers still relevant?” in MOBILESoft, 2024, pp. 69–73.
[17] S. Yu, C. Fang, Y. Yun, and Y. Feng, “Layout and image recognition
driving cross-platform automated mobile testing,” in ICSE. IEEE, 2021,
pp. 1561–1571.
[18] P. Philippaerts, D. Preuveneers, and W. Joosen, “Oauch: Exploring
security compliance in the oauth 2.0 ecosystem,” in RAID. As-
sociation for Computing Machinery, 2022, p. 460–481.
[19] T. Sutter, T. Kehrer, M. Rennhard, B. Tellenbach, and J. Klein, “Dynamic
security analysis on android: A systematic literature review,” IEEE
Access, vol. 12, pp. 57 261–57 287, 2024.
[20] M. Jimenez, M. Papadakis, T. F. Bissyand´
e, and J. Klein, “Profiling
android vulnerabilities,” in QRS, 2016, pp. 222–229.
[21] P. Bhat and K. Dutta, “A survey on various threats and current state of
security in android platform,” ACM Comput. Surv., vol. 52, no. 1, Feb.
2019.
[22] D. Wu, D. Gao, E. K. T. Cheng, Y. Cao, J. Jiang, and R. H. Deng,
“Towards understanding android system vulnerabilities: Techniques and
insights,” in CCS. Association for Computing Machinery, 2019, p.
295–306.
[23] J. Zhu, K. Li, S. Chen, L. Fan, j. wang, and X. Xie, “A comprehensive
study on static application security testing (sast) tools for android,” TSE,
pp. 1–18, 2024.
[24] M. Linares-V´
asquez, G. Bavota, and C. Escobar-Vel ´
asquez, “An empir-
ical study on android-related vulnerabilities,” in MSR, 2017, pp. 2–13.
[25] S. Chen, Y. Zhang, L. Fan, J. Li, and Y. Liu, “Ausera: Automated
security vulnerability detection for android apps,” in ASE. Association
for Computing Machinery, 2023.
[26] L. Jannett, M. Westers, T. Wich, C. Mainka, A. Mayer, and V. Mladenov,
“Sok: Sso-monitor - the current state and future research directions in
single sign-on security measurements,” in EuroS&P, 2024, pp. 173–192.
[27] S. Shi, X. Wang, and W. C. Lau, “Mossot: An automated blackbox
tester for single sign-on vulnerabilities in mobile applications,” in CCS.
Association for Computing Machinery, 2019, p. 269–282.
[28] T. A. Rahat, Y. Feng, and Y. Tian, “Oauthlint: An empirical study on
oauth bugs in android applications,” in ASE, 2019, pp. 293–304.
[29] (2024) home-assistant-android. [Online]. Available: https://github.com/
home-assistant/android
[30] (2020) Home assistant issue: Blank white screen after login. [Online].
Available: https://github.com/home-assistant/android/issues/219
[31] (2024) Dataset and scripts. [Online]. Available: https://github.com/
dhqodqiwde/Android-Login- Analysis
[32] N. Anbalagan, R. A. Abbas Helmi, M. A. Hameed Ashour, and A. Jamal,
“Trusted application using biometrics for android environment,” in
CSPA, 2020, pp. 7–12.
[33] (2024) Authenticate users with sign in with google. [Online]. Available:
https://developer.android.com/identity/sign-in/credential-manager-siwg
[34] (2024) Facebook login for android - quickstart. [Online]. Available:
https://developers.facebook.com/docs/facebook-login/android/
[35] H. A. Rahman and N. Yulianti, “Implementation a passwordless and
multi factor authentication (mfa) mechanism for enhancing login security
in android applications,” in ICIMCIS, 2023, pp. 206–211.
[36] Y. Xiong, M. Xu, T. Su, J. Sun, J. Wang, H. Wen, G. Pu, J. He, and
Z. Su, “An empirical study of functional bugs in android apps,” in ISSTA.
Association for Computing Machinery, 2023, p. 1319–1331.
[37] L. Wei, Y. Liu, and S.-C. Cheung, “Taming android fragmentation:
Characterizing and detecting compatibility issues for android apps,” in
ASE, 2016, pp. 226–237.
[38] (2024) github. [Online]. Available: https://github.com.
[39] (2022) github search api. [Online]. Available: https://docs.github.com/
en/rest/search/search?apiVersion=2022-11- 28
[40] F.-X. Geiger, I. Malavolta, L. Pascarella, F. Palomba, D. Di Nucci, and
A. Bacchelli, “A graph-based dataset of commit history of real-world
android apps,” in MSR, 2018, pp. 30–33.
[41] P. Liu, L. Li, Y. Zhao, X. Sun, and J. Grundy, “Androzooopen: Collecting
large-scale open source android apps for the research community,” in
MSR, 2020, pp. 548–552.
[42] A. Aizawa, “An information-theoretic perspective of tf–idf measures,”
Information Processing & Management, vol. 39, no. 1, pp. 45–65, 2003.
[43] (2024) Nltk stopwords. [Online]. Available: https://www.nltk.org/howto/
portuguese en.html#stopwords
[44] (2024) Wordpress. [Online]. Available: https://github.com/
wordpress-mobile/WordPress-Android
[45] (2024) nextcloud-android. [Online]. Available: https://github.com/
nextcloud/android
[46] (2024) element-android. [Online]. Available: https://github.com/
element-hq/element- android
[47] (2024) thunderbird-android. [Online]. Available: https://github.com/
thunderbird/thunderbird-android
[48] (2024) woocommerce-android. [Online]. Available: https://github.com/
woocommerce/woocommerce-android
[49] (2024) Firebaseui-android. [Online]. Available: https://github.com/
firebase/FirebaseUI-Android
[50] (2024) fossasia. [Online]. Available: https://github.com/fossasia
[51] (2024) Tusky. [Online]. Available: https://github.com/tuskyapp/Tusky
[52] (2024) apps-android-commons. [Online]. Available: https://github.com/
commons-app/apps- android-commons
[53] (2024) Anki-android. [Online]. Available: https://github.com/ankidroid/
Anki-Android
[54] (2024) phimpme-android. [Online]. Available: https://github.com/
fossasia/phimpme-android
[55] (2024) element-x-android. [Online]. Available: https://github.com/
element-hq/element- x-android
[56] (2024) davx5-ose. [Online]. Available: https://github.com/bitfireAT/
davx5-ose
[57] (2024) Appium. [Online]. Available: https://appium.io/docs/en/latest/
[58] (2024) Google android developer document. [Online]. Available: https:
//developer.android.com/reference/android/arch/lifecycle/Lifecycle.State
[59] (2024) owncloud. [Online]. Available: https://github.com/owncloud
[60] (2024) Jetpack. [Online]. Available: https://jetpack.com/
[61] (2024) open-event-attendee-android. [Online]. Available: https://github.
com/fossasia/open-event-attendee- android
[62] (2024) Pockethub. [Online]. Available: https://github.com/pockethub/
PocketHub

[63] (2024) libre-tube/libretube. [Online]. Available: https://github.com/
libre-tube/LibreTube
[64] (2021) Thunderbird issues: Port isn’t changed when switching
account types. [Online]. Available: https://github.com/thunderbird/
thunderbird-android/issues/5088
[65] (2024) Antennapod/antennapod. [Online]. Available: https://github.com/
AntennaPod/AntennaPod
[66] (2022) Antennapod issues: Relogin very fast fails. [Online]. Available:
https://github.com/AntennaPod/AntennaPod/issues/5841
[67] S. Chen, C. Chen, L. Fan, M. Fan, X. Zhan, and Y. Liu, “Accessible
or not? an empirical investigation of android app accessibility,” TSE,
vol. 48, no. 10, pp. 3954–3968, 2022.
[68] K. Moran, M. L. V´
asquez, and D. Poshyvanyk, “Automated gui testing
of android apps: From research to practice,” in ICSE-C, 2017, pp. 505–
506.
[69] A. K. Jha, S. Lee, and W. J. Lee, “An empirical study of configuration
changes and adoption in android apps,” Journal of Systems and Software,
vol. 156, pp. 164–180, 2019.
[70] F. Pecorelli, G. Catolino, F. Ferrucci, A. De Lucia, and F. Palomba,
“Software testing and android applications: a large-scale empirical
study,” Empirical Software Engineering, vol. 27, no. 2, p. 31, 2022.
[71] J.-W. Lin, N. Salehnamadi, and S. Malek, “Test automation in open-
source android apps: a large-scale empirical study,” in ASE. Association
for Computing Machinery, 2021, p. 1078–1089.
[72] L. Ardito, R. Coppola, S. Leonardi, M. Morisio, and U. Buy, “Automated
test selection for android apps based on apk and activity classification,”
IEEE Access, vol. 8, pp. 187 648–187 670, 2020.
[73] J. Yan, H. Liu, L. Pan, J. Yan, J. Zhang, and B. Liang, “Multiple-
entry testing of android applications by constructing activity launching
contexts,” in ICSE. Association for Computing Machinery, 2020, p.
457–468.
[74] P. Bose, D. Das, S. Vasan, S. Mariani, I. Grishchenko, A. Continella,
A. Bianchi, C. Kruegel, and G. Vigna, “Columbus: Android app testing
through systematic callback exploration,” in ICSE, 2023, pp. 1381–1392.
[75] M. Wan, N. Abolhassani, A. Alotaibi, and W. G. J. Halfond, “An
empirical study of ui implementations in android applications,” in
ICSME, 2019, pp. 65–75.
[76] W. Song, J. Ming, L. Jiang, H. Yan, Y. Xiang, Y. Chen, J. Fu, and
G. Peng, “App’s auto-login function security testing via android os-level
virtualization,” in ICSE, 2021, pp. 1683–1694.
[77] S. Ma, R. Feng, J. Li, Y. Liu, S. Nepal, Diethelm, E. Bertino, R. H.
Deng, Z. Ma, and S. Jha, “An empirical study of sms one-time password
authentication in android apps,” in ACSAC. Association for Computing
Machinery, 2019, p. 339–354.
[78] (2024) orgzly. [Online]. Available: https://github.com/orgzly/
orgzly-android
[79] (2024) duckduckgo. [Online]. Available: https://github.com/duckduckgo/
Android
[80] (2024) facebook/facebook-android-sdk. [Online]. Available: https:
//github.com/facebook/facebook-android-sdk
[81] (2024) Pocket casts. [Online]. Available: https://github.com/Automattic/
pocket-casts- android
[82] (2024) Password-store. [Online]. Available: https://github.com/
android-password- store/Android-Password-Store
[83] (2024) Aegis. [Online]. Available: https://github.com/beemdevelopment/
Aegis