Client-Side Rate Limiting
To bypass client-side rate limits for development, the Android SDK can be placed in Developer Mode.
In addition to rate limits on the server-side, the Android SDK also employs client-side rate limiting.
Client-side rate limits in addition to server-side rate limits helps limit a device's overall network usage and bandwidth consumption, by not sending data in the first place. They also further reduce the traffic to Memfault from any single malfunctioning device, and which helps provide fairer pricing.
In general, when any particular error event is detected, the Android SDK will check whether that type of error event has been rate limited, before recording the event to be uploaded. For some error types, the SDK will additionally consider an error event's Signature in the rate limit, by limiting events with unique Signatures and repeated Signatures.
For example, we can use the stacktrace from Java Exceptions as the Signature to uniquely identify exceptions from one another. Java Exceptions are rate limited at a rate of 100 unique Exceptions, 4 repeated Exceptions, returning 1 every 15 minutes. If we receive 5 Java Exceptions with the same stacktrace, and thus the same Signature, in the same 15 minute period, those 5 Java Exceptions will only count as 1 towards the 100 allowed, and only 4 of those Java Exceptions will be uploaded. After 15 minutes, another 1 of those Java Exceptions will be allowed to upload.
This granularity helps mitigates situations where a single crash in a crashloop prevents all other exceptions from being seen.
Event Type | Default Rate Limit (Default Token Duration) |
---|---|
Bug Report (on device requests) | 3 bug report requests (30 minutes) |
Bug Report (periodic) | 3 periodic bug reports (30 minutes) |
DropBoxManager ANRs | 10 unique ANRs (15 minutes) |
DropBoxManager Java Exceptions | 100 unique, 4 repeated Exceptions (15 minutes) |
DropBoxManager WTFs | 10 unique, 5 repeated WTFs (1 day) |
DropBoxManager Kmsgs | 10 Kmsgs (15 minutes) |
DropBoxManager Custom Events | 2 Custom Events (1 hour) |
DropBoxManager Tombstones | 10 unique Tombstones (15 minutes) |
Kernel Oops | 3 Kernel Oops (6 hours) |
Reboot Events | 5 Reboot Events (15 minutes) |
SELinux Violations | 15 unique SELinux Violations (1 day) |
A previous version of this document mistakenly described the rate limits as a sliding window algorithm. The rate limit is more accurately describing using the Token Bucket algorithm. Sorry for the mistake!