[MUSIC PLAYING] JAYANTI DABHERE:
Hello, everyone, and thank you for joining me at
Google I/O. My name is Jayanti, and I'm a Software Engineer
at Firebase Crashlytics. Whether you're an
existing Crashlytics user or just starting to
learn more about Crashlytics, welcome. Crashlytics is a leading mobile
crash reporting platform, and as a team, we think
about app stability a lot. We have been hard at work
to help you find and fix those pesky crashes. That way, you can spend more
time building apps and games that users love. Whether you double
up on Android, Apple, Flutter, or games, we have some
exciting updates for you today. Let's dive right into it. This year at Google I/O,
we are excited to show you how we are strengthening the
mobile ecosystem by integrating Crashlytics with Google's most
popular developer products and making our
platform work better with an open ecosystem of
languages and frameworks. There are two key legs of a
crash troubleshooting journey-- finding the crashes that
are most important to fix, fixing crashes by identifying
the offending lines in the code base. Finding a crash is way
harder than it sounds. Even with Crashlytic's
prioritized list of crashes, some of the most impactful
crashes can be a mess. Fixing not only requires
a detailed stack trace report but also
additional information to get to the bottom
of the root cause. To address these, I have some
exciting updates lined up for you in these areas. I'm going to showcase
brand new features in Android Studio's App
Quality Insights window. For native apps and
games, we not only have exciting features to
address those tricky memory errors, but also multiple
strategies improvements to help map the crash report
to the exact line and file in your code base. And last but not the least,
fundamental transformation of our crash grouping algorithm. Let's look at some of the
ways we are helping you find the most important
issues in your app, starting with Android Studio. Last year at Google I/O, we
announced the canary launch of App Quality
Insights window, which lets you view and address
Crashlytics reports right from Android Studio. We have seen an incredible
response from the Android community, and it's amazing
to hear how it's streamlining the team's workflows. In addition to the clickable
stack traces and issues list, you told us that finding and
managing issues was still challenging. We have heard your
feedback and are excited to share these updates. First, we are making it easier
to find and filter crashes by letting you select the
play track for the latest version of your app or
via Crashlytics signal to identify the most important
issues affecting your users. With Notes, you can
collaborate with your team and record your
findings to keep them up to date with the
status of your bug fix. And when you have
finally fixed the crash, you can now close the issue
right from Android Studio. We are happy to announce that
we are graduating these latest beloved features
in Android Studio Flamingo to the stable channel. We hope you and your team
take advantage of these and let us know what you think. If your Android app
uses native code, C++ memory management issues
are the most common and some of the trickiest bugs
in Android software. Not only that, they account for
over 60% of Android's security vulnerabilities and for millions
of user visible crashes, leading to high lifetime
development costs for your app. To help address memory
related crashes, Crashlytics now
supports GWP-ASan. GWP-ASan is an
address sanitizer that helps you find and fix memory
bugs such as use after free and buffer overflow in
production environments. GWP-ASan can be enabled
with a few simple steps, and once enabled for
your app, Crashlytics highlights crashes with GWP-ASan
reports using a new signal. You can quickly filter
your issues list using that signal
to find crashes that have GWP-ASan data. When you navigate to the
issue, after clicking on the new memory
stack trace tab, you will see a full
GWP-ASan report with allocated and
deallocated stack traces right next to the crash thread. We also provide an insight
specific to the cause of the memory
error, for example, use after free, that provides
an explanation of the cause so you don't have to worry
about what to do next. All right, now that we have
identified what crashes to fix, it's time to squash those bugs. Let's look at some of
the ways Crashlytics is making stack
traces even better to help debug and
fix these crashes. Development platforms are
becoming more complex, making it harder to
map the crash report to the line in your code base. To keep up with these
changes, Crashlytics is continuing to improve
the quality of stack traces by making the
crashes look exactly like the code you wrote. For native apps, in addition
to providing memory state traces via GWP-ASan reports,
we have made improvements so that native stack traces
are even more detailed, helping you find the exact file
and line number of the code. ANRs that contain
threads with native code are now fully symbolicated. And if your app is
a Unity game, we have made IL2CPP
frames more meaningful by adding translations
for lambdas, generics, local functions, and types. For languages like
Swift and Kotlin, the compiler
generates extra frames that makes it challenging
to navigate the stack trace and get to the root
of the problem. To help you deal
with such cases, we have greatly improved
our symbolication engine so that these compiler generated
frames now have an exact line and file number. Here is an example of
the Swift stack trace before and after improvement. To uplift the quality
of your stack traces using these
improvements, upgrade now to the latest Crashlytics
SDKs and Gradle plugin. Now, as we all know,
having detailed stacked traces is sometimes not
enough to fully understand a tricky crash. An app can crash
in similar ways, generating almost
identical state traces. Crashes that have a
common point of failure can come from
different code paths, making it even harder to get
to the bottom of the bug. Don't worry, we
are here to help. Crashlytics already
groups crashes with similar stack
traces into issues. To group crashes that have same
failure point and similar stack traces, we are now
introducing a new subgrouping called variants. With variants, you'll
be one step closer in identifying the root cause
of these pervasive crashes. Let's look at an example
where variants can accelerate your crash debugging. As a developer, I want to get
to the bottom of this issue, but the issue consists
of hundreds of events, so I have to manually cycle
through each of those. Not anymore. With Crashlytics
variants, you can see an indication of the
variants right on the issues list with a revamped
metadata like package name. Diving even deeper, now I
can see stack traces grouped together into several variants,
also indicating the user impact of each variant. A quick glance at
the stack trace and I can already see multiple code
paths affecting this issue. I also know which
one to focus on first based on one
impacting most users or happening the most
frequently in my app. In addition to
introducing variants, we have fundamentally
transformed our crash grouping algorithm. The way that we
have grouped crashes has remained unchanged
for many years, and we set out to
improve it to solve some of the known problems. With these enhancements,
you will now see-- fewer duplicates, a
line number change doesn't cause a new issue; more
meaningful alerts and signals, since a new issue
actually represents a new bug; a more
powerful search-- each issue contains
more searchable metadata like exception type
and package name. All right, with the help
of variants and new crash grouping, now I finally
know the offending line of code in my app. Let's go to the Android Studio
and finally fix this bug. Hmm, it seems like the
code on that line number has been refactored
since the crash occurred, and the code looks very
different from the one in the crash report. Today, we are happy to
give you an early glimpse of a new feature in
App Quality Insights. To improve on one of the
most popular clickable strack trace features, we're
now adding support for navigating to the version
of your app at the blamed commit, point in time
when the crash happens, so that you can
compare the current and blamed commit
version to get an insight of the state of the code
base when the crash happened. This feature is now available
in Android Studio Hedgehog's canary channel. We hope you give this a try
and let us know what you think. As you saw, we have made
a ton of improvements to make Crashlytics work better
with popular Google Developer products and open ecosystem
of languages and frameworks. To summarize, here is
what we have covered-- App Quality Insights features on
Android Studio, new Crashlytics signal, and memory
stack traces as part of GWP-ASan support,
improved stack traces across popular
languages and platforms, and updated crash grouping
algorithm and a new feature called variant. We're continuing to adapt
and improve Crashlytics to give you a full service
experience for your app stability issues across
various platforms and devices. No matter what stage of
app development you're in, we are here for you. We can't wait to hear what
you think of these updates. Don't forget to upgrade to
the latest Crashlytics SDK and Gradle plugin. Thank you for joining
me today, and we'll see you at the next I/O. [MUSIC PLAYING]
