This approach is practically non-functional

[deakjahn]

To spare the trouble to other people trying to achieve the same, let's describe the situation. I guess most of us wanting to experiment with this are devs who have both

• a Google-based app in Google Play, with AdMob implemented. Still, we're not that satisifed with the fill and want to look into mediation to present more ads to our users,
• and a Huawei-based app in the AppGallery, with Huawei/Petals Ads implemented.

This mediation here would simply reuse what we already have in our Huawei app to fill in the gaps of the Google one. Sounds promising but, sadly, it fails. The problems, one by one:

1. This plugin is non-functional, as is (see Adapter doesn't report success #37 for a few problems). Those can be rectified, so it's not immediately a showstopper.

2. Pulling Huawei ads, through mediation or not, requires the same machinery as implementing pure HMS in our Huawei-based apps in the first place. The same SDK, the same agconnect-services.json, the works, in addition to the already present GMS SDK. This wouldn't necessarily be a probem (slightly larger app size, for sure) if Google Play currently accepts apps that contain HMS code. This is an open question now. They used to refuse it, that's why we needed the two-flavor approach described above (GMS app in Google Play, HMS app in AppGallery). I don't know what's the situation now and I couldn't try it myself because of:

3. Almost certainly all of us use different package names for our Google and Huawei apps (even if the second only has a .huawei suffix at the end). And that makes our agconnect-services.json (more precisely, the data contained within) invalid in the GMS+HMS mediation scenario: the package name no longer matches, hence we don't receive ads from Huawei. Actually, agconnect-services.json could now be replaced with code-based initialization, provided you don't use this plugin from GitHub but copy the source and integrate it with your own code. But this doesn't alleviate the problem.