Outsystems FAQ

Q: Managing google-services files in projects with several possible package names

In the plugin, you can add multiple google-services.json files to your project, and the correct one is selected based on the package name set during the build. Create a ZIP archive named google-services.zip containing each google-services.json file, add this ZIP to the project with the action set to Deploy to Target Directory, and specify the target directory as google-services/package_name (for example, google-services/com.pushwoosh.demo). During the project build, specify the corresponding package name.

Q: Resolving conflicts between multiple plugins depending on FirebaseMessagingService

Android does not resolve such conflicts automatically, so it must be done manually by writing a router class in Java named FirebaseMessagingRouterService that handles the conflict. Save it as FirebaseMessagingRouterService.java, place it into a ZIP archive named FirebaseMessagingRouterService.zip, add this archive to the resources of your Outsystems project, set the action to Deploy to Target Directory, and specify the target directory as FirebaseMessagingRouterService.

Q: Each new notification replaces the previous one on Android

By default the Pushwoosh Android SDK posts every push with the same notification id, so a new push replaces the previous one. Starting with Pushwoosh Plugin component version 4.7.0, add the SetMultiNotificationMode client action to a flow that runs after initialization (for example, the OnInitializeOver handler, after RegisterDevice) — each push then appears as a separate notification. Android groups them into one expandable stack, which is standard system behavior.

Managing google-services files in projects with several possible package names

In the plugin, you can add multiple google-service.json files to your project, which will be selected based on the package name set during the build.

If you want to switch between multiple Firebase projects (each with its own google-services.json configuration file), follow these steps:

Create a ZIP archive. Place each google-services.json file into a .zip archive named google-services.zip.
When adding this .zip file to the project, set the action to Deploy to Target Directory and specify the target directory as google-services/${package_name}.

For example, if the project package name is com.pushwoosh.demo, the target directory will be google-services/com.pushwoosh.demo.

During the project build, specify the corresponding package name.

Resolving conflicts between multiple plugins depending on FirebaseMessagingService

Android does not automatically resolve such conflicts, so it must be done manually. Since each plugin has its own logic, we cannot provide universal code that works for all possible plugins.

Here’s how to address conflicts:

Write a router class in Java to handle the conflict. This class must be named FirebaseMessagingRouterService.

Refer to the guide for an example: Using Pushwoosh SDK with other FCM services.

Name the Class File. The file containing this class must be named FirebaseMessagingRouterService.java.
Place this file into a .zip archive named FirebaseMessagingRouterService.zip.
Add this archive to the resources of your Outsystems project.
Set the action to Deploy to Target Directory, and specify the target directory as FirebaseMessagingRouterService.

Each new notification replaces the previous one on Android

By default, the Pushwoosh Android SDK works in single notification mode: every push is posted with the same notification id, so each new one replaces the previous. It is not related to the device vendor or to collapse_key.

Starting with Pushwoosh Plugin component version 4.7.0, enable stacking with the ready-made SetMultiNotificationMode client action:

Update the Pushwoosh Plugin component from the Forge.
Refresh the dependency to the PushwooshPlugin module (Manage Dependencies).
Add SetMultiNotificationMode to a flow that runs after initialization — for example, the handler of the OnInitializeOver event, right after RegisterDevice. The action takes no parameters, and one successful call is stored by the SDK and survives restarts.

Each push then appears as a separate notification. Android groups them into one expandable stack with a counter — that is standard system grouping. Note: pushes sent with an android_tag value still replace each other regardless of the mode.