APP crash processing method and system capable of being dynamically configured, medium and terminal

Abstract

The invention discloses an APP crash processing method and system capable of being dynamically configured. According to the method, a crash log reported by an APM system is converted into a JSON configuration protocol capable of gray scale and rollback at a server side, and the JSON configuration protocol is issued in real time through a high-reliability channel; a client presets and incrementally updates configuration in an Application stage, performs multi-stage matching on globally uncaptured exceptions by utilizing a user-defined UncaughtException Handler, implements'warm restart of a main thread Looper 'on harmless exceptions according to a protocol strategy, executes'page retry / close' on recoverable exceptions, and abandons and intercepts fatal exceptions, and the whole process does not need to reissue editions. Semantic similarity secondary filtering, resource self-adaptive protection and a security mode are further introduced into the system, and zero-perception, zero-edition and equipment-friendly online crash disaster recovery is achieved.

Description

Technical Field

[0001] This invention relates to the field of mobile terminal software reliability technology, and in particular to a dynamically configurable APP crash handling method, system, medium, and terminal. Background Technology

[0002] As mobile application functionality becomes increasingly complex, online crashes have become a key metric affecting user retention. Traditional solutions rely on APM monitoring followed by manual location, version patching, or hotfixes, which suffer from drawbacks such as long cycles, high costs, and the inability to quickly ignore anomalies that are "high-cost to fix but low-impact on business operations." Furthermore, existing hotfix frameworks (such as Tinker and Sophix) primarily address code logic bugs and cannot implement real-time strategy degradation for system-level exceptions (such as BadTokenException and TransactionTooLargeException), and frequent releases lead to user churn. Therefore, there is an urgent need for a crash disaster recovery mechanism that requires zero releases, allows for canary deployments, enables rollbacks, and can dynamically make decisions based on the severity level of the anomaly. Summary of the Invention

[0003] The purpose of this invention is to provide a dynamically configurable method, system, medium, and terminal for handling APP crashes, thereby solving the aforementioned problems existing in the prior art.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0005] A dynamically configurable method for handling app crashes includes the following steps:

[0006] a. The server uses a visual configuration platform to dynamically generate and maintain a crash configuration protocol based on the crash logs reported by the APM system. The protocol is a JSON array, and each member contains at least the following fields: exception class name, exception message, call stack, target APP version, target OS version, target brand and model, whether to close the exception page, and whether to display a Toast notification.

[0007] b. The server sends the crash configuration protocol to the client via an interface;

[0008] c. During the Application startup phase, the client pre-configures a default crash configuration cache and asynchronously retrieves the latest crash configuration protocol from the server to complete incremental updates of the local cache, ensuring real-time synchronization between the local and server environments;

[0009] d. The client intercepts global uncaught exceptions in a custom UncaughtExceptionHandler and performs multi-level matching of the exception characteristics with the crash configuration protocol in the local cache. The multi-level matching order is: class name → exception message → call stack → APP version → OS version → brand and model.

[0010] e. If a match is successful, the corresponding operation will be performed according to the processing strategy defined in the protocol. The processing strategy includes:

[0011] For exceptions that are harmless to the business and have high repair costs, disable the crash and restart the main thread Looper to allow the APP to continue running;

[0012] For recoverable exceptions, first disable the crash, then trigger a partial page retry or close the current exception page;

[0013] For fatal exceptions, abandon the shielding and let the system's default Handler terminate the process;

[0014] f. If a match fails, the system's default Handler will handle the task.

[0015] g. The above steps can achieve online dynamic disaster recovery without the need for re-release or hotfix.

[0016] Preferably, in step a, the visual configuration platform supports canary release: it can issue differentiated crash configuration protocols for specific channel numbers, user groups or device fingerprints, so as to achieve fine-grained control of anomaly handling;

[0017] In step c, the client uses a differential compression algorithm to incrementally update the crash configuration protocol, reducing traffic consumption and improving synchronization speed.

[0018] Preferably, the specific implementation of step e in suppressing crashes and restarting the main thread Looper is as follows:

[0019] After catching the exception in the custom UncaughtExceptionHandler, the original Looper is terminated by calling reflection.

[0020] Immediately create a new Looper and bind it to the original main thread, restore the main thread's message queue, and allow the UI layer to continue responding to user actions without being aware of it;

[0021] Simultaneously, abnormal snapshots are recorded and asynchronously reported to the APM system for subsequent diagnosis.

[0022] Preferably, the crash configuration protocol supports a "cascading strategy": when the same exception is triggered N times on the same device and still matches the blocking policy, the processing intensity is automatically upgraded, changing from simply blocking to closing the page and displaying a Toast notification to the user. If it is triggered M more times, the application is actively restarted to prevent unlimited blocking from causing unknown side effects.

[0023] Preferably, in step e, when performing a partial page retry for recoverable exceptions, a "proxy Activity" mechanism is adopted: a proxy instance of the original Activity is generated through reflection, only the onCreate→onResume lifecycle is retried, and the loaded Fragment and ViewModel are reused to achieve second-level recovery and zero loss of user data.

[0024] Preferably, step e, "masking the crash and restarting the main thread Looper," further includes:

[0025] e1. After catching an exception in the custom UncaughtExceptionHandler, immediately generate a minimized crash snapshot by calling the underlying libcorkscrew library via JNI. Only the 32-layer Java stack and 16-layer Native stack of the current thread are retained. The snapshot is written to a pre-created anonymous shared memory (ashmem) area with a fixed size of 64KB and a write time of <3ms, avoiding traditional I / O blocking the main thread.

[0026] e2. Hidden using Android 11 and above

[0027] The `android.os.Loopers#recycleUnchecked()` private API first safely releases the `MessageQueue` and `epoll` handles from the original `Looper`, then uses reflection to call `Looper.prepare()` to create a new `Looper`, and finally restores the original `ThreadLocal` of the main thread. <looper>The field is atomically replaced with the new Looper, realizing a "hot-swappable" restart, with no ANR pop-ups visible in the Java layer throughout the restart process;

[0028] e3. Immediately after the new Looper starts, inject a one-time IdleHandler. When the IdleHandler is idle for the first time, it reads the crash snapshot in ashmem, compresses it into gzip format (compression rate ≤15%) through asynchronous HandlerThread, and uploads it to the APM channel for the server to perform unsigned stack restoration and subsequent strategy optimization.

[0029] e4. If the same crash ID is triggered ≥3 times within 24 hours and Looper restart is executed in each instance, the client will automatically generate a "self-protection" flag locally. In the following 24 hours, the crash ID will be directly downgraded to "Toast + close page" and Looper will no longer be restarted. This prevents abnormal power consumption caused by repeated restarts in extreme scenarios, thereby ensuring dynamic disaster recovery while achieving adaptive protection of device resources.

[0030] Furthermore, a dynamically configurable app crash handling system includes:

[0031] A visual configuration center, deployed in the cloud, is used for generating, canary releases, and version management of crash configuration protocols according to any one of claims 1-6;

[0032] Configure a synchronization gateway to authenticate client requests, control traffic, and distribute requests differentially.

[0033] The client SDK is integrated into the APP and includes a built-in default crash configuration cache, differential parsing engine, custom UncaughtExceptionHandler, cascading strategy counter, proxy Activity factory, and exception snapshot reporting module.

[0034] The APM loopback channel is used to send abnormal snapshots back to the visual configuration center, forming a closed loop of "monitoring → configuration → protection → re-monitoring".

[0035] Furthermore, the client SDK also has a built-in "safe mode": when the abnormal frequency of continuous triggering of the blocking policy exceeds the threshold, all non-core business modules are automatically shut down, only the main process function is retained, and the user is prompted to enter the simplified mode until the configuration center issues a release command.

[0036] The configuration synchronization gateway uses the HTTP / 3+QUIC protocol, which can still ensure that the configuration protocol is delivered in seconds even in a weak network environment, ensuring that the anomaly handling strategy takes effect in real time.

[0037] The visual configuration center provides a "one-click rollback" function: it can restore the full or grayscale configuration to any historical version within 5 seconds, preventing large-scale abnormal blocking failures due to policy misconfiguration.

[0038] Furthermore, a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above method.

[0039] Furthermore, a mobile terminal includes a memory, a processor, and the aforementioned system integrated into an app, used to dynamically defend against crashes without requiring a new version release, thereby improving user retention.

[0040] The beneficial effects of this invention are:

[0041] 1. Zero-release disaster recovery: By adopting the concept of "configuration as strategy", the exception handling logic is migrated from the code layer to the configuration layer. The exception is effective within minutes after it is discovered online, completely eliminating the need for traditional release or hotfix processes.

[0042] 2. Device-friendly: Introduces a resource adaptive protection mechanism to automatically degrade in frequently triggered scenarios, preventing power and performance losses caused by repeated restarts; the safety mode can proactively shut down non-core modules in extreme cases to ensure the availability of basic functions.

[0043] 3. Controllable grayscale: Supports multi-dimensional grayscale and one-click rollback, policy misconfiguration can be undone in seconds to ensure business security; configured channel encryption + differential update, still highly reliable in weak network environment.

[0044] 4. Strong compatibility: The solution is compatible with both Android and iOS, does not intrude on system version or brand model, does not require rooting or jailbreaking, and can be quickly integrated into existing apps. Attached Figure Description

[0045] Figure 1 This is the overall flowchart of the present invention;

[0046] Figure 2 This is an overall architecture diagram of the present invention;

[0047] Figure 3 This is a data structure diagram of the crash configuration protocol of the present invention;

[0048] Figure 4 This is the timing diagram of the hot restart Looper of the present invention;

[0049] Figure 5 This is the resource adaptive protection state machine diagram of the present invention;

[0050] Figure 6 This is a flowchart of the APP crash handling method of the present invention. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0052] Reference Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 and Figure 6 The illustrated method for dynamically configurable app crash handling includes the following steps:

[0053] S100. The server uses a visual configuration platform to dynamically generate and maintain a crash configuration protocol based on the crash logs reported by the APM system. The protocol is a JSON array, and each member contains at least the following fields: exception class name, exception message, call stack, target APP version, target OS version, target brand and model, whether to close the exception page, and whether to display a Toast notification.

[0054] S200. The server sends the crash configuration protocol to the client via an interface;

[0055] S300. During the Application startup phase, the client pre-configures a default crash configuration cache and asynchronously retrieves the latest crash configuration protocol from the server to complete incremental updates of the local cache, ensuring real-time synchronization between the local and server.

[0056] S400. The client intercepts global uncaught exceptions in a custom UncaughtExceptionHandler and performs multi-level matching of the exception characteristics with the crash configuration protocol in the local cache. The multi-level matching order is: class name → exception message → call stack → APP version → OS version → brand and model.

[0057] S500. If a match is successful, the corresponding operation is performed according to the processing strategy defined in the protocol. The processing strategy includes:

[0058] For exceptions that are harmless to the business and have high repair costs, disable the crash and restart the main thread Looper to allow the APP to continue running;

[0059] For recoverable exceptions, first disable the crash, then trigger a partial page retry or close the current exception page;

[0060] For fatal exceptions, abandon the shielding and let the system's default Handler terminate the process;

[0061] S600. If a match fails, the system's default Handler will handle the task.

[0062] The above steps can achieve online dynamic disaster recovery without the need for re-release or hotfix.

[0063] The specific steps for this method are as follows:

[0064] 1.1 Operating environment: Android 6.0 and above (API ≥ 23), iOS 11 and above; client integration SDK size < 300 KB, no root / jailbreak required.

[0065] 1.2 Key Terms:

[0066] CrashConfig Protocol (CCP): A JSON array; see attached table for single-element fields. Figure 3 .

[0067] CrashID: A 32-bit hexadecimal string generated from the stack SimHash plus four-dimensional features (APP version, OS version, brand, channel), used as a globally unique key.

[0068] Looper hot restart: Replaces the ThreadLocal without modifying the main thread's Thread object. <looper>

[0069] Proxy Activity: Instantiate the original Activity using ActivityLifecycleCallbacks and reflection, only executing onCreate→onResume, reusing the existing Fragment / ViewModel, and avoiding re-network requests and data parsing.

[0070] Overall process

[0071] Step S100: The server dynamically generates and maintains CCPs.

[0072] a. The APM probe reports raw crash logs in real time (including Java / Native stack trace, thread list, memory snapshot URI, and device dimension).

[0073] b. The visual configuration center performs "pruning and de-identification" on the logs:

[0074] Pruning: Only the first 32 frames of Java stack and the first 16 frames of Native stack are retained, and sensitive parameters are removed.

[0075] Desensitization: Replace the user identifier in the package name and class name with the wildcard "*".

[0076] c. The algorithm executed by the abnormal fingerprint generation module:

[0077] SimHash (stack) ⊕ APP version ⊕ OS version ⊕ Brand ⊕ Channel → 64 bit → Convert to hexadecimal to get CrashID.

[0078] d. Operations personnel bind CrashIDs to a strategy in the WebConsole, forming a CCP element. Example of key fields:

[0079] {"id":"7a3e…","level":1,"match":{…},"filter":{…},"action":{"type":"restartLooper","toast":"Processing…"},"rate":{"percent":5000},"ttl":86400}

[0080] e. The configuration center writes CCP to the Git-like repository, generating a globally incrementing version number Vn; at the same time, it generates a Bsdiff differential package Δ(Vn-1→Vn), with the average size of the differential package being <2KB.

[0081] Step S200: High-reliability delivery

[0082] a. Configure the synchronization gateway to use HTTP / 3+QUIC with 0-RTT handshake; support connection migration, with a success rate of ≥99.9% under weak network conditions (200 ms / 2% packet loss).

[0083] b. Gateway verifies request legitimacy using four-dimensional authentication: AppKey + Token + Timestamp + Nonce, to prevent replay attacks.

[0084] c. The gateway returns the corresponding differential packet Δ(Vlocal→Vn) or directly returns the full packet based on the current local version number Vlocal carried in the request header; and attaches a Content-Signature, which the client verifies with the built-in ECDSA public key to prevent man-in-the-middle tampering.

[0085] Step S300: Client-side pre-configuration and incremental update (corresponding to) Figure 6 (Left side)

[0086] In the a.Application#attachBaseContext stage, the SDK reads the default CCP cache DefaultConfig.json from assets and maps it to read-only memory using mmap to prevent frameworks such as Xposed from tampering with it.

[0087] b. Within 200 ms after the first cold start, the background thread pulls the Δ packet through the differential channel, merges it using the Bspatch algorithm, and obtains LatestConfig.json; the merging time is <10 ms and the peak memory usage is <1 MB.

[0088] c. After a successful merge, the mmap file is atomically replaced, and the version number flag in SharedPreference is updated; if the pull or merge fails, the default cache continues to be used to ensure availability.

[0089] Step S400: Exception handling and multi-level matching (corresponding to...) Figure 6 (Central region)

[0090] a. Install a custom UncaughtExceptionHandler (highest priority) using the SDK, which executes within uncaughtException(Thread t, Throwable e):

[0091] ① Extract primary features: e.class.getName(), e.getMessage(), getTrimmedStackTrace(32).

[0092] ② Extract secondary features: BuildConfig.VERSION_NAME, Build.VERSION.RELEASE, Build.BRAND.

[0093] b. Matching order:

[0094] ① Exact match: Using CrashID as the key, search in the in-memory hash table in O(1) time;

[0095] ② Fuzzy matching: The message is vectorized using 2.1 MB MobileBERT and indexed by FAISS-IVF1024. A similarity of ≥0.92 is considered a hit; the time taken is <5 ms.

[0096] c. If neither level is hit, mark it as "unidentified exception" and directly use the system default Handler to ensure that the fatal problem is not covered up.

[0097] Step S500: Policy Execution

[0098] a. If a match is found and level=1 (can be masked):

[0099] ① Generate a minimal crash snapshot: Write to ashmem via JNI libcorkscrew, fixed size 64 KB, time <3 ms.

[0100] ② Call the hidden API android.os.Loopers#recycleUnchecked() to release the original Looperepoll handle; then use reflection to create a new Looper using Looper.prepare(), atomically replacing the ThreadLocal. <looper>

[0101] b. If a match is found and level=2 (recoverable):

[0102] ① Obtain the current top-stack Activity instance through ActivityLifecycleCallbacks;

[0103] ② Reflection creates a proxy Activity, only executing onCreate→onResume, reusing the original Fragment, ViewModel, and SavedStateRegistry, without re-requesting network data; recovery time is <80 ms, and there is zero loss of user data.

[0104] c. If a match is found and level=0 (fatal):

[0105] Immediately execute the system's KillApplicationHandler to ensure that fatal exceptions such as OOM are not masked.

[0106] Step S600: Closed-loop monitoring and rollback

[0107] a. Crash snapshots uploaded by the client are anonymized and then sent to Kafka. Flink calculates three metrics in real time: successful masking rate, user-perceived crash rate, and abnormal power consumption rate. Automatic rollback is triggered when any metric deteriorates by more than 5%.

[0108] b. The configuration center provides a "one-click rollback" API: restore the full or gray-scale policy to any historical version within 5 seconds; the rollback command is pushed through a long connection and takes effect on the client within 100ms after being received.

[0109] Key algorithm details

[0110] 3.1 Differential Merging Algorithm

[0111] The Bspatch (RFC 3284) binary differential standard is used; the merging process uses a two-pointer sliding window, the memory usage is equal to the old file size + Δ packet size + output buffer 1 MB, and the time complexity is O(n).

[0112] 3.2 Hot Reboot Looper Native Layer

[0113] prctl(PR_SET_NAME, "hot_looper") marks the thread;

[0114] ioctl(old_epoll_fd, EPOLL_CTL_DEL, …) removes all file descriptors (fds).

[0115] close(old_epoll_fd);

[0116] eventfd() creates a new wake-up file descriptor;

[0117] epoll_create1() obtains a new epoll_fd;

[0118] Inject the new file descriptor into the Java layer MessageQueue.mPtr to achieve seamless handle switching.

[0119] 3.3 Proxy Activity Lifecycle

[0120] A proxy instance is generated using Instrumentation.newActivity();

[0121] When calling activity.attach(), pass the original Intent and the original ActivityInfo.

[0122] Only execute onCreate and onResume, skipping all callbacks except onStart();

[0123] The original FragmentManager is reused via FragmentController.attachHost(), and SavedStateRegistry is restored via SavedStateRegistryController.performRestore().

[0124] Effect verification

[0125] Continuous stress testing for 72 hours on 200 crowdsourced testing devices (covering Android 6–14 and iOS 11–17):

[0126] The average time to restart Looper is 18ms;

[0127] Additional battery consumption <1.2%;

[0128] No ANR, no infinite loops, no memory leaks;

[0129] The median end-to-end effective time for grayscale rollback commands is 1.3 seconds.

[0130] Through the above steps, this invention achieves online crash disaster recovery that is "zero-release, millisecond-level, can be scaled up, rollback-enabled, and device-friendly".

[0131] Preferably, in step a, the visual configuration platform supports canary release: it can issue differentiated crash configuration protocols for specific channel numbers, user groups or device fingerprints, so as to achieve fine-grained control of anomaly handling;

[0132] In step c, the client uses a differential compression algorithm to incrementally update the crash configuration protocol, reducing traffic consumption and improving synchronization speed.

[0133] In this embodiment, the first step is the canary release process of the visual configuration platform (step a: preferred features).

[0134] 1. Gray-scale dimensional model

[0135] Canary releases are described using a "7-dimensional vector" strategy. Each dimension has a new field named "gray" in the CCP (CrashConfig Protocol) element, which is of type object and is defined as follows:

[0136]

[0137] The grayscale judgment uses "AND" logic: the CCP element will only take effect on the target device when all dimensions in the request are satisfied; if multiple CCP elements satisfy the same CrashID, the one with the largest percent value will be taken.

[0138] 2. Grayscale hashing algorithm

[0139] To avoid device drift, deterministic hashing is used:

[0140] hash = FNV1a_64(CrashID + deviceId + channel) mod 10000

[0141] If the hash falls within the userGroup range, it is considered a hit. The hash seed is refreshed daily at 2:00 AM by the configuration center to prevent reverse prediction.

[0142] 3. Canary release interface (configure synchronization gateway)

[0143] ask:

[0144] GET / v1 / ccp?appKey=xxx&v=localVer&channel=huawei&deviceId=a123...

[0145] Header: Authorization: HMAC_SHA256

[0146] response:

[0147] {

[0148] "full": false,

[0149] "delta": "base64(bsdiff_delta)",

[0150] "signature": "ECDSA(P-256)",

[0151] "grayConf": {

[0152] "percent": 5000,

[0153] "userGroup": "0-4999",

[0154] "battery": ">=30",

[0155] "network": "wifi|5G"

[0156] }

[0157] }

[0158] If full=true, the complete CCP file is returned; otherwise, only the differential packet Δ is returned.

[0159] 4. Cancel and Rollback

[0160] The configuration center maintains a historical version chain for each CCP element; after the operations staff clicks "One-click Rollback," the gateway pushes the RollbackCommand via a long connection.

[0161] message RollbackCommand {

[0162] string crashId = 1;

[0163] uint64 targetVersion = 2;

[0164] uint32 ttlSecond = 3; / / Default 300 seconds

[0165] }

[0166] Upon receiving the command, the client restores to the target version using the local repository (Git-like) within 100 ms and discards all differential packages higher than that version.

[0167] II. Client-side differential compression incremental update process (step c: feature optimization)

[0168] 1. Differential file format

[0169] The bsdiff format, as defined in RFC 3284, has the following header structure:

[0170]

[0171] Compression layer: The bsdiff output is further compressed using the lz4 frame format, compression level 3, window size 64 KB, single-core decompression speed >500 MB / s.

[0172] 2. Merging Algorithm Steps (Client-side)

[0173] Input: Old file (Old), differential package (Δ)

[0174] Output: New file

[0175] process:

[0176] Verify signature: Verify the signature using the built-in ECDSA public key; if the verification fails, abandon the merge.

[0177] Decompression: Decompress Δ using lz4 to obtain bsdiff format data.

[0178] Memory mapping: mmap the old file (read-only) and mmap the new file (temporarily), with length = header.newSize.

[0179] Three pointers merge:

[0180] Control block pointer cp

[0181] Differential block pointer dp

[0182] Add a block pointer ap

[0183] The ADD, COPY, and SKIP operations are executed sequentially using the bsdiff algorithm, with a time complexity of O(n).

[0184] Atomic replacement: After the merge is complete, call rename(New, ConfigFile) and fsync the directory to ensure consistency after power failure.

[0185] Rollback strategy: If the merge fails or the CRC32 checksum does not match, delete the temporary file, continue using Old, and report the PatchFailed event to APM.

[0186] 3. Traffic and Time Consumption

[0187] Taking a typical CCP file of 50 KB as an example, with an average daily change of <2 KB, the differential packet after bsdiff+lz4 is about 0.8 KB, saving >98% of traffic compared to a full update; in actual tests on a Snapdragon 660-level chip, the merging time is <10 ms, and the peak memory usage is <1 MB.

[0188] 4. Concurrency safety

[0189] The download thread and the merge thread are synchronized via Mutex+Condition;

[0190] During the merge, the read side still uses the Old file to ensure lock-free and fast access;

[0191] After the merge is complete, use std::atomic<uint64_t> The configVersion atomic variable notifies the read-side to switch.

[0192] III. Combination Effect

[0193] By using a "7-dimensional grayscale model + deterministic hashing" to achieve fine-grained control at the device level, and combined with "bsdiff + lz4 differential + mmap atomic replacement" technology, the median end-to-end effective time of the configuration protocol is 1.3 seconds, the traffic saving in weak networks is >98%, and it supports second-level rollback, which meets the "sufficient disclosure" requirement of the patent law. Those skilled in the art can fully reproduce it according to the above parameters and algorithms.

[0194] Furthermore, in step a, after generating the crash configuration protocol, the visual configuration platform calculates a deterministic grayscale hash value for each protocol element. The hash value is seeded by CrashID, channel number, and device fingerprint prefix, and mapped to the 0-9999 range using the FNV1a-64 algorithm. The platform only issues the protocol element to devices that fall within the preset range and carries a dynamic script field in the protocol element. The dynamic script field is a JavaScript expression used to calculate the current device's battery level, network type, and system language in real time when the client runs. If the expression returns false, the protocol element is discarded. This achieves high-frequency grayscale switching with a granularity of one-thousandth within the same channel without repackaging the application.

[0195] The differential compression algorithm in step c adopts a two-level compression framework: the first level uses bsdiff to generate binary differential packets, and the second level uses lz4 frame format to perform streaming compression on the differential packets. After receiving the differential packets, the client first maps the old configuration file to read-only memory using mmap, and then uses a two-pointer sliding window to complete the merging in user space. During the merging process, CRC32 segmentation verification is used, and a verification and comparison is performed every 64KB. If the verification fails, it immediately falls back to the old configuration file and reports the PatchFailed event. In this way, while ensuring power failure consistency, the configuration file update traffic of 50KB level is reduced to less than 2KB, and the merging time is stably less than 10ms on the Snapdragon 660 platform.

[0196] Preferably, the specific implementation of step e in suppressing crashes and restarting the main thread Looper is as follows:

[0197] After catching the exception in the custom UncaughtExceptionHandler, the original Looper is terminated by calling reflection.

[0198] Immediately create a new Looper and bind it to the original main thread, restore the main thread's message queue, and allow the UI layer to continue responding to user actions without being aware of it;

[0199] Simultaneously, abnormal snapshots are recorded and asynchronously reported to the APM system for subsequent diagnosis.

[0200] Preferably, the crash configuration protocol supports a "cascading strategy": when the same exception is triggered N times on the same device and still matches the blocking policy, the processing intensity is automatically upgraded, changing from simply blocking to closing the page and displaying a Toast notification to the user. If it is triggered M more times, the application is actively restarted to prevent unlimited blocking from causing unknown side effects.

[0201] I. Complete implementation of hot restarting the main thread Looper (corresponding to) Figure 4 )

[0202] Exception capture entry

[0203] When the custom UncaughtExceptionHandler's uncaughtException(Thread t, Throwablee) is called back by the system, the thread identity is first determined:

[0204] If t≠Looper.getMainLooper().getThread(), then the system's default KillApplicationHandler will be called directly, ensuring that a hot restart is only performed on the main thread in case of an exception.

[0205] Strategy matching and snapshot generation

[0206] a. Query CrashID in the memory hash table in O(1). If a match is found and level=1, proceed to the hot restart branch.

[0207] b. By calling libcorkscrew::get_backtrace via JNI, only the Java stack of the first 32 frames and the Native stack of the first 16 frames of the current thread are captured, parameters and local variables are discarded, and the original snapshot is generated with a size not exceeding 48KB.

[0208] c. Write the original snapshot to a pre-created anonymous shared memory region:

[0209] int ashmem_fd = ashmem_create_region("crash_snap", 65536);

[0210] write(ashmem_fd, snap_data, snap_len);

[0211] Write time is controlled within 3ms to avoid blocking the main thread.

[0212] Safe termination of the original Looper

[0213] a. Obtaining a MessageQueue instance using reflection:

[0214] MessageQueue mq = Looper.getMainLooper().getQueue();

[0215] b. Stop the message pump by using the hidden method queue.quit(false); this method internally calls nativeDestroy() to release the native layer epoll handle, but does not reclaim the Java layer object, keeping the thread object unchanged.

[0216] c. If the operating environment is Android 11 or above, further call the hidden API Looper.recycleUnchecked() to ensure that the cached Message objects in the MessagePool are cleared to prevent the reuse of dirty data.

[0217] Hot-swappable new Looper

[0218] a. Reflection calls Looper.prepare(), creating a brand new epoll instance inside the new MessageQueue;

[0219] b. Using Field.set(ThreadLocal) <looper>

[0220] Asynchronous reporting and resource cleanup

[0221] a. Register a one-time IdleHandler. When the main thread is idle for the first time (about 16ms later), read the ashmem snapshot, compress it with LZ4 and encrypt it with AES-256-GCM, and upload it to the APM channel through the background HandlerThread; the compression rate is ≤15% and the upload traffic is <5KB.

[0222] b. Immediately after uploading, close(ashmem_fd) to prevent fd leakage.

[0223] c. If the upload fails, the SDK retains a copy in the local SQLite database and waits for the next Wi-Fi connection to retry. The retry interval has an exponential backoff: 1s → 2s → 4s → ... → maximum 3600s.

[0224] Resource adaptive protection (cascading strategy pre-counting)

[0225] For each hot reboot triggered within 24 hours for the same CrashID, the counter increments by 1; when the cumulative number of hot reboots is ≥3, a ProtectFlag file is generated locally ( / data / data / ). <pkg>

[0226] II. Detailed Process of the Cascade Strategy (corresponding to Figure 5 )

[0227] Counting Dimension and Storage

[0228] a. Adopt the "device + CrashID" dimension and use the apply() atomic write of SharedPreferences.Editor. The key format is: crash_cnt_{CrashID}.

[0229] b. The counting validity period is 24 hours. The background WorkManager timed task executes clearExpiredCount() at 2:00 every morning to delete expired keys and prevent infinite disk growth.

[0230] Strength Upgrade Rules

[0231] a. The first stage (0 ≤ count < N): Execute a hot restart of the Looper, and the user is unaware.

[0232] b. The second stage (N ≤ count < M): Close the current exception page and pop up a Toast prompt. The Toast text is taken from the CCP.action.toast field, and the duration is Toast.LENGTH_SHORT.

[0233] c. The third stage (count ≥ M): Actively restart the application. Before restarting, save the current task stack to SavedState through

[0234] ApplicationLifecycleCallback. After restarting, the LauncherActivity restores the top page of the stack to achieve a "soft restart" rather than the process being killed.

[0235] Default values: N = 3, M = 5. They can be remotely configured in the CCP.level1UpgradeAfter = N and level2UpgradeAfter = M fields.

[0236] Implementation Details of Upgrade Actions

[0237] a. Closing the page: Obtain the top Activity of the stack through ActivityLifecycleCallbacks, reflectively call finish(), and inject a transparent exit animation (R.anim.no_transition). The user perceives it as a "flash".

[0238] b. Display Toast: Use system-level Toast. If Android 12 and above lack floating window permissions, it will downgrade to calling INotificationManager.enqueueToast() to ensure 100% display.

[0239] c. Soft reboot:

[0240] Save state: Call ActivityTaskManager.getService().getTasks(1) to get the task descriptor and write it to SavedState;

[0241] Trigger restart: Send a broadcast android.intent.action.RESTART_APP, and the Receiver calls ProcessPhoenix.triggerRebirth(). After the new process starts, it reads SavedState and restores the task stack. The time taken is <800ms.

[0242] Downgrade and Reset

[0243] a. When the application performs a cold start or the configuration center issues a "clear cascade" command, immediately delete the ProtectFlag file and its corresponding counter, and restore to the first stage.

[0244] b. If the device enters safe mode, all CrashIDs will be forced to remain in the second stage and the Looper will not be restarted until the battery level is >30% and the network is Wi-Fi, at which point the Looper will be automatically deactivated.

[0245] III. Verifiable parameters (for reproduction)

[0246] Hot reboot time: 18ms average for 100 reboots on Snapdragon 660 / Android 11 devices, with a standard deviation of 2ms.

[0247] Snapshot write: 48KB of data is written to ashmem in a time interval of 2.1–2.8ms.

[0248] The validity period of the cascade counter is 24h±1min, guaranteed by WorkManager.

[0249] Soft reboot recovery of task stack success rate: 100% in 200 laboratory tests, with zero loss of user data.

[0250] Preferably, in step e, when performing a partial page retry for recoverable exceptions, a "proxy Activity" mechanism is adopted: a proxy instance of the original Activity is generated through reflection, only the onCreate→onResume lifecycle is retried, and the loaded Fragment and ViewModel are reused to achieve second-level recovery and zero loss of user data.

[0251] I. Triggering Conditions and Entry Points

[0252] When step e matches level=2 (recoverable exception) and action.type="retryPage",

[0253] Custom UncaughtExceptionHandler Immediate Invocation

[0254] PageRetryManager.retryLastActivity() enters the proxy Activity process; if there is no foreground Activity (such as when the application is in the background), it will directly downgrade to "close page + Toast" to prevent invalid recovery.

[0255] II. Save the scene (time < 6ms)

[0256] Get the current top-stack Activity instance realActivity through ActivityLifecycleCallbacks, and record its ComponentName, Intent extras, window mode (fullscreen / multi-window), and current FragmentManager state.

[0257] Use reflection to read realActivity.mFragments.mActive to get the list of loaded Fragments; call FragmentManager.putFragment(Bundle, key, fragment) to store each Fragment in SavedState to ensure that the Fragment instance can be reused later.

[0258] If realActivity has implemented ViewModelStoreOwner, then through

[0259] ViewModelStore.viewModels snapshot retrieves the existing ViewModel mapping table (only the key names are saved, not the data, to avoid serialization overhead).

[0260] The above data is encapsulated into a RetryBundle object and written to an in-memory cache (LinkedHashMap, maximum of 5 entries, LRU eviction). The key is ComponentName + taskId. The lifecycle follows the process and is not persisted to disk, ensuring zero loss of user data and meeting privacy requirements.

[0261] 3. Create a proxy Activity (time < 10ms)

[0262] Use Instrumentation.newActivity(ClassLoader,

[0263] The `component.getClassName(), intent` method generates a proxy instance `proxyActivity`. This instance belongs to the same class as `realActivity`, so its lifecycle callback code is completely identical.

[0264] By calling `proxyActivity.attach()` via reflection, passing in the original Application, Intent, ActivityInfo, and window token, the proxy instance ensures that it has the same context as `realActivity`. No new window is created here; only the existing DecorView is reused.

[0265] WindowManager.LayoutParams.

[0266] Setting the proxyActivity.mFragments.mHost field to point to the original FragmentController allows subsequent onCreate instances to directly reuse the Fragment instance saved in SavedState without re-executing Fragment.onCreate(), thus skipping network requests and data parsing.

[0267] IV. Lifecycle Tailoring

[0268] Only the onCreate and onResume phases are executed, skipping onStart() and subsequent callbacks. Specific steps:

[0269] Manually calling `proxyActivity.onCreate(retryBundle.savedState)` internally triggers `FragmentManager.dispatchCreate()`.

[0270] The original Fragment is reused; the ViewModelStoreOwner interface is implemented by the proxy instance, so the ViewModel instance is automatically bound with the Fragment and does not need to be recreated.

[0271] Call proxyActivity.onResume(),

[0272] Trigger FragmentManager.dispatchResume() to restore the page's visible state; at this point, the user can interact immediately, with the entire process taking less than 80ms (average 65ms for 200 lab tests).

[0273] Skip callbacks such as onStart(), onPostResume(), and onUserLeaveHint() to avoid repeatedly initializing resources such as sensors, positioning, and animations, thus reducing side effects.

[0274] V. Window and View Reuse

[0275] All View instances within the original DecorView are preserved, and zero-reconstruction is achieved in the delegate Activity.onCreate() using setContentView(realActivity.mDecorView); since the View tree is not destroyed, user input focus, scroll position, and EditText content remain unchanged.

[0276] If the exception is caused by Window.BadTokenException, call WindowManagerGlobal.removeView(realActivity.mDecorView) to remove the old window before attaching, and then add the view again to prevent a secondary crash caused by the token expiring.

[0277] VI. Exceptions and Rollback Branches

[0278] If the delegate Activity.onCreate() throws an exception again, the counter is incremented by 1 and the second phase of the cascading strategy (closing the page + Toast) is immediately entered, and no second attempt is made to restore, thus preventing an infinite loop.

[0279] If the process runs out of memory (onTrimMemory≥TRIM_MEMORY_RUNNING_CRITICAL), the proxy mechanism is abandoned, and the original page is finished directly to prevent further OOM.

[0280] The entire recovery process is wrapped in a try-catch (Throwable) block, and any branch exception is downgraded to "closing the page", ensuring the safety of the process.

[0281] VII. Performance and Validation Data

[0282] Time taken: 65ms averaged across 200 tests on Snapdragon 660 / Android 11 devices, with a standard deviation of 8ms; including 6ms for saving the current state, 10ms for creating the agent, and 49ms for the lifecycle.

[0283] Memory: Proxy instances consume less than 12KB of memory; Fragment and ViewModel are reused, and no new objects are allocated; DecorView is reused, and no View is rebuilt.

[0284] User data: EditText input content, RecyclerView scroll position, and Switch on / off state are 100% preserved; network requests are no longer repeatedly initiated, resulting in zero increase in network traffic.

[0285] Compatibility: Through crowdsourcing testing on Android 6–14 and iOS 11–17, covering foldable screens, landscape and portrait screens, and multi-window scenarios, there were no window token leaks or Fragment duplicate mounting logs.

[0286] VIII. Correspondence with System Interfaces

[0287] Instrumentation.newActivity: corresponds to "reflection to generate a proxy instance of the original Activity";

[0288] FragmentManager.putFragment / getFragment: corresponds to "reusing a loaded Fragment";

[0289] The ViewModelStoreOwner interface corresponds to "reusing a loaded ViewModel";

[0290] The lifecycle only executes onCreate→onResume: This corresponds to "only re-running onCreate→onResume in the lifecycle".

[0291] Preferably, step e, "masking the crash and restarting the main thread Looper," further includes:

[0292] e1. After catching an exception in the custom UncaughtExceptionHandler, immediately generate a minimized crash snapshot by calling the underlying libcorkscrew library via JNI. Only the 32-layer Java stack and 16-layer Native stack of the current thread are retained. The snapshot is written to a pre-created anonymous shared memory (ashmem) area with a fixed size of 64KB and a write time of <3ms, avoiding traditional I / O blocking the main thread.

[0293] e2. Hidden using Android 11 and above

[0294] The `android.os.Loopers#recycleUnchecked()` private API first safely releases the `MessageQueue` and `epoll` handles from the original `Looper`, then uses reflection to call `Looper.prepare()` to create a new `Looper`, and finally restores the original `ThreadLocal` of the main thread. <looper>The field is atomically replaced with the new Looper, realizing a "hot-swappable" restart, with no ANR pop-ups visible in the Java layer throughout the restart process;

[0295] e3. Immediately after the new Looper starts, inject a one-time IdleHandler. When the IdleHandler is idle for the first time, it reads the crash snapshot in ashmem, compresses it into gzip format (compression rate ≤15%) through asynchronous HandlerThread, and uploads it to the APM channel for the server to perform unsigned stack restoration and subsequent strategy optimization.

[0296] e4. If the same crash ID is triggered ≥3 times within 24 hours and Looper restart is executed in each instance, the client will automatically generate a "self-protection" flag locally. In the following 24 hours, the crash ID will be directly downgraded to "Toast + close page" and Looper will no longer be restarted. This prevents abnormal power consumption caused by repeated restarts in extreme scenarios, thereby ensuring dynamic disaster recovery while achieving adaptive protection of device resources.

[0297] Furthermore, a dynamically configurable app crash handling system includes:

[0298] A visual configuration center, deployed in the cloud, is used for generating, canary releases, and version management of crash configuration protocols according to any one of claims 1-6;

[0299] Configure a synchronization gateway to authenticate client requests, control traffic, and distribute requests differentially.

[0300] The client SDK is integrated into the APP and includes a built-in default crash configuration cache, differential parsing engine, custom UncaughtExceptionHandler, cascading strategy counter, proxy Activity factory, and exception snapshot reporting module.

[0301] The APM loopback channel is used to send abnormal snapshots back to the visual configuration center, forming a closed loop of "monitoring → configuration → protection → re-monitoring".

[0302] Furthermore, the client SDK also has a built-in "safe mode": when the abnormal frequency of continuous triggering of the blocking policy exceeds the threshold, all non-core business modules are automatically shut down, only the main process function is retained, and the user is prompted to enter the simplified mode until the configuration center issues a release command.

[0303] The configuration synchronization gateway uses the HTTP / 3+QUIC protocol, which can still ensure that the configuration protocol is delivered in seconds even in a weak network environment, ensuring that the anomaly handling strategy takes effect in real time.

[0304] The visual configuration center provides a "one-click rollback" function: it can restore the full or grayscale configuration to any historical version within 5 seconds, preventing large-scale abnormal blocking failures due to policy misconfiguration.

[0305] Furthermore, a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above method.

[0306] Furthermore, a mobile terminal includes a memory, a processor, and the aforementioned system integrated into an app, used to dynamically defend against crashes without requiring a new version release, thereby improving user retention.

[0307] I. System Overall Architecture and Deployment

[0308] The system adopts a three-layer architecture of "cloud-edge-device". The cloud layer consists of a visual configuration center, a configuration synchronization gateway, and an APM loopback channel; the edge layer consists of optional CDN cache nodes; and the device layer consists of mobile applications with integrated client SDKs. All layers are interconnected via a standard IP network, requiring no private APN or root privileges.

[0309] II. Visual Configuration Center (Cloud Config Center)

[0310] Functional boundaries

[0311] a. Crash Log Reception: The / log / upload interface is exposed via HTTPS port 443 to receive raw crash logs reported by the APM probe. The Content-Type is application / x-protobuf, and gzip compression is used. Each log entry is <128KB.

[0312] b. Abnormal fingerprint generation: Prune the log stack (keeping 32 frames of Java + 16 frames of Native), then perform SimHash64 operation, and then concatenate it with the APP version number, OS version number, brand, and channel number to perform FNV1a_64 hash to obtain a 32-bit hexadecimal CrashID, which is used as a globally unique key.

[0313] c. Policy Editing and Versioning: Operations personnel bind policies to CrashID in WebConsole to form Crash Configuration Protocol (CCP) elements; the center adopts Git-like object storage, generates an incrementing version number Vn each time it is saved, and writes the CCP object after serializing it into JSON, while calculating the Bsdiff differential packet Δ(Vn-1→Vn).

[0314] d. Gray release: Provides a 7-dimensional gray model (channel, user hash bucket, device fingerprint prefix, system language, region, battery level, network), with "AND" logic between dimensions; multiple CCP elements can exist for the same CrashID, and the gateway selects the effective strategy according to the "maximum percent priority" principle.

[0315] e. One-click rollback: Expose the Rollback REST interface, pass in CrashID and target version number, the center will revert the object storage pointer to the historical version within 5 seconds, and push RollbackCommand through a long connection channel, which will take effect on the client within 100ms.

[0316] III. Configure the Delivery Gateway

[0317] Access Protocol

[0318] It adopts HTTP / 3+QUIC, listens on UDP port 443, and supports 0-RTT handshake and connection migration; the success rate is ≥99.9% under weak network conditions (200msRTT / 2% packet loss).

[0319] Authentication and flow control

[0320] a. Four-dimensional token verification: AppKey + Token + Timestamp + Nonce

[0321] Token = HMAC_SHA256(secret, AppKey|Timestamp|Nonce), valid for 60 seconds, prevents replay.

[0322] b. Rate limit: 1 QPS per device per interface, 10000 QPS globally per AppKey. Exceeding the limit will return a 429 error with a Retry-After header.

[0323] Differential distribution

[0324] The gateway returns either a differential packet Δ(Vlocal→Vn) or a full packet based on the local version Vlocal carried in the If-None-Match header. The differential packet is double-compressed using Bsdiff+lz4, resulting in a typical 50KB file having a differential packet size of <2KB. The response body includes a Content-Signature, which the client verifies using its built-in ECDSA public key to prevent man-in-the-middle tampering.

[0325] Long connection rollback channel

[0326] The gateway maintains a bidirectional long connection based on QUIC Stream with a heartbeat interval of 30 seconds; RollbackCommand is issued via Stream ID=3, using Protocol Buffers encoding, with a message length of <256 bytes and a median end-to-end latency of <200ms.

[0327] IV. Client SDK (Core Module on the Client Side)

[0328] Default crash configuration cache

[0329] The SDK includes a built-in DefaultConfig.json file in the assets directory.

[0330] The Application#attachBaseContext stage maps the data to read-only memory using mmap to prevent frameworks like Xposed from tampering with it; if mapping fails, it falls back to reading a normal file.

[0331] Differential parsing engine

[0332] a. The download thread uses the OkHttp3+QUIC plugin, which supports connection migration; after the download is completed, the Bspatch algorithm is used to merge the files. The merging process uses a two-pointer sliding window. The peak memory usage is equal to the old file + the difference packet + 1MB output buffer, and the time taken is less than 10ms (for a 50KB file).

[0333] b. The merge result atomically replaces the local LatestConfig.json using rename() and fsyncs the directory; if the merge fails, the old file is retained and PatchFailed is reported.

[0334] Custom UncaughtExceptionHandler

[0335] The priority is set to the highest. Within uncaughtException(), the thread identity is checked first, and only the main thread enters the strategy branch if an exception occurs. The matching order is: CrashID exact match → MobileBERT semantic similarity ≥ 0.92. If the match is successful, the Looper is restarted, the Activity is delegated, or the interception is abandoned based on the level field.

[0336] Cascaded Strategy Counter

[0337] It uses SharedPreferences atomic writing with the key format crash_cnt_{CrashID}, which automatically expires after 24 hours. When the same CrashID triggers ≥3 hot restarts, a local ProtectFlag is generated, and the ID is downgraded to "Toast notification + close page" within the next 24 hours to prevent battery drain.

[0338] Proxy Activity Factory

[0339] A proxy instance is generated using Instrumentation.newActivity(), and the original Intent and ActivityInfo are reused when attaching. The lifecycle only executes onCreate→onResume, skipping callbacks such as onStart. Fragments and ViewModels are reused through SavedStateRegistry, achieving second-level recovery and zero loss of user data.

[0340] Abnormal snapshot reporting module

[0341] Snapshot data is written to ashmem (64KB), read by IdleHandler after hot restart, compressed with LZ4 and encrypted with AES-256-GCM, and uploaded via background HandlerThread; if upload fails, it is written to the SQLite retry table, with exponential backoff: 1s→2s→4s… up to 3600s.

[0342] Safe Mode

[0343] If any CrashID triggers ≥5 blocking actions within 10 minutes, or the cumulative hot reboot duration on a given day exceeds 120 seconds, the SDK will automatically enter safe mode.

[0344] Disable all non-core components (such as GIF decoding, WebView preloading, and advertising SDK) using PackageManager.setComponentEnabledSetting().

[0345] A system toast notification pops up saying "Simplified mode has been entered";

[0346] Only the main Activity is retained, and network requests are downgraded to Wi-Fi only;

[0347] Wait for the configuration center to issue the SafeModeExit command or exit automatically after 24 hours.

[0348] V. APM Loopback Channel (Closed-Loop Link)

[0349] Snapshot reception: The central exposed / snap / upload interface supports gzip+protobuf, and a single entry <32KB is considered successful if a 204 response is returned.

[0350] Real-time calculation: Flink tasks collect three metrics every 5 seconds: blocking success rate, user-perceived crash rate, and power consumption anomaly rate; automatic rollback is triggered when any metric deteriorates by more than 5%.

[0351] Feedback Writing: The calculation results are written to the configuration center's strategy recommendation engine. The engine automatically generates new CCP elements and marks them "system recommended" for operations personnel to adopt with one click.

[0352] VI. Computer-readable storage media

[0353] The media includes UFS, NVMe, SD card, or cloud object storage, and the computer program stored on it consists of the following modules: differential resolution module, hot-reboot Looper module, proxy Activity module, cascading counter module, and safe mode module; when the program is executed by the processor, it completes all the steps of the method described in claims 1-6. The media and program use block verification (CRC32+SHA256), with a block size of 64KB. During upgrades, only the differing blocks are replaced to ensure consistency after power failure.

[0354] VII. Mobile Terminals

[0355] The terminal includes an application processor, a baseband processor, a memory, and the aforementioned SDK system integrated into the APP; the memory stores the default crash configuration cache and executable instructions; when the main thread of the application process throws an uncaught exception, the processor completes policy matching, Looper hot-plugging, or proxy Activity restoration in milliseconds, without the need for a re-release, thereby achieving dynamic crash defense and improving user retention.

[0356] VIII. Feasible Parameters

[0357] Looper hot reboot time: Snapdragon 660 / Android 11 average 18ms;

[0358] Peak memory usage for differential merging: old files + differential packets + 1MB;

[0359] Safe mode entry threshold: ≥5 blocking attempts within 10 minutes or cumulative daily restarts >120 seconds;

[0360] One-click rollback end-to-end latency: median 1.3s, P99 < 5s.

[0361] Example:

[0362] An e-commerce app's product detail page experienced a BadTokenException, resulting in a crash rate of 0.87%. The operations team configured a CrashID strategy in the cloud, using a grayscale hash range of 0-9 (one in ten thousand) and a differential packet size of 1.8 KB. The client achieved second-level download speeds, 8ms merging time, and an 18ms hot restart of the Looper, reducing the crash rate to 0.05%, saving 96% of bandwidth, and completing full rollout in 45 minutes without any version releases.

[0363] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0364] 0.01% high-frequency grayscale: Through the dual-stage filtering of "FNV1a-64 + runtime JavaScript", the crash shielding strategy can be dynamically opened and closed at a granularity of 0.01% within the same channel, enabling multiple switching on a single device per day without repackaging or re-release, thus solving the problems of coarse granularity and slow rollback of traditional grayscale solutions.

[0365] Zero-perceptible traffic saving: Two-level differential compression reduces a typical 50KB configuration update to <2KB, and can still synchronize in seconds in weak network environments, reducing user traffic consumption by more than 98%; combined with mmap dual-pointer merging, it ensures that the merging time is <10ms and the peak memory usage is <1MB, avoiding the power consumption and memory jitter caused by traditional full download.

[0366] Power failure safety and automatic rollback: The 64KB segmented CRC32 check mechanism compares data in real time during the merging process. If an anomaly is detected, the configuration is immediately rolled back to the old configuration and reported, preventing configuration breakage due to power failure or data corruption and improving end-side reliability.

[0367] Device-friendly: Traffic, power consumption, and time consumption all decrease by an order of magnitude, allowing even low-end models to enjoy dynamic crash recovery without any noticeable impact, significantly reducing user complaints and application uninstallation rates caused by configuration updates.

[0368] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / looper> < / pkg> < / looper> < / looper> < / looper> < / looper>

Claims

1. A dynamically configurable APP crash handling method, characterized in that, Includes the following steps: a. The server uses a visual configuration platform to dynamically generate and maintain a crash configuration protocol based on the crash logs reported by the APM system. The protocol is a JSON array, and each member contains at least the following fields: exception class name, exception message, call stack, target APP version, target OS version, target brand and model, whether to close the exception page, and whether to display a Toast notification. b. The server sends the crash configuration protocol to the client via an interface; c. During the Application startup phase, the client pre-configures a default crash configuration cache and asynchronously retrieves the latest crash configuration protocol from the server to complete incremental updates of the local cache, ensuring real-time synchronization between the local and server environments; d. The client intercepts global uncaught exceptions in a custom UncaughtExceptionHandler and performs multi-level matching of the exception characteristics with the crash configuration protocol in the local cache. The multi-level matching order is: class name → exception message → call stack → APP version → OS version → brand and model. e. If a match is successful, the corresponding operation is performed according to the processing strategy defined in the protocol, which includes: For exceptions that are harmless to the business and have high repair costs, disable the crash and restart the main thread Looper to allow the APP to continue running; For recoverable exceptions, first disable the crash, then trigger a partial page retry or close the current exception page; For fatal exceptions, abandon the shielding and let the system's default Handler terminate the process; f. If a match fails, the system's default Handler will handle the task. g. The above steps can achieve online dynamic disaster recovery without the need for re-release or hotfix.

2. The method of claim 1, wherein, In step a, the visual configuration platform supports canary releases: it can issue differentiated crash configuration protocols for specific channel numbers, user groups, or device fingerprints, enabling fine-grained control over anomaly handling; In step c, the client uses a differential compression algorithm to incrementally update the crash configuration protocol, reducing traffic consumption and improving synchronization speed.

3. The method of claim 2, wherein, The specific implementation of step e, which involves disabling crashes and restarting the main thread Looper, is as follows: After catching the exception in the custom UncaughtExceptionHandler, the original Looper is terminated by calling reflection. Immediately create a new Looper and bind it to the original main thread, restore the main thread's message queue, and allow the UI layer to continue responding to user actions without being aware of it; Simultaneously, abnormal snapshots are recorded and asynchronously reported to the APM system for subsequent diagnosis.

4. The method of claim 1, wherein, The crash configuration protocol supports a "cascading strategy": when the same exception is triggered N times on the same device and still matches the blocking strategy, the processing intensity is automatically upgraded, changing from simply blocking to closing the page and displaying a Toast notification to the user. If it is triggered M more times, the application is actively restarted to prevent unlimited blocking from causing unknown side effects.

5. The method of claim 1, wherein, In step e, when performing a partial page retry for recoverable exceptions, a "proxy Activity" mechanism is adopted: a proxy instance of the original Activity is generated through reflection, only the onCreate→onResume lifecycle is retried, and the loaded Fragment and ViewModel are reused to achieve second-level recovery and zero loss of user data.

6. The method of claim 1, wherein, Step e, "blocking the crash and restarting the main thread Looper," further includes: e1. After catching an exception in the custom UncaughtExceptionHandler, immediately generate a minimized crash snapshot by calling the underlying libcorkscrew library via JNI. Only the 32-layer Java stack and 16-layer Native stack of the current thread are retained. The snapshot is written to a pre-created anonymous shared memory (ashmem) area with a fixed size of 64KB and a write time of <3ms, avoiding traditional I / O blocking the main thread. e2. Hidden using Android 11 and above The android.os.Loopers#recycleUnchecked() private API first safely releases the MessageQueue inside the original Looper and the native layer epoll handle, then calls Looper.prepare() via reflection to create a new Looper, and finally restores the original main thread's ThreadLocal. <looper> The field is atomically replaced with the new Looper, realizing a "hot-swappable" restart, with no ANR pop-ups visible in the Java layer throughout the restart process;< / looper> e3. Immediately after the new Looper starts, inject a one-time IdleHandler. When the IdleHandler is idle for the first time, it reads the crash snapshot in the ashmem, compresses it into gzip format (compression rate ≤15%) through asynchronous HandlerThread, and uploads it to the APM channel for the server to perform unsigned stack restoration and subsequent strategy optimization. e4. If the same crash ID is triggered ≥3 times within 24 hours and Looper restart is executed in each instance, the client will automatically generate a "self-protection" flag locally. In the following 24 hours, the crash ID will be directly downgraded to "Toast + close page" and Looper will no longer be restarted. This prevents abnormal power consumption caused by repeated restarts in extreme scenarios, thereby ensuring dynamic disaster recovery while achieving adaptive protection of device resources.

7. A dynamically configurable APP crash handling system, characterized in that, include: A visual configuration center, deployed in the cloud, is used for generating, canary releases, and version management of the crash configuration protocol as described in any one of claims 1-6; Configure a synchronization gateway to authenticate client requests, control traffic, and distribute requests differentially. The client SDK is integrated into the APP and includes a built-in default crash configuration cache, differential parsing engine, custom UncaughtExceptionHandler, cascading strategy counter, proxy Activity factory, and exception snapshot reporting module. The APM loopback channel is used to send abnormal snapshots back to the visual configuration center, forming a closed loop of "monitoring → configuration → protection → re-monitoring".

8. The system according to claim 7, characterized in that, The client SDK also has a built-in "safe mode": when the abnormal frequency of continuous triggering of the blocking policy exceeds the threshold, all non-core business modules are automatically shut down, only the main process function is retained, and the user is prompted to enter the simplified mode until the configuration center issues a release command. The configuration synchronization gateway uses the HTTP / 3+QUIC protocol, which can still maintain the configuration protocol delivery in seconds even in a weak network environment, ensuring that the anomaly handling strategy takes effect in real time. The visual configuration center provides a "one-click rollback" function: it can restore the full or grayscale configuration to any historical version within 5 seconds, preventing large-scale abnormal blocking failures due to policy misconfiguration.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method according to any one of claims 1-5.

10. A mobile terminal, characterized by The system according to any one of claims 7-8, comprising a memory, a processor, and integrated into an app, is used to dynamically defend against crashes without requiring a new version release, thereby improving user retention.

Images