Detailed explanation and practical application of Android system service DropBoxManagerService

1. Background

As the number of company applications increases, it is necessary to centrally collect some crash data and logs of some of the company's online applications for analysis and processing. During this practice, it is learned that the system data/system/dropbox directory will generate relevant log files for all applications.

This directory is managed by DropBoxManagerService, one of the Android system services, so I read the source code related to DropBoxManagerService in detail, hereinafter referred to as DBMS.

DBMS may be one of the Android system services with less source code, so it is relatively simple to read. After reading it, I found that it is actually a simple log file management service.

When we record and manage some local log files of the application, we can refer to the design scheme of file management in the DBMS source code.

Assuming we don’t read the source code, what should we consider if we design a log file management system ourselves?

In addition to the most basic solution for obtaining various log files, we can propose several points to consider for file management:

1. What strategy is used to access the log?
2. What fool-proofing strategies should be designed?
3. Whether it is necessary to provide external interfaces and which interfaces to provide
4. How to ensure performance
5. How to solve the problem of multi-process
6. How to deal with lost files
7. How to notify users of file changes

Let's take a look at DBMS with the above questions.

2. Introduction to DropBoxManagerService

DropBoxManagerService is one of the services of the Android system and adopts a C/S structure:

• Client: DropboxManager, used to provide an interface to the application layer.
• Server side: DropBoxManagerService, a system service that manages the system directory (data/system/dropbox).
• System Setting database: responsible for managing some configuration information of DBMS.

The overall architecture relationship is shown in the following figure:

2.1 Introduction to DropBox Directory

The directory structure of this directory is shown in the figure below:

It contains some system log files. The file names and suffixes are different for different types of files.

2.1.1 File Format

[email protected]

• tag: represents the log type, common tags: data_app_anr, system_app_crash, data_app_nativecrash, where data_app represents a normal application and system_app represents a system application
• timeStampMillis: The timestamp of the log, which is usually equal to the time of the crash. In some cases, the system will make some adjustments.
• extentions: suffix name, common file suffix names: .txt, .lost, .txt.gz, .tmp, general log files are .txt or .txt.gz, and the records after the file is deleted will be named .lost

The advantage of this file naming method is that you can tell at a glance what type of file it is.

2.1.2 Common files

1. JE Files:
   [email protected]
2. NE file:
   [email protected]
3. ANR File:
   [email protected]

It also includes some other system error logs, memory, restart related, etc.

2.2 Provided Interfaces

2.2.1 Add files

addData/addFile/addEntry

2.2.2 Get File

getNextEntry, get the desired file based on tag and timestamp.

2.2.3 Dump directory information

Get some information about the DropBox directory: number of files, file list, file details, etc. You can use the command line operation (dumpsys dropbox).

 $ dumpsys dropbox
 Drop box contents : 131 entries
 Max entries : 1000
 // The following is omitted......

2.2.4 Other CMD commands

Provides some other CMD operation commands, such as set-rate-limit, add-low-priority, etc.

2.3 Directory Control Configuration

2.3.1 Default basic configuration and file clearing strategy

These configurations are stored in the system's setting database and can be accessed through settings.global.

The configuration of file storage mainly includes the following dimensions:

1. File survival time (3 days by default);
2. Maximum number of stored files (1000 by default);
3. Maximum number of files in low memory conditions (300 by default);
4. The space available for the DropBox directory (10MB by default);
5. The DropBox directory occupies a maximum of 10% of the available storage (available storage = system available storage - system total storage * reserved ratio);
6. The percentage of total storage that DropBox needs to reserve (10%)
7. The interval for scanning disk space when clearing space;
8. Minimum file size to be compressed.

Based on the above configuration, we can know the log file clearing policy under this directory, and the files will be deleted in time after the configuration limit is triggered.

The file cleanup policy will be executed in the following three situations to prevent DropBox from taking up too much space:

1. The device is low on memory;
2. The setting configuration has changed;
3. Add files.

At the same time, when adding files, if they exceed the configured available space, they will be discarded.

 /**
 * Trims the files on disk to make sure they aren't using too much space.
 * @return the overall quota for storage (in bytes)
 */
 private synchronized long trimToFit ( ) throws IOException {
 return mCachedQuotaBlocks * mBlockSize ;
 }

2.3.2 File deletion and marking strategy

When the above strategy is not met, some files will be deleted. After deletion, an empty file named .lost will be added to DropBox to mark the deleted files.

2.3.3 File type control

DropBoxMangerService also has control over the types of files that can be stored, mainly control over TAGs.

 public boolean isTagEnabled ( String tag ) { }

2.3.4 Permission Control

Using DropBox requires the READ_LOGS permission and the PACKAGE_USAGE_STATS permission.

2.4 Read and Write Strategies

This part involves several key methods and properties of DBMS, mainly initialization (init), adding files (addEntry), getting files (getNextEntry), and file types (EntryFile).

The DBMS is started by SystemServer as a system service. Adding files (addEntry) and getting files (getNextEntry) will be initialized (init) when called.

Each file will be converted into an EntryFile class for management. The relationship is shown in the figure below:

Let's take a look at the details of initialization, EntryFile, adding files, and getting files:

2.4.1 Initialization

Initialization will cache the DropBox file list into memory.

 /** If never run before, scans disk contents to build in-memory tracking data. */
 private synchronized void init ( ) throws IOException {
 // Code omitted......
 File [ ] files = mDropBoxDir .listFiles ( ) ; // List all files
 for ( File file : files ) {
 EntryFile entry = new EntryFile ( file , mBlockSize ) ; // One log file corresponds to one EntryFile object
 enrollEntry ( entry ) ; // Add to mAllFiles
 }
 }

Initialization time:

• Device storage capacity low broadcast callback
• Set configuration item modification
• Adding a log file
• Get log files
• dump command line lists some contents of DropBox

2.4.2 EntryFile file attributes

Each file corresponds to an EntryFile, and the size is counted by the number of blocks. The reading and writing involved in the DBMS are all performed based on the blockSize of the disk, which will be more efficient.

 static final class EntryFile implements Comparable < EntryFile > {
 public final String tag ; // Log file tag, type
 public final long timestampMillis ; // Timestamp of log file
 public final int flags ; // Log file flags, including TEXT, EMPTY, and GZIPPED
 public final int blocks ; // Number of blocks to store files
 }

2.4.3 Adding Files

Add a log file, common in the addErrorToDropBox method call in Ams.

Adding a file control policy

① The .lost file format is not allowed to be added.

 // If you add a .lost file, throw an exception
 if ( ( flags & DropBoxManager .IS_EMPTY ) != 0 ) throw new IllegalArgumentException ( ) ;

② TAGs that are not allowed to be recorded will not be added.

 // Read from the settings whether this tag is allowed to be recorded
 if ( ! isTagEnabled ( tag ) ) return ;

③ Write according to the disk block size set by the system to improve writing efficiency.

 int bufferSize = mBlockSize ;

④ Correction of abnormal timestamp files: Before writing files, files with modification times exceeding 10s from the current time will be renamed and added to the cache file list.

 // Find all files after 10 seconds of the current time
 SortedSet < EntryFile > tail = mAllFiles .contents .tailSet ( new EntryFile ( t + 10000 ) ) ;
 EntryFile [ ] future = null ;
 if ( ! tail .isEmpty ( ) ) {
 future = tail .toArray ( new EntryFile [ tail .size ( ) ] ) ;
 tail .clear ( ) ; // Clear all files older than the current time from the file list mAllFiles
 }
 // Code omitted......
 for ( EntryFile late : future ) {
 if ( ( late .flags & DropBoxManager .IS_EMPTY ) == 0 ) { // Rename the files older than the current time, increase the timestamp by 1 , and add them back to mAllFiles
 enrollEntry ( new EntryFile ( ) ) ;
 }
 }

⑤ The order of adding files is to create a temporary file first, and then use the file's rename method. The rename method is an atomic operation to ensure the safety of concurrent operations.

 // Save the file through the rename method to ensure the safety of concurrent operations
 temp .renameTo ( file ) )

⑥ After the file is added, a broadcast notification is sent. The broadcast is divided into real-time broadcast and delayed broadcast. Delayed broadcast is used to notify files with lower priority.

 // Low priority can send delayed broadcast
 mHandler .maybeDeferBroadcast ( tag , time ) ;
 // Send real-time broadcast with high priority
 mHandler .sendBroadcast ( tag , time ) ;

2.4.4 Get File

The logic of DBMS to obtain files is relatively simple. We can understand the meaning of the method name getNextEntry(String tag, long millis,...). It mainly finds the first file after the timestamp passed in by the user.

 for ( EntryFile entry : list .contents .tailSet ( new EntryFile ( millis + 1 ) ) ) {
 return new DropBoxManager .Entry ( entry .tag , entry .timestampMillis , file , entry .flags ) ;
 }

2.5 Source code reading summary

2.5.1 Answer the questions we asked before reading

① Log access strategy

• The file list will be initialized into memory when low storage, adding or acquiring files, etc.

② What fool-proofing strategies should be designed?

• Provides restrictions on file size, storage ratio, etc.
• Files will be cleared when storage is low or configuration changes occur.
• The configuration is saved in the setting, and then the configuration changes are monitored through ContentObserver.

③ What interfaces are provided to the outside world?

• Provides interfaces for adding, acquiring, and cmd commands, taking development and debugging into consideration.

④ How to ensure performance

• From the annotations in the source code, it can be seen that at present, each Entry, regardless of size, corresponds to a file, which is inefficient. The source code also lists TODOs, considering using a single file queue for optimization.

 // TODO : This implementation currently uses one file per entry , which is
 // inefficient for smallish entries -- consider using a single queue file
 // per tag ( or even globally ) instead. 

• Use the file system block size for reading and writing to improve efficiency.

⑤ How to solve the problem of multiple processes

• All file operations are written to temp first, and then the rename solution is used to ensure atomic operations and thus ensure the safety of concurrent operations.
• Both addEntry and getNextEntry are locked.

⑥ How to deal with file loss

• After a file is deleted, it will be replaced by an empty file with the same name, thus marking the file as deleted.

⑦ How to notify users of file changes

• The outside world is notified by broadcasting, and real-time and delayed broadcasts are set for files of different priorities.

2.5.2 Other points

1. File storage not only limits the size, but also the file type.
2. Not all files are compressed. Files larger than a certain size will be compressed.
3. The file name is very particular and contains relevant information such as application type, crash information, occurrence time, etc.
4. Files are retrieved in order of timestamps. For files with abnormal timestamps, the times will be adjusted.

2.5.3 User’s Perspective

Of course, in the process of using the source code, I also found some points that I personally think can be optimized.

1. During use, some file names should be added with the package name. For example, crash files generated by applications can be distinguished by package name, which is more user-friendly. Of course, the original intention of this design is for unified use of the system and may not be open to the outside world.
2. The authority control is too simple. Some abnormal logs of the business itself should be supported to be freely viewed.
3. The information of these files should be better maintained in a database to facilitate users. Of course, the design may become more complicated and not simple enough.

3. Source code reading application – log file management & reporting design

3.1 Overview

background:

Some applications want to report some logs of the application runtime, including runtime log, crash log, Hprof memory snapshot, captured exceptions, etc.

need:

Need to design a set of client log file collection, management and reporting functions

refer to:

1. The log storage management solution can refer to some strategies in DBMS
2. The log upload solution refers to some excellent models in the industry.

3.2 Solution

The overall solution adopts the producer-consumer model, with several key nodes

1. Producers: Multiple processes of the application, they may generate different types of logs and write them to the specified file directory
2. Temporary file directory: Set different directories to store temporary files according to file type and priority
3. Reporting data directory: The files in the temporary file directory will be written to the reporting data directory through the rename scheme
4. Consumer: reporting process, the reporting process will monitor changes through FileObserver to report files

The overall flow chart is as follows:

3.3 Determine the external interface

1. Get the file interface
2. File storage interface
3. Interface for statistics files (type, quantity)
4. Change the interface of some configuration policies
5. Active reporting interface
6. Other custom parameter interfaces

3.4 Determine the collection control strategy

1. Allow collection: When this configuration is turned off, no collection behavior will be performed locally
2. Log storage directory: a private directory solidifies a space
3. File naming method: refer to DBMS, process name_log type_foreground and [email protected]
4. Log type switch: Each log type is set to allow mobile phones to log
5. Collect log types: crash logs, runtime logs, memory snapshots, capture logs, other custom logs, etc.
6. Log survival time: Refer to DBMS, if the log exceeds a certain time, the file will be deleted.
7. Log storage space: Refer to DBMS and set a ratio of available storage on the mobile phone.
8. Number of log files: If the number exceeds the specified number, some files will be deleted; referring to DBMS, when the available storage is low, fewer files should be stored
9. For other initialization opportunities, please refer to DBMS

3.5 Determine the reporting control strategy

1. Whether to allow reporting. If this configuration is turned off, reporting behavior is not allowed.
2. Whether to allow reporting under traffic conditions . If this configuration is set to not allow, reporting is only allowed under wifi conditions.
3. The maximum file size that can be reported in a single time, single day, or single month under traffic conditions . This configuration controls the file size that can be reported by the application when reporting under traffic conditions.
4. The maximum file size that can be reported in a single time, single day, or single month under WiFi conditions . This configuration controls the file size that can be reported by the application when reporting under WiFi conditions.
5. Reporting interval , this configuration controls the reporting interval of low-priority files
6. Report failure limit . This configuration controls that after a certain number of failures, no more reports are allowed.
7. Reporting priority (low-priority logs do not need to be reported frequently)
8. The size of the file reported in this weak network situation
9. The amount of traffic allowed for a single time, day, or month. This configuration controls the amount of traffic that the application can use when reporting.
10. The minimum power limit that can be reported . This configuration controls the minimum power limit under reporting conditions.

3.6 Log Collection Solution

• DropBox logs: read locally first, then store and report
• Runtime log: Use adb logcat command to output logs to local storage
• Memory snapshot: dump Hprof file, and then do some cropping to make it easier to upload in a smaller size
• Other logs: real-time output records to local, report on demand

The above specific plans are not the focus of this article and will not be described in detail.

3.7 Log Writing Solution

Through the study of online courses, I learned that mmap has very high performance, so I finally adopted the "multi-process write + mmap" solution, and avoided the accumulation of cross-process calls, which is very efficient.

3.8 Log reporting solution

Refer to the real-time and delayed notification schemes for adding files to DBMS. Reporting is also divided into real-time reporting and delayed reporting.

• Real-time reporting: When a log appears, it is reported directly, targeting logs with higher importance
• Delayed reporting: reporting when a certain number or a certain time has been reached

3.9 Data Monitoring

3.9.1 Quality Control

3.9.2 Disaster Recovery Monitoring

IV. Conclusion

This article mainly covers two topics:

1. Read and analyze the DropBoxManagerService source code, including interface design, file storage management and control mechanisms and strategies, multi-process processing, and abnormal error prevention mechanisms

2. Application log collection and reporting scheme, mainly referring to the design of DropBoxManagerService source code

We often emphasize source code reading. What can source code bring us? I think there are mainly the following points:

• Improvements in coding technology
• Thinking of analyzing problems
• Solution Design
• Application of Design Patterns

This article is just a starting point. With the help of the above cases, I briefly talked about the application of DBMS source code and source code reading. I hope it can bring some inspiration to everyone in source code reading, and at the same time give you an understanding of some uncommon services of the Android system.