Writing in the front
In the daily development process, programmers often need to temporarily cooperate with the server to check network request messages to troubleshoot problems. In this case, we would connect the phone to the development computer and run the development kit to view LogCat. This approach takes time and effort, and it will not work if there is no computer nearby or a corresponding development environment on the computer. In addition, developers usually have a test environment app installed on their phones, and they have to repackage to troubleshoot problems in production.
What we did before
To solve this problem, such debug logic was packaged in the production (for example, writing logs to a file) and set in a stealth-like way into the DEBUG interface. The disadvantages of this approach are obvious:
- Debug functions exist in the product, causing security risks
- Logs are written to a local file, which is much more difficult to view than Logcat in AndroidStudio
New solutions
The overall train of thought
- Create an app (Debug Server: Server) and add functions related to the DEBUG panel to this app
- Create a lib (Debug Client: Client) to implement the debug function for apps requiring the debug function to rely on
- The Server creates a ServerSocket, waits for Client connections, and broadcasts the IP address and port
- After receiving broadcasts from the BroadcastReceiver, the Client establishes a Socket to connect to the Server
- After the connection is successful, client-server two-way communication is realized through socket channels
- The Client executes the Server’s instructions and sends the results back to the Server
- The Server is responsible for sending instructions and displaying information sent by the Client
Security assurance
- The debugging related functions triggered by this scheme are no longer included in the APP, and users cannot trigger these functions
-
The debug function of the main app is triggered by the Server. As long as the validity of the Server is ensured, relevant functions of the debug can be protected from being arbitrarily triggered by third-party hackers:
In step 4, the hacker can set custom permissions and add android:protectionLevel="signature" to verify that the Server and Client have the same signature to ensure that the Server is not from a third-party source. To ensure that only apps with the same signature can receive the broadcast messageCopy the code
- The Server application installation package is not publicly available and generally only runs on the developer’s device
- Scenarios with higher security requirements can remove this feature with the official release of APK
Open source tools
DebugController
-
Android :app-debugger:1.3.2′, CSDN will automatically convert the first letter of android ‘A’ to uppercase ‘A’
-
Currently, only logCAT logs can be viewed. 2.1 Real-time logs can be viewed 2.2 Log Level Filtering 2.3 Log Keyword filtering 2.4 Different colors of Log Levels can be displayed 2.5 Long logs can be expanded or shrunk by clicking 2.6 Log details can be viewed by holding down. The system automatically formats JSON and supports scrolling and zooming. 2.7 Multiple logs for copying or sharing 2.8 Clearing current logs
-
Function is easy to extend 3.1 Client add AbstractMessageProcessor subclass for message processing DebugController. AddProcessor (processor)
3.2 the Client sends a message to the Server AbstractMessageProcessor. SendMessage (the message)
3.3 Server to add IServerMessageProcessor implementation classes for message processing ServerMessageProcessorManager. AddProcessor (processor)
3.4 Server to send information to the Client ServerMessageProcessorManager. SendMessageToClient (processor, the message)
Finally, attach a few operation effect pictures: