Comments (13)
Hey @samdozor we did try a full clean/rebuild. Nuked node_modules, android/.idea, and android/.gradle, ran invalidate cache, clean, and build. I also just tried it on a completely fresh checkout, and it is still throwing.
We already have it pinned to 5.9.3 in our android/app/build.gradle, but that doesn't seem to make a difference. It was pinned with a compile
configuration, and I tried changing that to implementation
, but still no dice.
When I look at all the dependencies being compiled, I'm seeing both 5.9.3 and 5.10.2:
from react-native-mparticle.
Hey @jordanhaven you can add the following snippet in your app level build.gradle
file to pin the mparticle version to 5.9.3
configurations.all {
resolutionStrategy {
force 'com.mparticle:android-core:5.9.3'
}
}
Hope this helps!
from react-native-mparticle.
I literally just started experiencing this issue a few minutes ago. Great timing. That snippet resolved it for me. Thanks @willpassidomo!
from react-native-mparticle.
Nope :/
I've tried:
- Changing
implementation project(':react-native-mparticle')
to
implementation(project(':react-native-mparticle')) {
exclude group: "com.mparticle", module: "android-core"
}
- Setting
configurations.all.resolutionStrategy.force
as above - Changing our implementation from
implementation 'com.mparticle:android-core:5.9.3'
to
implementation('com.mparticle:android-core:5.9.3') {
force = true
}
- Upgrading this plugin to 2.3.3, but leaving everything else the way it was (no forces or excludes)
- Upgrading this plugin to 2.3.3 and making all of the above changes
In all cases, I get the same issue.
The only time I got a different error was when upgrading this plugin to 2.3.3 and changing our implementation 'com.mparticle:android-core:5.9.3'
to implementation 'com.mparticle:android-core:5.10.3'
, thinking, hey, if the core versions all match, it should be bueno, right? But then it wouldn't build and I got errors related to r8 (last relevant cause in stacktrace: Caused by: com.android.tools.r8.utils.AbortException: Error: Class content provided for type descriptor com.mparticle.internal.Q actually defines class com.mparticle.internal.q
). And it's the same error regardless of whether or not android.enableR8=true
is set in gradle.properties.
I've also done a lot of cache invalidation/restarts (both from the UI and from going nuclear and emptying out ~/.gradle/caches
).
from react-native-mparticle.
hey @jordanhaven - thanks for the report. We can definitely change this to a static dependency. That said:
- in the meantime - you should be able pin the
com.mparticle:android-core
dependency in your build.gradle and it'll override our plugin's version. - the referenced change shouldn't actually be a breaking change - maybe you need to do a total clean/rebuild? We made logEvent accept
BaseEvent
instead ofMPEvent
, butMPEvent
is a subclass ofBaseEvent
.
from react-native-mparticle.
@willpassidomo works perfectly, thanks!
from react-native-mparticle.
Actually, nevermind, it appeared to be working for me (I think because I had modified the mParticle build.gradle to be static to unblock myself and hadn't changed it back), but fresh builds are still failing :(
ETA: it seems like on an initial clean/rebuild, the dependencies look correct, but once we build and run on device, we see 5.10.3 show up.
Initial open in AS/gradle sync:
from react-native-mparticle.
hey @jordanhaven would mind rerunning this with our latest React release, 2.3.3
? We put out a fix yesterday for the underlying issue, so it should make the downgrade to 5.9.3 no longer necessary.
The issue we experienced recently had to do with recent versions of Gradle Build Tools (3.4+) starting using R8 by default in its build chain, which seems to cause issues similar to the ones you experienced when the dependency is compiled into a project which is not using R8.
The problem played itself out in the Android module of our React Native project which, until yesterday's release, was still using an old version of Gradle Build Tools. The latest version should resolve this issue
from react-native-mparticle.
@jordanhaven I'm sorry to hear that. What version of Gradle Build Tools do you have in your Android project?
if it is not the latest (3.5.1) I would highly recommend upgrading to that level, there seem a high number of issues related to R8 in earlier versions
from react-native-mparticle.
@jordanhaven @arcyn1c We just released version 5.11.0, which rolled back the Gradle Build Tool upgrades we previously made. This version will be pulled in automatically by the React SDK, so you will be able to go back to your original code (sans the fixes we went over here). I'm going to close this for now, but if any issues like this pop back up, please do open up a new issue! Thanks for the report!
from react-native-mparticle.
@willpassidomo we experienced this issue as well, and made a change our own gradle file to effectively roll forward the Android SDK to fix our builds:
dependencies {
implementation 'com.mparticle:android-core:5.10.2'
}
However this doesn't fix the underlying "problem" of something you reference in your last comment - the "auto upgrade" facility of the RN sdk. Correct me if I'm wrong but the range specifier in the gradle file of the RN package, of the Android SDK dependency, is "take latest" which means our builds are not deterministic. We'd prefer a fixed version so that our builds are deterministic and we can control SDK upgrades, whether they are the RN SDK's or the underlying native SDK's. Right now it still seems like any developer of the Android SDK can release a new (even major) version with a breaking change (like the baseEvent
one above) and it would get pulled into the next builds of anybody using the RN sdk and potentially break live apps.
from react-native-mparticle.
@markgibaud Hey Mark, thanks for reaching out!
The Android SDK dependency iscompileOnly
means it will only be used during Compile time. The version you specify in your application build.gradle
is the version that will be used at Runtime. The version you specify in your RN project, using implementation
is the version that will be used at Runtime. As long as the dependency in your RN project is locked, you will achieve deterministic builds.
https://developer.android.com/studio/build/dependencies#dependency_configurations
We agree that it is not perfect to even have an open-ended compileOnly
dependency, but we are extremely conscientious of maintaining API compatibility, so it is not likely to ever be an issue. We will update this behavior in the near future, but it doesn't rise to the level warranting a hotfix
Just to clarify, the issue originally cited in this issue was not a result of any API changes, rather an issue with the update of the Gradle Build Tools past version 3.4.1
, which caused multidexing problems in some dependent applications. Essentially, when the app was compiled, our SDK was split amongst different ".dex" files, and for some reason was not being mapped properly. We suspect that the solution would be resolved if clients also upgraded their Gradle Build Tool, but we decided to instead roll back the upgrade. The specific issue with that particular Gradle Build Tools version, 3.4.1
, was that in that version the new code shrinker "R8" was enabled by default and it was not playing nice with build chains still using Progaurd.
The rollback occurred in our Android SDK in version 5.11.0
, so using any version equal or greater than that should alleviate the multidexing issue
I hope you found this answer satisfactory, and please reach back out if you find my explanation lacking :)
from react-native-mparticle.
Hi @willpassidomo thanks for the quick reply and apologies for not getting back sooner.
I'm not an expert at gradle and how compileOnly and implementation at different levels interact, but it was definitely such that without updating any source on our side whatsoever, the new update of the mParticle Android SDK was pulled in at build time and because it contained that breaking change we couldn't release our Android app. We proved this multiple ways on different machines before figuring out that that was the problem (the problem was of course that although everything compiled correctly, at runtime the logEvent
called failed) Agree it's not worth a hotfix but going forward we'd definitely want to reach a stage where from any given commit we would be able to produce a deterministic build.
Anyway thanks for looking into it and we're satisfied it's unlikely to happen again before fixing the versions in the RN package 👍
from react-native-mparticle.
Related Issues (20)
- Can't build the app after upgrading mParticle-Apple-SDK to 8.13.0 HOT 3
- Unable install in expo HOT 16
- 'mParticle.h' file not found HOT 2
- [iOS] App won't build after upgrading to react-native 0.73 HOT 4
- Build Failure in React Native Due to Missing mParticle-Apple-SDK Header After Update HOT 1
- com.mparticle:android-core com.mparticle:android-core: compliance warning for Android HOT 2
- Compilation Error HOT 2
- Feature Request: Raise an event once at attribution is fetched at the native layers. HOT 4
- question: isLoggedIn flag. HOT 1
- Not able to find specification HOT 2
- Plugin uses deprecated part of the mParticle Android SDK
- Could not invoke MParticle.logEvent HOT 3
- After published 2.7.1 old versions have stopped being build HOT 12
- Question: Is autolinking supported? HOT 3
- Documentation needs more clarity around identification HOT 1
- Module uses old part of the mParticle Android SDK HOT 4
- mParticle -> Warning: Braze SDK initialized outside of mParticle kit
- Global Subscription States in Braze via mParticle React Native library
- Simulator not running on M1 MacBook? HOT 2
- Migrate to AndroidX HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-native-mparticle.