SDK Crash Handler With Thread Tracking for Accurate Attribution

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software development kits (SDKs) lack the capability to promptly and accurately identify crashes occurring within their own components, relying instead on the underlying operating system's crash diagnostic features, which can be inadequate for pinpointing SDK-related issues.

Innovation Solution

A new SDK with integrated APIs and a crash handler that tracks thread identifiers and API call counters to determine if a crash is SDK-related, providing indicators to a server system for centralized analysis.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If the SDK relies on the operating system's crash diagnostic features, then the SDK can maintain simplicity and avoid implementing complex crash detection mechanisms, but the SDK cannot promptly and accurately identify crashes occurring within its own components

Engineering Contradiction:
Improvecrash identification accuracyVSAvoidcrash detection mechanism complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The SDK segments the crash detection process into distinct components: thread identifier tracking, API call counter monitoring, and crash handler analysis. By dividing the detection mechanism into these modular segments, the SDK achieves accurate crash identification while maintaining manageable complexity through structured organization of detection functions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The SDK implements feedback mechanisms through the crash handler that receives crash identifiers from the operating system, analyzes them against tracked thread identifiers and API call counters, and provides feedback about whether the crash is SDK-related. This feedback loop enables accurate crash identification while the handler structure keeps the complexity organized and controllable.

Inventive Principle:
Principle #23Feedback

2Reliability

If the SDK implements comprehensive crash detection and identification capabilities, then the SDK can accurately identify SDK-related crashes, but the SDK increases the complexity of the system

Engineering Contradiction:
Improvecrash detection reliabilityVSAvoidSDK structure complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The crash handler serves multiple functions: it receives crash identifiers from the operating system, determines crash thread identifiers, compares them against tracked threads, checks API call counters, and provides both SDK internal crash indicators and callback crash indicators. This multi-functionality consolidates several detection tasks into a single component, improving reliability while managing complexity through functional integration.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The SDK performs preliminary actions by tracking thread identifiers and maintaining API call counters before crashes occur. The list of thread identifiers and their corresponding API call counts is built up in advance, enabling the crash handler to quickly compare against this pre-collected data when a crash occurs, thereby improving detection reliability without adding complexity during the crash event itself.

Inventive Principle:
Principle #10Preliminary action

3Measurement precision

If the SDK tracks thread identifiers and API call counters continuously, then the SDK can precisely determine SDK-related crashes, but the SDK increases processing overhead

Engineering Contradiction:
Improvecrash attribution precisionVSAvoidprocessing overhead
Core Design Contradiction:
Measurement precisionVSUse of energy by moving object

Solution Approach 1:

The SDK implements partial tracking by focusing specifically on thread identifiers and API call counters that are relevant to crash detection, rather than tracking all possible system parameters. This selective tracking achieves the necessary precision for crash attribution while minimizing processing overhead by only collecting and maintaining data that directly contributes to crash identification accuracy.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP4105783B1Software development kit with independent automatic crash detection
Publication Date: 2025.09.24 AGORA LAB INC
  • EP4105783B1 patent drawingFigure 1
  • EP4105783B1 patent drawingFigure 2
  • EP4105783B1 patent drawingFigure 3

AI summary

An improved SDK includes a set of APIs and a crash handler registered with the operating system. Each API is an interface accessible by a computer software application. Up on entrance, each API determines the current thread identifier, and inserts it into a list if it is not already in the list. Each thread identifier corresponds to an API call counter, which is incremented by one at the entrance and decremented by one at the exit point of the API. The SDK also records the identifier of the thread it creates for callback functions. When a crash occurs, the crash handler is executed. It determines that the crash is related to a callback interface if the crash thread identifier matches the callback thread identifier. The crash is determined to be caused by the SDK if the API call counter corresponding to the crash thread identifier is greater than zero.