Overseas APP Push (Part 1): Differences Between Manufacturer Channel and Google FCM Channel

Author: Aurora Senior Engineer - Shi Kunkun

The picture of the enterprise going to sea

In the context of the ongoing epidemic and the complex and changeable international trade environment, China's foreign direct investment flow and stock have ranked among the top three in the world for four consecutive years. Nearly 80% of Chinese enterprises will maintain and expand their foreign investment intentions and are optimistic about their foreign investment prospects. When an enterprise goes overseas, the first priority is to establish a channel of contact with users. Outside of the APP environment, the channels for reaching users overseas are slightly different from domestic users. Overseas is mainly based on email, while in China, SMS is the main channel, supplemented by social channels such as WeChat. In the APP environment, there is little difference between overseas and domestic users, and they are mainly based on APP push. Next, we focus on making some comparisons and analysis from overseas APP push channels.

Status of APP message push channel

Overseas, in addition to Apple, Android is still the leader in mobile phone manufacturers, with a monopoly of 19% of the market share. Xiaomi, OPPO, Vivo, and realme followed closely with a market share of 12%, 9%, 8% and 6% respectively.

Figure 1: Global smartphone shipments report in the fourth quarter of 2021 (data from market research agency Conuterpoint Research)

The channel through which corporate APP messages reach users, the most important thing is still push notification messages. Each head manufacturer has customized the Android native system, but it is still different from the domestic environment.

In mainland China, Google cannot use Google-related services due to geographical restrictions. Domestic manufacturers have castrated the GMS service suite at the system level, and Google's official FCM push channel is correspondingly unavailable. In turn, each manufacturer's own manufacturer channel is replaced. As the name implies, the vendor channel refers to the system-level push channel provided by the mobile phone hardware manufacturer. Because it is a system service, it always exists after the device is turned on, effectively ensuring the high availability of the push channel for long connections.

Overseas, because the Android system supports the Google FCM channel by default, and the network environment is not restricted by regions, the manufacturer does not castrate the GMS of the mobile phone exported overseas, but retains the coexistence of the manufacturer channel and the Google FCM channel. The Google FCM channel is a channel service that comes with the Android system. It maintains a long connection with the Google Firebase backend. The service belongs to Google rather than the device manufacturer. After the actual test and the official technical communication with the manufacturer, the use of the notification channel is summarized as follows:

The difference between vendor channel and Google FCM channel

So, since overseas Google services are unrestricted, why do manufacturers keep two channels? Are there any specific differences between them? There are indeed some differences.

The first difference is that the above-mentioned channels belong to different service providers. The manufacturer channel is provided by hardware equipment manufacturers, and the Google FCM channel is officially provided by Google.

Difference 2 : Vendor channel, when the network is smooth and the content of the push message is legal, push messages to the manufacturer's device through the vendor channel, regardless of whether the application process is alive or not, the message can be pushed in place. Therefore, the vendor channel is a guarantee for the efficient delivery of messages. At the same time, it also has a certain improvement in the activation, promotion and retention of enterprise users. In the FCM channel, when a message is pushed to an Android device through Firebase in the background, after the device receives the message, it will first decide whether to display the message according to a certain state of the application. If the APP process is actively killed by the user, it will not continue to display push messages.

For this rule, we were skeptical at first. If this is the case, then there is no advantage of high-availability channel service compared with APP's own implementation of message push. Is it just to help developers simplify the implementation process of push service? Reduce development costs? With this question in mind, we launched a special test and analysis. The analysis process is as follows:

• Verify the display of messages when the process is alive and killed.
• Analyze the lifecycle state of a message
• In-depth analysis of system source code, GMS source code, FCM source code
• Conclusion

The following is the specific analysis process, which involves the analysis of the system source code. If you are not interested, you can skip reading and look directly at the final conclusion.

01. Verify the phenomenon of message display when the process is alive and killed

a. Go back to the background, stay inactive for 2 hours, connect to the phone via usb, enter ADB mode, and after executing the ps command, the process still exists, indicating that the system has not reclaimed resources. At this point, a push message is sent, and as expected, the notification message is displayed normally.

b. Exit to the background, through recent tasks, swipe to kill the APP

Similarly, after entering ADB, check the process status through the ps command. The process no longer exists, but it is uncertain whether the resources are reclaimed by the system in time. At this time, a push message is sent, and the notification message can be displayed normally. It is also more in line with the advantages of the manufacturer's channel. c. Enter the application details and forcibly stop the APP

Unsurprisingly, the process must no longer exist, and so does the ps command to view it. Likewise, it cannot be determined whether resources are reclaimed by the system in a timely manner. At this time, the push message is sent, but the notification message cannot be displayed normally. It is speculated that the FCM channel does not depend on the survival of the APP process. This feature is superior to the APP's own implementation of push notifications.

d. Restart the phone

After restarting the phone, since the application has not received the broadcast permission to restart the system, the process must no longer exist, and at the same time, the resources must also be recycled by the system. At this time, a push message is sent, and the notification can still be displayed normally. This further confirms that the system caches a certain state of the application, and FCM will decide whether to display the notification according to the state.

02. Analyze the life cycle state of the message

With the above test phenomenon, then the next focus is to analyze why after forcibly stopping the APP, the notification cannot be received and displayed normally. First look at the response of the push API, which is normal. The push task has been submitted to the Google Firebase backend, so let's assume that the server has been sent to the device. Capture the on-site system log through adb logcat >log.log, and the following prints are in the log:

 16600 16600 W GCM : broadcast intent callback: result=CANCELLED forIntent { act=com.google.android.c2dm.intent.RECEIVE pkg=cn.jiguang.junion.jpushtestdemo (has extras) }

It is confirmed that the message has been delivered to the device normally, so it is suspected that the message broadcast of the GMS is not sent normally.

03. In-depth analysis of system source code, GMS source code, FCM decompiled code

First, according to the FCM method invocation chain, start from the message distribution and follow up to confirm its invocation steps.

a. FirebaseMessagingService

It is traced in the system source code that FirebaseMessagingService is responsible for distributing notification messages to the SDK.

b. EnhancedIntentService is responsible for parsing and processing received messages

c. Continue to analyze where the message is received, and track that the message in the broadcast is transmitted to the Service in the form of AIDL

Then send to FirebaseInstanceIdReceiver

d. The final broadcast source CloudMessagingReceiver

Therefore, it can be clearly known that the message of FCM is also from the broadcast.

04. Conclusion

Finally, the answer was found in AMS. After the application is actively killed by the user, the system directly filters out the broadcast to which the dead process belongs, so that no broadcast is sent to it.

In the Android system, after the application is actively killed by the user, it will call finishForceStopPackageLocked() in ams to send an internal broadcast: ACTION_PACKAGE_RESTARTED, which will limit the self-start of the package or notify the removal and so on. The broadcast is sent through sendBroadcast. In AMS broadcastIntentLocked, intent.addFlags(Intent.FLAG_EXCLUDE_STOPPED_PACKAGES) is explicitly added; the Flag will later find the cache from the system and filter the broadcast code:

 registeredReceivers = mReceiverResolver.queryIntent(intent,resolvedType, false /*defaultOnly*/, userId);

Inside the IntentResolver.queryIntent method there is a call:

 final boolean excludingStopped = intent.isExcludingStopped();
if (excludingStopped && isFilterStopped(filter, userId)) {  -------这里会过滤Stopped 和进程Stop的    
if (debug) {         Slog.v(TAG, " Filter's target is stopped; skipping");   
 }
}

​isExcludingStopped() definition code:

 public boolean isExcludingStopped() {  return (mFlags&(FLAG_EXCLUDE_STOPPED_PACKAGES|FLAG_INCLUDE_STOPPED_PACKAGES))== FLAG_EXCLUDE_STOPPED_PACKAGES;} 

The official issues also have a similar official reply. If you are interested, you can read:

Quote from: https://github.com/firebase/firebase-android-sdk/issues/2917

For more information on the integration methods of overseas vendor channels, please see the next breakdown.

About Aurora

Aurora Mobile (NASDAQ: JG), founded in 2011, is a leading customer interaction and marketing technology service provider in China. At the beginning of its establishment, Jiguang focused on providing stable and efficient message push services for enterprises. With its first-mover advantage, it has grown into a mobile message push service provider with a far leading market share. With the continuous strengthening of enterprises' demand for customer contact and marketing growth, Jiguang has proactively launched solutions such as message cloud and marketing cloud to help enterprises achieve multi-channel customer contact and interaction needs, as well as artificial intelligence and big data. The application of marketing technology to help the digital transformation of enterprises.