Method for acquiring Android application log data

Abstract

The embodiment of the invention provides a method for obtaining Android application log data, and belongs to the technical field of data processing, and the method specifically comprises the steps that a target application is created, a shared UserId is configured, and a consistent signature is used for packaging and installation, so that the target application obtains an independent UID; the same share UserId value is declarated in AndroidManifest.xml of the log collection tool, a signature key consistent with the target application is used for packaging, and after installation, the same Linux user ID is obtained to access private data of the target application; reading private data of the target application by using a log collection tool, and performing aggregation compression to generate a feedback data packet; when it is detected that user operation triggers a data export instruction, the system sharing menu is called to send a feedback data set to a third-party application or directly upload the feedback data set to a background server. Through the scheme disclosed by the invention, non-invasiveness, cross-version compatibility and transmission security are realized.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a method for obtaining Android application log data. Background Technology

[0002] Currently, existing technical solutions for obtaining user feedback logs mostly rely on scenarios where relevant code is added beforehand, and the feedback information obtained is largely limited to the logs. However, many problems cannot be discovered and analyzed in the logs due to various reasons such as incomplete logs, missing logs, logging not being enabled in the official release package, or configuration conflicts among some users. In such cases, if you want to confirm the root cause of the user's reported problem, you often need the user to install a test version with more logs, but some problems may not be reproducible after reinstalling.

[0003] It is evident that there is an urgent need for a non-intrusive method that is cross-version compatible and secure in acquiring Android application log data. Summary of the Invention

[0004] In view of this, the present disclosure provides a method for obtaining Android application log data, which at least partially solves some of the problems existing in the prior art.

[0005] This disclosure provides a method for obtaining Android application log data, including: Step 1: Create the target application and configure sharedUserId. Set android:sharedUserId="com.example.shared" in the target application's AndroidManifest.xml and package and install it using consistent signing to give the target application an independent UID. Step 2: Declare the same sharedUserId value in the AndroidManifest.xml of the log collection tool and package it with the same signing key as the target application. After installation, obtain the same Linux user ID to access the target application's private data. Step 3: Use a log collection tool to read the target application's private data, aggregate and compress it to generate a feedback data packet; Step 4: When a user operation triggers a data export command, the system's share menu is invoked to send the feedback dataset to a third-party application or directly upload it to the backend server.

[0006] According to a specific implementation of an embodiment of this disclosure, step 2 specifically includes: Step 2.1: The collection tool and the target application use the same digital signature certificate and android:sharedUserId configuration value; Step 2.2: Through the Android system's shared user ID mechanism, both can share the same Linux user ID, thereby gaining direct access to the target application's data directory.

[0007] According to one specific implementation of this disclosure, the private data includes a SharedPreferences configuration file, an SQLite database file, and a Logcat circular buffer log.

[0008] According to a specific implementation of an embodiment of this disclosure, the step of calling the system share menu to send to a third-party application includes: The system's native sharing interface is invoked to push feedback data packets to email or social media platforms.

[0009] According to a specific implementation of an embodiment of this disclosure, the step of uploading to the backend server includes: The feedback data packet is uploaded to the remote server backend via the HTTP / S protocol.

[0010] According to a specific implementation of an embodiment of this disclosure, step 3 further includes: The collected private data is transmitted to a remote terminal in real time via network protocols, including WebDAV, SMB / CIFS, FTP / FTPS, and NFS.

[0011] The scheme for obtaining Android application log data in this embodiment includes: Step 1, creating a target application and configuring sharedUserId, setting android:sharedUserId="com.example.shared" in the target application's AndroidManifest.xml, and packaging and installing it using a consistent signature to give the target application an independent UID; Step 2, declaring the same sharedUserId value in the log collection tool's AndroidManifest.xml and packaging it using the same signing key as the target application, obtaining the same Linux user ID after installation to access the target application's private data; Step 3, using the log collection tool to read the target application's private data, aggregating and compressing it to generate a feedback data packet; Step 4, when a user operation triggers a data export instruction, calling the system share menu to send the feedback dataset to a third-party application, or directly uploading it to the backend server.

[0012] The beneficial effects of this disclosure are as follows: Improved user experience: When users provide detailed log feedback, they do not need to reinstall the application version that includes the logging function, which simplifies the operation process and makes user feedback more convenient; Enhanced security: Log data is separated from the application package, avoiding the packaging of log information in the application installation package and reducing the risk of sensitive information leakage; High flexibility: Allows users to configure log upload strategies independently, including log level, sending timing and channel, to meet customized needs in different scenarios. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart illustrating a method for obtaining Android application log data according to an embodiment of the present disclosure. Detailed Implementation

[0015] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0016] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0017] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0018] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0019] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0020] Existing technical solutions for obtaining user feedback logs mostly rely on scenarios where relevant code is added beforehand, and the feedback information obtained is largely limited to the logs. However, many problems cannot be discovered and analyzed in the logs due to various reasons such as incomplete logs, missing logs, logging not being enabled in the official release package, or configuration conflicts among some users. In such cases, if you want to confirm the root cause of the user's reported problem, you often need the user to install a test version with more logs, but some problems may not be reproducible after reinstalling.

[0021] 1. The problem to be solved When users report problems, especially when online operations encounter abnormalities but do not crash, relying solely on logs is often insufficient to accurately pinpoint the root cause. The main reasons include: The scope of log recording is limited; The official release package may disable logging functionality; Some configuration conflicts will not trigger log output; Lost or missing logs make critical data unavailable.

[0022] This makes it difficult for the development team to reproduce the problem from existing logs, thus affecting the efficiency of quickly locating and fixing the issue.

[0023] 2. Existing Solutions Currently, most solutions attempt to address this issue using the following approaches: Log collection functionality is pre-integrated into the release package, allowing for more complete logs to be obtained through test or debug versions of the app; Use a third-party remote logging or error reporting platform (such as Firebase Crashlytics, Sentry, Shipbook) to centrally collect crash and log events. 3. Shortcomings of existing solutions (1) Users need to switch or reinstall a test version with logs; otherwise, log collection will be passively restricted.

[0024] (2) If the problem cannot be reproduced after reinstallation, the on-site conditions are lost.

[0025] (3) Incomplete log coverage and lack of key configuration information. (4) Although crash logs or event logs are common, they may not be relevant to configuration-related issues (such as permissions, language settings, and device brand differences).

[0026] (5) The log platform depends on the backend and pre-embedded points.

[0027] (6) Log information is packaged in the application installation package, which poses a risk of sensitive information leakage.

[0028] In summary, while existing solutions can cover some typical problems, they still cannot meet the requirements of "accurately recreating the user's situation" and "avoiding the user observer effect (because switching versions affects the user's state)".

[0029] 4. A new solution is needed. Therefore, there is an urgent need for a method that, with the user's consent, can capture real-time logs and configuration information without reinstalling or modifying the original package: (1) It can read configuration and temporary files in the original application's private directory; (2) Supports aggregation, compression, and sharing via the user client; (3) Do not introduce new versions or package switching; (4) Improve the integrity of log information and preserve the user's on-site environment.

[0030] The approach of using sharedUserId and signature consistency, combined with the installation of a standalone but non-intrusive log collection application, precisely addresses several shortcomings of existing technical solutions.

[0031] This disclosure provides a method for obtaining Android application log data, which can be applied to the debugging process of mobile terminal software in Internet scenarios.

[0032] See Figure 1 This is a flowchart illustrating a method for obtaining Android application log data according to an embodiment of this disclosure. Figure 1 As shown, the method mainly includes the following steps: Step 1: Create the target application and configure sharedUserId. Set android:sharedUserId="com.example.shared" in the target application's AndroidManifest.xml and package and install it using consistent signing to give the target application an independent UID. For example, in this embodiment of the disclosure, a bank's mobile app (the target application) experienced a transfer failure issue on some user devices. The development team needed to collect environmental logs, configuration data, and real-time error information from the user devices on-site without affecting normal user operation.

[0033] In practice, the development team opened the AndroidManifest.xml configuration file in the bank app's Android project files and... <manifest>Add the attribute android:sharedUserId="com.bankapp.shared.debug" to the root tag, then use the bank's exclusive digital signature key bank_release.keystore to sign and package the app, and then release the official version of the bank app to the app store.

[0034] When a user installs this version of the banking app, the Android system assigns them a unique Linux user ID (such as u10236), which becomes the basic identifier for subsequent data sharing.

[0035] Step 2: Declare the same sharedUserId value in the AndroidManifest.xml of the log collection tool and package it with the same signing key as the target application. After installation, obtain the same Linux user ID to access the target application's private data. Furthermore, step 2 specifically includes: Step 2.1: The collection tool and the target application use the same digital signature certificate and android:sharedUserId configuration value; Step 2.2: Through the Android system's shared user ID mechanism, both can share the same Linux user ID, thereby gaining direct access to the target application's data directory.

[0036] In practice, a standalone log collection tool app can be developed. The same attribute, android:sharedUserId="com.bankapp.shared.debug", can be set in the app's AndroidManifest.xml file. The app can then be packaged using the exact same bank_release.keystore signing key and uploaded to the bank's official website for users to download.

[0037] When a user downloads and installs the log collection tool from the bank's official website, the Android system automatically detects a sharedUserId value that is completely identical to the bank's app. Using the same digital certificate for signing, the system assigns the same Linux user ID u10236 to the log tool.

[0038] By using log tools, direct access to the bank's app's private directory can be obtained, allowing the reading of critical data from the transfer module.

[0039] Step 3: Use a log collection tool to read the target application's private data, aggregate and compress it to generate a feedback data packet; Optionally, the private data includes SharedPreferences configuration files, SQLite database files, and Logcat circular buffer logs.

[0040] Furthermore, step 3 also includes: The collected private data is transmitted to a remote terminal in real time via network protocols, including WebDAV, SMB / CIFS, FTP / FTPS, and NFS.

[0041] In practice, when a user's transfer failure is detected, the log collection tool is opened and the "Start Diagnosis" button is triggered to initiate the collection process. The tool automatically scans the bank's App private directory, extracts all XML-formatted configuration files (including security certificate configurations), SQLite database files (including recent transaction records), and captures the contents of the real-time Logcat buffer. It then filters error logs containing the keyword "TransferFailed" and packages the data into an encrypted diagnostic_data.zip compressed file.

[0042] Commands are sent via the remote console to enable the enterprise intranet SMB protocol transmission channel. The logging tool establishes a secure connection to \\bank-debug-server\live_logs to continuously upload real-time data streams during the transfer process, forming a dynamic log file user_device123_live.log in the bank's data center.

[0043] Step 4: When a user operation triggers a data export command, the system's share menu is invoked to send the feedback dataset to a third-party application or directly upload it to the backend server.

[0044] Furthermore, the step of sending the system share menu to a third-party application includes: The system's native sharing interface is invoked to push feedback data packets to email or social media platforms.

[0045] Furthermore, the step of uploading to the backend server includes: The feedback data packet is uploaded to the remote server backend via the HTTP / S protocol.

[0046] In practice, when a user action triggers a data export command, there are two corresponding data export schemes: Option A: Local sharing 1. The user clicks the "Generate Report" button; 2. The tool will pop up the system's native sharing menu (including options for WeChat / QQ / Gmail, etc.) 3. The user selects "Email" and enters support@bank.com 4. Automatically create an email with the title "Transfer Fault Diagnosis Report" 5. Send with an encrypted copy of diagnostic_data.zip. Option B: Direct transmission to server 1. When the tool detects that a user has clicked the "Secure Upload" button, it connects to the bank's security gateway via HTTPS. 2. Display a real-time upload progress bar (from 0% to 100%); 3. After the upload is complete, "Diagnosis ID: DL20230715008" will be displayed for users to query.

[0047] The method disclosed herein achieves zero intrusion, requiring no modification to the bank app, maintaining the original signature and functional integrity, and eliminating the need for users to log in again or interrupt business operations; it is real-time and accurate, capturing the complete runtime environment state at the moment of a fault, including volatile information such as memory data and thread stacks; it offers enterprise-level security, with data encrypted on the device side using AES-256, and the transmission channel supporting enterprise security protocols such as SMB signature / FTPS encryption; and it is user-friendly, requiring only three clicks for the diagnostic process (start → generate → send), automatically generating easy-to-understand progress prompts.

[0048] The tool was paired and installed on the released app (with sharedUserId configuration) and the corresponding tool application, covering multiple test devices. The tool successfully read the target application's logs and configurations without any user intervention or impact on the target app's normal operation, and ultimately successfully obtained the issue data from internal testing feedback.

[0049] The method for collecting Android application log data provided in this embodiment reads the logs and configurations of the original application by installing an independent log collection tool, without requiring the user to reinstall or update the application. Compared with the traditional solution that requires the use of a test version application with pre-built log collection function, forcing the user to replace or overwrite the version, affecting the usage environment, and may even lead to configuration or data loss, this solution avoids the user experience and environmental damage caused by the above operations. By using a mechanism that ensures consistency between sharedUserId and signature, the log collection tool can securely access the application's private directory, accurately read logs and key configuration information, and perform non-intrusive modifications. Compared to the original solution that required hot-swapping the log collection package, this solution maintains the immutability of the user data directory, avoiding data corruption, permission loss, or additional configuration conflicts caused by replacing the collection package. Users only need to install the log collection tool → trigger with one click → collect automatically → provide feedback on the collection package through common channels (such as email, social applications), without the need for a background installation process or complex operations, which significantly reduces the technical threshold, reduces operation steps, improves the feedback rate, effectively shortens the problem reproduction-collection-processing process time, and improves development and operation efficiency; Data access capabilities are achieved using the android:sharedUserId attribute and consistent signature. Although this mechanism has been marked as deprecated since API 29, it is still supported and can be combined with android:sharedUserMaxSdkVersion="32" to maintain compatibility. At the same time, it reserves alternative IPC paths, such as ContentProvider / AIDL, to ensure future upgrade feasibility and avoid relying on outdated solutions.

[0050] It should be understood that the various parts of this disclosure can be implemented in hardware, software, firmware, or a combination thereof.

[0051] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.< / manifest>

Claims

1. A method for obtaining Android application log data, characterized in that, include: Step 1: Create the target application and configure sharedUserId. Set android:sharedUserId="com.example.shared" in the target application's AndroidManifest.xml and package and install it using consistent signing to give the target application an independent UID. Step 2: Declare the same sharedUserId value in the AndroidManifest.xml of the log collection tool and package it with the same signing key as the target application. After installation, obtain the same Linux user ID to access the target application's private data. Step 3: Use a log collection tool to read the target application's private data, aggregate and compress it to generate a feedback data packet; Step 4: When a user operation triggers a data export command, the system's share menu is invoked to send the feedback dataset to a third-party application or directly upload it to the backend server.

2. The method according to claim 1, characterized in that, Step 2 specifically includes: Step 2.1: The collection tool and the target application use the same digital signature certificate and android:sharedUserId configuration value; Step 2.2: Through the Android system's shared user ID mechanism, both can share the same Linux user ID, thereby gaining direct access to the target application's data directory.

3. The method according to claim 1, characterized in that, The private data includes SharedPreferences configuration files, SQLite database files, and Logcat circular buffer logs.

4. The method according to claim 1, characterized in that, The step of sending the system's share menu to a third-party application includes: The system's native sharing interface is invoked to push feedback data packets to email or social media platforms.

5. The method according to claim 1, characterized in that, The steps of uploading to the backend server include: The feedback data packet is uploaded to the remote server backend via the HTTP / S protocol.

6. The method according to claim 1, characterized in that, Step 3 also includes: The collected private data is transmitted to a remote terminal in real time via network protocols, including WebDAV, SMB / CIFS, FTP / FTPS, and NFS.

Images