[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]