GCM + flavors + build types = fail

[Diego Costantini]

Hi guys,
is it possible to have this combination working without file manipulation in gradle?

The problem is that GCM wants to be in the manifest, with an absolute package name, which instead changes based on the buildvariant.
All of this because I couldn't have GCM working while keeping GCMIntentService.java in main, where it belongs.

Do you know how I could solve this?

Here is the manifest I had to force for the particular buildVariant I need now:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.my.app.flavor1" >

    <permission
        android:name="com.my.app.flavor1.debugQA.permission.C2D_MESSAGE"
        android:protectionLevel="signature" />

    <application>
        <service android:name="com.my.app.flavor1.debugQA.GCMIntentService"/>
        <receiver
            android:name="com.google.android.gcm.GCMBroadcastReceiver"
            android:permission="com.google.android.c2dm.permission.SEND" >
            <intent-filter>
                <action android:name="com.google.android.c2dm.intent.RECEIVE" />
                <action android:name="com.google.android.c2dm.intent.REGISTRATION" />
                <category android:name="com.my.app.flavor1" />
            </intent-filter>
        </receiver>
    </application>
</manifest>

Thanks

[Xavier Ducrohet]

There's no easy fix right now but we're working on a new manifest merger that will support this use case.

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Diego Costantini]

Hi Xavier,
I just went through the description of the new merger and it seems very nice.

However I came to realize that it alone might not save me from the GCM issue.

I will have to test it again, but if I remember correctly, GCM grants permission only to the application with its same package name, meaning that it needs to be in a specific folder structure for each flavor and buildType.

So, for example, if I keep GCMIntentService in main (again, where it belongs in my opinion), it will not register because its package will be my.application and it won't be accessible from the application my.application.flavor1.type1 (and I would find out only by guessing at logs at runtime, btw).

In fact now I have a GCMIntentService in each possible combination i need (it gives me the creeps).

Could you please tell me I am doing it wrong? I cannot believe the GCM implementation is so "wrong".

Anybody else able to have one single GCMIntentService.java working for multiple build variants?

[Xavier Ducrohet]

You're talking about 

 <category android:name="com.my.app.flavor1" />

right?

The new manifest merger has a placehold for the final package name of the app so you can do

 <category android:name="${packageName}" />

and it'll get automatically replaced with the final package name.

[Diego Costantini]

yes, that part should be solved by injection through the new merger :)

however, unless I messed up with some relative path .GCMIntentService in the manifest (I was surprised by how the new merger uses the package in the manifest rather than from gradle with smart replacement), the file needs to be in my/application/flavor1/type1/GCMIntentService.java to be able to register to GCM, which makes all the tricks in manifest not enough (this is true for each variant i want, so one of those java files exactly the same, just in another folder)

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/KYldXW-YQ0E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Xavier Ducrohet]

Are you sure the service class has to be in the package name declared by the app? That sounds weird.

[Diego Costantini]

this answer gives me hope :)

we were able to make push work only that way, although we couldn't believe it was THE way.

once we enable the new merger we will try step by step to push that class back down to main.

[Diego Costantini]

I could fix it.
Now that I had a few hours to look into the code, I saw what was missed in the original implementation.
The code currently was trying to stick to the defaults, while it should just implement a custom broadcast receiver returning the location of the intent service, which is not in the application root by default, and in our case it is anyway in a project library :)