React-native-notifee: Notifee doesn't work when proguardrules is set to true

[kperreau]

Hello.

Notifee doesn't work when proguardrules is set to true, i mean, notification doesn't display.
If i set proguardrules to false, everything work fine, in dev mode and release google play.

Step to reproduce:
Just use notifee.displayNotification() function, nothing happen with proguardrules = true.

Versions:

"react-native": "0.62.2",
"@notifee/react-native": "^0.5.1",

This is relative to this issue: https://github.com/notifee/react-native-notifee/issues/21
But @Salakar ask me to create new issue, and yes license has been correctly added.

Please next time, test before release, i tested for you 3 times, and it's still not work.

Thank you.

[mikehardy]

I can confirm this. I had a trivial button hooked to a notifee local notification that works in dev/debug builds but is not working on my first release build test. I'm still working on confirming that my licensing is correct, and I'm still working on what my fully merged Android proguard/R8 shrink setup is.

@kperreau I have no idea what you mean by 'proguardrules = true' though, that's not a directive I'm familiar with.

(base) mike@kunashir:~/work/Kullki/ksocialscore/packages/public-app (rebranding) % grep -r proguardrules *
(base) mike@kunashir:~/work/Kullki/ksocialscore/packages/public-app (rebranding) % 

No hits on that string. I suspect it is a local variable in your bulid.gradle? I expect something more like this in your android{} block in app/build.gradle and to be precise you are asserting that when 'minifyEnabled true` you are having troubles?

    buildTypes {
        debug {
            shrinkResources enableProguardInDebugBuilds
            minifyEnabled enableProguardInDebugBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
            proguardFiles "${background_geolocation.projectDir}/proguard-rules.pro"
            signingConfig null // clear out built-in debug signing + force use signingConfig block

            // Firebase requires all signatures to be globally unique, so each package has unique config
            productFlavors.dev.signingConfig signingConfigs.devSigning
            productFlavors.qa.signingConfig signingConfigs.qaSigning
            productFlavors.staging.signingConfig signingConfigs.stagingSigning
            productFlavors.prod.signingConfig signingConfigs.prodSigning
        }
        release {
            shrinkResources enableProguardInReleaseBuilds
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
            proguardFiles "${background_geolocation.projectDir}/proguard-rules.pro"
            signingConfig null // clear out built-in debug signing + force use signingConfig block

            // Firebase requires all signatures to be globally unique, so each package has unique config
            productFlavors.dev.signingConfig signingConfigs.devSigning
            productFlavors.qa.signingConfig signingConfigs.qaSigning
            productFlavors.staging.signingConfig signingConfigs.stagingSigning
            productFlavors.prod.signingConfig signingConfigs.prodSigning
        }
    }

I haven't had a chance to check the adb output yet but the answer will likely be two parts at once:

1. any important libraries that Notifee depends on will need to be annotated or have a proguard-rules.pro chunk. I'm not sure what the dependent libraries are though
2. Notifee itself will need @Keep annotations in the important parts or we'll need a proguard-rules.pro chunk similar to this but notifee, and probably the notifee.app package prefix as well

# react-native-firebase section
-keep class io.invertase.firebase.** { *; }
-dontwarn io.invertase.firebase.**
# end react-native-firebase section

As for this

Please next time, test before release, i tested for you 3 times, and it's still not work.

I've worked with few groups that have as much of a testing focus as Invertase actually. I understand this is frustrating, I need this to work as well. But it is version '0.5.1' and alpha testing does have the connotation that users are testers. So here we are

You may try different '-keep' options in your proguard-rules.pro file and report back? I won't have time to look again for a little while but I give a 50/50 shot on just keeping io.invertase.* and notifee.app.* working if you put it in there

[kperreau]

@kperreau I have no idea what you mean by 'proguardrules = true' though, that's not a directive I'm familiar with.

I'ts about android/app/build.gradle:

/**
 * Run Proguard to shrink the Java bytecode in release builds.
 */
def enableProguardInReleaseBuilds = true

I've worked with few groups that have as much of a testing focus as Invertase actually. I understand this is frustrating, I need this to work as well. But it is version '0.5.1' and alpha testing does have the connotation that users are testers. So here we are

Maybe, but it's not a specific case, i'ts an easy to reproduce use case, just enable ProguardInReleaseBuilds and check.

[mikehardy]

Maybe, but it's not a specific case, i'ts an easy to reproduce use case, just enable ProguardInReleaseBuilds and check.

Sure! Easy case to check. Here's the thing, you assert that they did not test it. Do you have facts for the assertion? It could be that they did test it. There is even the implication that they are a bit ridiculous for not testing it, still based on that assumption. But the fact is release mode was tested...I have been working with them today to try to troubleshoot this and other things. Apparently proguard is more subtle than that, and it just wasn't reproduced in their project on release builds for some sort of subtle-interaction reason.

My project might just have a simple "I didn't get the license correct" thing, I still haven't had time to dig in on it, I will later today but an adb logcat scan on a device with a release build running will clear that up for me. I will report back either way.

[mikehardy]

Alright! I actually had a license verification problem but it was a multi-bug - after fixing it with https://github.com/notifee/react-native-notifee/commit/d2e4d96fb826d7d2cd12ef297c8cc3dd8cfb7de5 your issue was present as well @kperreau

Your issue is (I think) fixed in https://github.com/notifee/react-native-notifee/commit/2709c1d58c59bb5620c7f697fc358e782b1594a3 and if you update to 0.6.1 version here you will likely have success with your release builds?

Note that in the diff from 0.5.1 to 0.6.1 the 'Importance' type has moved to 'AndroidImportance'. It was just a matter of renaming my usage of the type, the internals / semantics were the same. Other than that it should work for you

Let us know?

[kperreau]

Ok it seems to be working. Thank you.

Note that in the diff from 0.5.1 to 0.6.1 the 'Importance' type has moved to 'AndroidImportance'. It was just a matter of renaming my usage of the type, the internals / semantics were the same.

It would be nice to notice this kind of thing in the release note so that everyone can migrate without worries.
https://notifee.app/react-native/docs/release-notes

[mikehardy]

Of course, it was the wee hours in the morning when we fixed the issue though, need for sleep prevailed ;-)