Skip to main content

Introduction

💡Try the Sandbox
Try an interactive sandbox where you can explore Memfault without having to sign up.

Memfault is a Device-centric Fleet observability and OTA platform, that can be integrated into any Device running AOSP, including those requiring GMS certification, allowing both developers and managers to quickly understand and debug Device Stability, product usage, and more.

SDKs are available for Android 8-14. Running a different version of Android? Feel free to let us know!

What does Memfault do?​

Bugreport Capture​

Android bug reports can be triggered for collection and uploaded to Memfault, for download and post-processing.

Device-wide Issue Monitoring​

Kernel panics, Tombstones, JVM Exceptions, ANRs, WTFs, SELinux violations, and more, from every app and service on the Device, from the user and the kernel space, are collected and intelligently grouped together into Issues, to help understand the trends over time, and between Releases.

Device-level Metrics​

Device-centric metrics like Battery Life, Wi-Fi and Network Connectivity, Network Usage, Disk Availability, CPU and Memory utilization, Disk Wear, Device Thermals, Thermal Throttling rates, and more, are collected across the entire fleet, to help understand the trends over time, and between Releases.

Smart Log Cache​

All types of logs on the device, including from the kernel buffer or from system apps and services, can be collected and uploaded. Logs can be configured to upload continuously or periodically. All logs that overlap events of interest, such as crashes, are collected automatically.

Logs-to-Metrics​

Metrics can be generated from logs on the device, for quickly reacting to, and measuring, ongoing incidents.

Millisecond-Resolution Events Timeline​

All events on the Device, such as Network Connectivity, Device Thermals, Battery Level, Battery Voltage, Charger Status, WorkManager Worker executions, and more, can be visualized on a Timeline in millisecond resolution, to understand the exact state of the Device at an exact moment in the past, when investigating an Issue. This enables capabilities like seeing whether Wi-Fi was connected at the time of a crash, if the Battery was charging, or what WorkManager Work was executing, or when the device was shutdown, at that point in time.

Historical Data Recovery​

All data collected on the Device is intelligently cached across a range of visibility options depending on your needs, costs, and performance tolerances. This data can be persisted for multiple days, and can be individually requested from that Device, ensuring visibility into problems that were not discovered until several days after the incident.

Minimal Device Footprint​

Data on the Device is collected infrequently, once per hour in the background by default. Many levers are available for tuning the frequency, volume, and timing of data collection and upload for the type of device.

Source-Available SDK​

The Memfault Android SDK is source-available, so you can see exactly what code is being loaded onto your AOSP device. We will work with you if there are modifications to the behavior of the SDK that you require!

See Android Features for a detailed guide of all of the data that the Android SDK can collect.

Have data on the device not collected by Memfault? Let us know! Or better yet, collect the data yourself using Memfault's Custom Metrics APIs.

How is Memfault different from other solutions?​

AOSP, not app-only observability​

Many existing Android observability solutions only provide analytics for a single app running on a Device. Memfault's Android SDK is part of the AOSP build, which allows it to gather data from all applications on the Device, even from apps and services not under your control (provided by AOSP), and with configurable permissions levels depending on your tolerance.

Many existing Android observability solutions only collect a single app's logcat logs and a single app's crashes. Memfault provides access to more kinds of data, across every application on the Device, including pre-installed apps and native services:

  • Logcat logs, including kernel, system, and event logs
  • Crashes (Exceptions, Tombstones, WTFs, ANRs)
  • OS errors (kernel oopses, SELinux violations, unexpected reboots)
  • Metrics from the Device (per-app and total network usage, per-app and total Device battery drain, disk space utilization, memory utilization, and more).

Device Metrics and Device Vitals​

Existing observability solutions are mostly focused on crashes. Memfault collects a variety of device-level metrics in addition to crash monitoring, which allows for comparisons of data beyond only crashes, to answer questions such as the average time to download and install an OTA update, or the number of devices using Wi-Fi versus Cellular on a specific day.

  • Metrics can be used to understand the performance of a single Device. All metrics collected on a Device can be visualized on a single timeline, alongside any crashes, which helps focus the debugging effort on the specific Device that's experiencing issues.
  • Memfault can be used to understand Fleet performance over time, and over different Releases. Metrics can be charted by Release, to understand regressions in performance or confirm that a fix has rolled out. This is particularly helpful alongside Memfault's OTA solution.

Device-centric SDK optimizations​

The Memfault SDK has multiple layers of optimizations to reduce the total amount of data uploaded, to be considerate of the Device's and user's network bandwidth. Data is only uploaded at configurable hourly intervals, with configurable settings to wait for favourable network conditions. Logcat logs can be configured to only upload if they are potentially relevant to an issue. Instead of collecting an Android bugreport that can be several MB in size, Memfault can collect much of the same data using metrics, with many settings to turn off data that isn't important to your product. Because the Memfault SDK is part of the AOSP build, it can monitor the device more efficiently in either the user or kernel space.

Historical Data Recovery​

The Memfault SDK will cache data on the Device for a configurable duration, and of a configurable size. This data can be requested from the Device days after the event occurred, making it possible to view what was going on the Device after the incident, when the user of the impacted Device reaches out to customer support.

Architecture Overview​

Memfault provides the Android SDK, a customizable SDK that can be easily integrated into your Android AOSP build.

The Android SDK's behavior is driven by the Bort application; it schedules and requests the diagnostics information, caches the data efficiently, and then processes the results and uploads then to the cloud when the Device is online. The Bort application is easily configurable to collect more or less data depending on your use case, and can be updated by pushing a new APK — no OS update is required.

The Usage Reporter is a companion system application that provides a mechanism for Bort to collect diagnostics information. It can use either the Memfault Caliper system, or bug reports, or both, depending on how the Bort application is configured.

info

For a detailed integration guide, see the AOSP Integration Guide.

To quickly preview Memfault on your own Android development Device, see the Android Quickstart APK.

To symbolicate native and ANR traces, as well as deobfuscate Android traces, Memfault provides a CLI tool that can be integrated into your build system to upload the required symbols and mappings, respectively. See Uploading Symbol Files for more information.

The Bort SDK contains built-in support for collecting many Android system metrics. To track additional or metrics on your platform, see our guide on Collecting Metrics.