default title

In Android development, we often encounter situations where third-party components (such as GMS) automatically pop up activities in specific scenarios. These outdated pop ups often disrupt the normal business logic of the product, and since we cannot directly modify GMS's internal code, we can only find a solution at the system level. This article will provide a detailed introduction on how to block specific GMS activities by intercepting the activity initiation process at the Framework layer.

Problem background: Uncontrollable GMS pop-up window

GMS (Google Mobile Services) is an important component of the Android ecosystem, which includes a large number of services and components. In practical use, we have found that GMS automatically pops up specific activities under certain triggering conditions (such as the one mentioned in this article) com.google.android.gms.nearby.discovery.fastpair.HalfSheetActivity）， These types of pop ups are not necessary for our business, but they can interrupt the user's operation process.

Due to GMS being a closed source component, we are unable to disable its pop-up logic through regular code modifications. Therefore, we will shift our approach to the Framework layer - filtering and blocking the target activity by intercepting its startup process.

Technical Research: Analysis of Activity Launch Process and Intercept Points

To implement activity interception, it is first necessary to have a deep understanding of the startup mechanism of activities in the Android system. In the Framework layer of Android, the startup logic of Activities is mainly encapsulated in ActiveStarter.java (based on Android 14 code), where the Execute() method is the core entry point for the startup process.

By analyzing the source code, we can find that the execute() method will first parse the activity information to be started (mRequest. activityInfo), and then call executeRequest() to perform specific startup operations. This means that the relevant information of the target activity (such as component name, package name, etc.) has already been prepared before the call to ExecuteRequest(), which is the ideal time for us to implement interception.

As a key node in initiating the process, executing the request () at this time can ensure obtaining complete activity information and block the process before executing the initiation operation, avoiding ineffective resource consumption.

Implementation plan: Add interception logic in ActiveStarter

Based on the above analysis, we have decided to add interception logic in the ActiveStarter. ExecuteRequest() method. The specific implementation steps are as follows:

1. Define interception list

Firstly, we need to maintain a filter list of activities that need to be intercepted, which includes the component information (package name+class name) of the target GMS activity. The component name can be obtained in standard format (such as com.google.android.gms/com.google.android.gms.nearby.discovery.fastpair.HalfSheetActivity）。

2. Add filtering and judgment in the startup process

In the executionerRequest() method, when the system completes the parsing of activity information and the startup status is STARTS_SUCCESS, we intercept and judge the target activity:

The core logic of this code is: when the name of the currently started Activity component is detected to exist in the interception list, the startup result err is set to START_CANCELED, thereby blocking the activity's startup process.

Verification result: interception effect test

To verify the effectiveness of the interception logic, we directly launched the target GMS Activity through ADB command for testing:

adb shell am start -n com.google.android.gms/com.google.android.gms.nearby.discovery.fastpair.HalfSheetActivity

After executing the command, the system returns the following result:

Starting: Intent { cmp=com.google.android.gms/.nearby.discovery.fastpair.HalfSheetActivity }

Error: Activity not started, unknown error code -96

Among them, the error code -96 corresponds to the START_CANCELED status we set in the code, indicating that the interception logic has successfully taken effect - the target activity's start request has been rejected by the system, achieving the expected interception effect.

Summary and Expansion

We have successfully implemented blocking of specific GMS activities by adding interception logic in the ActiveStarter of the Framework layer. The advantage of this approach is that:

No need to modify GMS source code, suitable for control scenarios of closed source components;

The interception point is located in the early stage of the activity initiation process, which can effectively avoid invalid page drawing and resource loading;

By configuring through a list, it is easy to expand and maintain the target activities that need to be intercepted.

In practical applications, we can dynamically adjust the filter list according to business needs to achieve fine-grained control of pop ups in different scenarios. Meanwhile, this approach can also be extended to other scenarios that require intercepting system or third-party component activities, providing a feasible technical solution for customizing the Android system.