From the submission of the AAB file to pre-review approval, your AAB file enters the GP review system and starts queuing. The Google review system will analyze our AAB file, performing a machine review of the code and UI, with a particular focus on the code. Both static and dynamic analysis are the core areas of the review process, with most issues related to code integrity, malware, and violations being identified at this stage. Therefore, this step is crucial for a successful app launch and for version updates and iterations.

App Code Machine Review

Static Analysis of the AAB File:

1. Hash Value Comparison
   In anti-reverse engineering efforts, the app’s complete files are hashed and encrypted according to a certain rule. During runtime, the app files are extracted and hashed again using the same rule, then compared to the original hash values to prevent malicious modifications. It’s highly likely that Google uses similar methods to compare the file similarity between our app and other violating apps as part of account association. It’s important to note that changing only the name of a file does not change its hash value!

2. Signature Files
   Never use the same signature file for signing different apps, especially if the signature is from a previously violating app.

3. Manifest Information
   Google will check whether the content in our Manifest file (such as various configuration settings) is compliant. For apps from certain regions (like "Ma Jia Bao"), the Manifest files are often quite similar, which can affect the review process.

4. Resource Files (Res, Assets)
   Google reviews whether resource files are in violation, checking for things like image content infringement, string content compliance with app content classification, etc. Resource files with high similarity to those of violating apps are also a focus of the review. Comparison methods may be similar to the first point. For game products, asset review is usually stricter.

5. Dex Files
   The section information and function code in the Dex files are the primary focus of machine reviews. To understand the section information of Dex files, one must learn about the Dex file format, which can be roughly understood as consisting of a header, index section (xx_ids), and data section (data). Function code is the main point of code review, focusing on whether the code is highly similar to previously violating code or contains malicious code.

6. SO Files
   Understanding SO files requires knowledge of reverse engineering. The section information and exported functions in SO (ELF) files are likely to be areas of Google’s review. Many SDKs generate SO files from C++ code, so the choice of SDK is important. Avoid using SDKs from small companies or any potentially risky SDKs in our projects.

Google Play’s review system performs a series of operations on the app package files and ultimately generates a static analysis feature table, which will be compared against Google’s backend violation database for future reference.

Runtime Dynamic Analysis

After static analysis, the review proceeds to the more stringent dynamic analysis phase, where Google Play may simulate the execution of our AAB file in a sandbox (virtual execution environment) to comprehensively analyze the app.

1. Java/Kotlin/Flutter/Compose API Call Chain
   Regardless of which development language is used, all code will run on the Java Virtual Machine and be converted into Java bytecode. Google will examine the API call chain to determine if we are using outdated or violating APIs and whether there are any security vulnerabilities in the code. They will also check for code overlap with other violating apps.

2. SO File C++ Code API Call Chain
   Similar to Java API calls, Google will review the C++ API calls in SO files. It is recommended to use self-developed SDKs and avoid small or risky third-party SDKs or open-source libraries that might not be properly regulated, as they could have been used in violating apps.

3. Activity and Fragment Stack (Full Path) Information
   Information related to the app's UI instances will be stored in the stack. Google will check for code overlap with other violating apps in the stack, which could trigger account association.

4. App-Created Directory Files
   This point is often overlooked, especially during the development of apps in certain regions. App-created directory file names inside the app can easily be scrutinized and may cause association issues during review.

5. Network Behavior (Interaction with the Backend)
   Not only the app’s code, but also its interaction with backend servers is a focus of the review. Domain names, paths, and JSON structures that match those of violating apps can lead to penalties or account association.

6. Log Analysis
   Details such as log print points, information, and search keys are often overlooked. If two apps with different package names produce highly similar log outputs when logging is enabled, they may easily be flagged as associated.

After simulating the app’s operation, Google Play generates a dynamic analysis feature table, which is also compared with Google’s backend violation database.

UI Interface Review

In summary, during the simulation run, Google Play will take screenshots of every interface and compare them against its powerful backend violation database to determine whether the app resembles other violating apps, if it has any association with them, or if its UI elements violate intellectual property rights.

Key Points

After extracting a variety of complex feature points, static analysis and dynamic analysis feature tables, along with UI interface screenshots, will be compared against Google’s backend violation database to check for associations with violating apps, malicious software, or code violations. This comparison will ultimately output a threshold to determine whether the app passes the review or receives more severe penalties.

It should be noted that the above analysis is based on my personal understanding of Google Play’s machine review strategy. The actual review process is likely far more extensive and strict, and is something we should continue to study.

Lastly, I sincerely wish that all your apps pass the review on the first attempt, and that your business grows smoothly.