master build error

[dkvbabu]

HI,

I am facing below problem while running react-native run-android

Task :app:processDebugResources FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':app:processDebugResources'.

Android resource linking failed
/home/ubunto/.gradle/caches/transforms-1/files-1.1/drawee-1.10.0.aar/bfe2e3ba3748905ed6faebb6039cbe7e/res/values/values.xml:3:5-58:857: AAPT: error: resource android:attr/fontVariationSettings not found.

/home/ubunto/.gradle/caches/transforms-1/files-1.1/drawee-1.10.0.aar/bfe2e3ba3748905ed6faebb6039cbe7e/res/values/values.xml:3:5-58:857: AAPT: error: resource android:attr/ttcIndex not found.

error: failed linking references.

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

• Get more help at https://help.gradle.org

BUILD FAILED in 33s

Please look into this and reply.

Regards
dk venkatesh babu

[wsupajirakit]

I found the same problem.

[gnprice]

Hello! Thanks @dkvbabu for filing this.

I see the same thing on my own machine, and we're seeing it also in CI. The exact same commit that's in master now built just fine when I originally pushed it:
https://travis-ci.org/zulip/zulip-mobile/builds/546002328
so this seems to be a change somewhere in our dependencies. It's unfortunate that we seem to be exposed to a change uploaded by dependency's maintainer causing our own build to behave differently and fail.

I'm looking into fixing the immediate issue now.

[gnprice]

Update: this isn't totally trivial to fix, awkwardly.

The required step to fix it seems to be to bump compileSdkVersion to 28:
flutter/flutter#27226 (comment)
Apparently the cause is that some dependency (drawee, I guess) began to use, at compile time, a feature introduced in API 28.

And indeed, that resolves this error.

---

But then there's another error (and using cd android && ./gradlew :assembleDebug --continue to have the build plow past the first error, one can confirm that this error is already present on master, so it's not caused by the compileSdkVersion bump):

* What went wrong:
Execution failed for task ':app:mergeExtDexDebug'.
> com.android.build.api.transform.TransformException: java.lang.RuntimeException: java.lang.RuntimeException: com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives: 
  Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.
  Program type already present: android.support.v4.app.INotificationSideChannel

That, in turn, is helpfully explained here:
material-components/material-components-android#103
Apparently it's caused by some dependency upgrading from the Android Support Library to AndroidX while we're still on the Support Library (or alternatively vice versa.)

The Android folks have helpfully provided a feature in the Android build toolchain that will magically take care of this... for dependencies that come via Maven. They aren't designing for RN or for dependencies through NPM; and so when we have dependencies that we compile from source, they effectively assume that those dependencies are part of our codebase and we can just upgrade them ourselves.

Anyway, the feature they do provide is to put this into gradle.properties:

android.useAndroidX=true
android.enableJetifier=true

It magically converts references within Maven dependencies to the Android Support Library (android.support.annotation etc.) into references to AndroidX (androidx.annotation etc.).

If I apply that, the DexArchiveMergeException goes away...

---

...but then there's a new class of error. Four of our NPM-based dependencies, from the RN ecosystem, get compile errors. They look like this:

/home/greg/z/mobile/node_modules/rn-fetch-blob/android/src/main/java/com/RNFetchBlob/Response/RNFetchBlobFileResp.java:3: error: package android.support.annotation does not exist
import android.support.annotation.NonNull;
                                 ^
...
/home/greg/z/mobile/node_modules/rn-fetch-blob/android/src/main/java/com/RNFetchBlob/Response/RNFetchBlobFileResp.java:80: error: cannot find symbol
        public long read(@NonNull Buffer sink, long byteCount) throws IOException {
                          ^
  symbol:   class NonNull

They all seem to be failures to find various android.support libraries.

Still working on that one. It'd be straightforward to do with a small patch to each of these dependencies (and Android Studio is eager to make those changes for me, even)... but patching our dependencies isn't a normal thing in our build process, so actually doing that isn't straightforward.

Next thing I expect to try is upgrading those particular dependencies -- crossing fingers that each one of the four (a) has made a newer release that makes this switch, (b) has such a release that doesn't break something else for us due to whatever random other changes they've made.

[gnprice]

Next thing I expect to try is upgrading those particular dependencies -- crossing fingers that each one of the four (a) has made a newer release that makes this switch, (b) has such a release that doesn't break something else for us due to whatever random other changes they've made.

Welp, first one I look at, there's a PR for it just today: react-native-image-picker/react-native-image-picker#1102
So... that's hopeful! Looks likely 🤞 it'll land soon, and then perhaps a release. Though then there's still the risk the unrelated changes that release pulls in will break something else... and also I haven't yet looked at the other three. Hmm.

[gnprice]

Aha, located what looks like the key discussion of this upstream:
facebook/react-native#25293
That's from going back to the root-cause issue, as I mentioned above:

It's unfortunate that we seem to be exposed to a change uploaded by dependency's maintainer causing our own build to behave differently and fail.

Some good details in that thread. In particular, we've scrupulously written down actual concrete versions in our build.gradle for all our dependencies (except RN itself, whose version we control through npm.) And searching through build.gradle files in our dependencies:

$ find android/ node_modules/ -name build.gradle | xargs grep --color=auto -P '(?<!com.facebook.react:react-native:)\+'

I'm pleasantly surprised to find that all but one of them have been equally careful!

The one exception is react-native-device-info:

$ cat node_modules/react-native-device-info/android/build.gradle
// ...
def DEFAULT_GOOGLE_PLAY_SERVICES_VERSION    = "+"

// ...
dependencies {
    def googlePlayServicesVersion = project.hasProperty('googlePlayServicesVersion') ? project.googlePlayServicesVersion : DEFAULT_GOOGLE_PLAY_SERVICES_VERSION
// ...
    compile "com.google.android.gms:play-services-gcm:$googlePlayServicesVersion"
}

Happily the problem is fixed upstream there, as of yesterday:
react-native-device-info/react-native-device-info#693

So: I'm going to hold off on attempting the AndroidX stuff (people say RN isn't ready for it before 0.60 anyway), and also hold off on the compileSdkVersion bump (though that should be smooth, and I may try it right after getting things working), and just deal with the react-native-device-info issue.

[gnprice]

Oof, we're on react-native-device-info version 0.21.5; the release with that fix is 2.1.2. That's a lot of version bumps, and signals two separate rounds of breaking changes.

(v0.21.5 is only just over a year old! 2018-04-09.)

So I'll first try to work around in a limited way without an upgrade. Then can attempt an upgrade after our build is working again -- it'd be good to refresh our dependencies in general.

[gnprice]

Fixed! @dkvbabu @wsupajirakit please rebase and try again, and confirm that it's working for you too.

Some handy discussion at react-native-device-info/react-native-device-info#693 (comment) of how to diagnose the issue (with ./gradlew -q app:dependencies).

Also in the same comment, a workaround that's a bit of a bigger hammer than I ended up using. I did this, to activate the specific logic that the react-native-device-info library's build.gradle has to control the version:

+project(":react-native-device-info").beforeEvaluate {
+    ext.googlePlayServicesVersion = "16.1.0"
+}

The workaround suggested in that comment would, IIUC, simply force any dependency's wildcard reference to use a particular version:

configurations.all {
    resolutionStrategy.force 'com.google.android.gms:play-services-gcm:16.1.0'
}

[dkvbabu]

Thanks. It is fine now. Regards dk venkatesh babu

…

________________________________ From: Greg Price <notifications@github.com> Sent: Wednesday, June 19, 2019 5:28 AM To: zulip/zulip-mobile Cc: dkvbabu; Mention Subject: Re: [zulip/zulip-mobile] master build error (#3526) Fixed! @dkvbabu<https://github.com/dkvbabu> @wsupajirakit<https://github.com/wsupajirakit> please rebase and try again, and confirm that it's working for you too. Some handy discussion at react-native-device-info/react-native-device-info#693 (comment)<react-native-device-info/react-native-device-info#693 (comment)> of how to diagnose the issue (with ./gradlew -q app:dependencies). Also in the same comment, a workaround that's a bit of a bigger hammer than I ended up using. I did this, to activate the specific logic that the react-native-device-info library's build.gradle has to control the version: +project(":react-native-device-info").beforeEvaluate { + ext.googlePlayServicesVersion = "16.1.0" +} The workaround suggested in that comment would, IIUC, simply force any dependency's wildcard reference to use a particular version: configurations.all { resolutionStrategy.force 'com.google.android.gms:play-services-gcm:16.1.0' } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#3526?email_source=notifications&email_token=ACPPERVBVMNYRGAD54N2HHDP3FZBZA5CNFSM4HY5YCQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYAJIGY#issuecomment-503354395>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACPPERSXXK2S7GYQX7SHISTP3FZBZANCNFSM4HY5YCQQ>.