Android build: Address deprecation warning in react-native-device-info
#4240
Assignees
Labels
Comments
chrisbobbe
added
a-Android
dependencies
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 1, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 4, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 9, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 11, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to several commits, listed below. Probably best to do this before the main upgrade commit. The "Fixed issues" and the "Known issues" sections of the release notes (linked for each upgrade below) are particularly informative for the patch-version upgrades, where, otherwise, the release notes seem identical to those of the corresponding minor version. ----- v5.6 (facebook/react-native@be2a2529a) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6/release-notes.html Upgrade guide: https://docs.gradle.org/5.6/userguide/upgrading_version_5.html#changes_5.6 Before doing this upgrade, I ran `gradle help --scan` (actually, `./gradlew help --scan`) to check for deprecations that might turn into failures after the upgrade, as recommended by the upgrade guide. The report (https://scans.gradle.com/s/2pgdvrpgnpyms [2]) didn't have a "Deprecations" item in the left nav, as shown in the guide's screenshot, but it did show some deprecation warnings in the console. (A similar output was seen from the alternative command they suggest, `gradle help --warning-mode all`; I ran it with `./gradlew`.) We see this in the console for three of our dependencies: ``` WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'. It will be removed soon. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html ``` The three dependencies are (with our issues to upgrade/replace, two of them filed just now): - `react-native-photo-view` zulip#4217 - `react-native-text-input-reset` zulip#4239 - `react-native-device-info` zulip#4240 The upgrade guide lists a few new deprecations; we may get warnings after the upgrade if they apply to us, but I suspect they may be given in the "Deprecations" section mentioned above, which we don't have, for whatever reason. It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. Unfortunately, we did run into a known issue with 5.6 (gradle/gradle#10347) that halted progress verifying the upgrade. React Native saw it too; facebook/react-native#26227 was filed to upgrade to 5.6.1 in response. That was closed and superseded by facebook/react-native#26349 (landed in facebook/react-native@b1c954b1f), done here and discussed below. ----- v5.6.2 (facebook/react-native@b1c954b1f) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.1/release-notes.html https://docs.gradle.org/5.6.2/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.1/userguide/upgrading_version_5.html#changes_5.6.1 https://docs.gradle.org/5.6.2/userguide/upgrading_version_5.html#changes_5.6.2 The release notes and upgrade guides appear close to identical to those for v5.6. One thing we could and did do here, with gradle/gradle#10347 fixed, is proceed with verifying the v5.6 upgrade, together with the changes from v5.6 to v5.6.2. The build scan report at v5.6.2 (https://scans.gradle.com/s/peks3ratsf7ee) was very similar to the one we ran before the v5.6 upgrade; those three deprecation warnings didn't turn into errors. `tools/test --full android` succeeded right away. ----- v5.6.3 (facebook/react-native@ff6b2ff32) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.3/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.3/userguide/upgrading_version_5.html#changes_5.6.3 All near-identical to the previous docs. The build scan report at v5.6.3 (https://gradle.com/s/3holiaylf6jku) also looks very similar to those at past versions. At first, I got a build failure that I didn't get with the previous upgrades: ``` java.nio.file.NoSuchFileException: /Users/chrisbobbe/dev/zulip-mobile/android/app/build/intermediates/external_file_lib_dex_archives/debug/out at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) [...] ``` It went away after deleting `android/.gradle` and running `./gradlew clean` (from SO: https://stackoverflow.com/a/62025502). ----- v5.6.4 (facebook/react-native@928f4434b) ----- Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 The build scan report at v5.6.4 (https://gradle.com/s/2szkm2hvdrejy) also looks very similar to those at past versions. ----- v6.0.1 (facebook/react-native@701e66bde) ----- Release notes from Gradle upstream: https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 The upgrade guide lists many new deprecations, and we are newly seeing some deprecation warnings in the build scan (see below). It also lists several potential breaking changes, and I haven't understood them well enough to find if they apply to us. We hope to catch any that do in `tools/test android --full`. This time, the build scan report for v6.0.1 (https://scans.gradle.com/s/l7q26kntclub6) does have a "Deprecations" section. Its contents: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. I encountered a build failure ("No file known for: classes.dex") but was able to fix it by clearing `android.gradle` and running `./gradlew clean`. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 11, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [2], corresponding to the following commits: - facebook/react-native@be2a2529a - facebook/react-native@b1c954b1f - facebook/react-native@ff6b2ff32 - facebook/react-native@928f4434b - facebook/react-native@701e66bde Probably best to do this before the main upgrade commit. We treat this as an upgrade from 5.5.x to the latest 5.6.x (which is the latest 5.x), and then to 6.0.1 (the latest 6.0.x). [1] - facebook/react-native@be2a2529a also added some comments in gradle.properties, which we reproduce. - We ran into a couple of different build failures, so, add those to the troubleshooting doc with the cache-clearing commands that worked to resolve them (from SO [3]). Release notes from Gradle upstream: https://docs.gradle.org/5.6.4/release-notes.html https://docs.gradle.org/6.0.1/release-notes.html Upgrade guides: https://docs.gradle.org/5.6.4/userguide/upgrading_version_5.html#changes_5.6.4 https://docs.gradle.org/6.0.1/userguide/upgrading_version_5.html#changes_6.0.1 We didn't spot any deprecations or announced breaking changes as applying to us, though it's a bit hard to tell (in particular, we use plenty of Gradle code that isn't ours, so we wouldn't necessarily spot something). We hope we'd catch any by just trying the build, e.g., with `tools/test android --full`. The upgrade guides recommend a "build scan", which we did by running `./gradlew help --scan`. In particular, the upgrade guides ask that you find a "Deprecations" section in the left nav of a web page showing the result of the scan. The build scan report at v5.6.4 [4] doesn't have a "Deprecations" section. This might mean that the feature was missing at that version, or it might mean that it looked for deprecations expressed in a certain way [5] and didn't find any. The report at v6.0.1 [6] did have a "Deprecations" section, with the following two warnings: """ BuildListener#buildStarted(Gradle) has been deprecated. This is scheduled to be removed in Gradle 7.0. 32 usages The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. 19 usages """ Expanding the 32 usages in the first of these, all but one are in the `com.android.library` plugin; one is in the `android` plugin. Expanding the 19 usages in the second of these, they're all in the `org.gradle.maven` plugin. In the console output from the build-scan command at both versions (shown in the build scan reports) we see some deprecation warnings from the Android Gradle Plugin, rather than Gradle itself. They apply to three of our dependencies, and we have issues to replace those dependencies (two of the issues filed just now): - `react-native-photo-view`; see zulip#4217 - `react-native-text-input-reset`; see zulip#4239 - `react-native-device-info`; see zulip#4240 [1] See discussion around zulip#4244 (comment) for some nuances about this. [2] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [3] https://stackoverflow.com/a/62025502 [4] https://gradle.com/s/2szkm2hvdrejy. The build scan at this link will be "available indefinitely", according to https://scans.gradle.com/. [5] zulip#4244 (comment) [6] https://scans.gradle.com/s/l7q26kntclub6
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 18, 2020
This is such a big leap between versions that my approach is to just tear down the package and set it up again, all in the same commit. This actually went very smoothly, for a few reasons: - We use a very small part of its API, especially after 18c37ce. - At least in the part we use, the library's own Flow types seem to be up-to-date. (We could have switched entirely to `expo-device`, and we could still do that, except that Expo has abandoned Flow completely, in favor of TypeScript. React Native Community has much better Flow support, generally.) - Since the addition of this package, we started using CocoaPods (33f4b41) and autolinking (a9a9ac7), which make it much easier to manage dependencies that use native code. In this commit: - Look over past commits and the installation instructions for v0.21.5 of this package [1] to see what we need to tear down: - Remove workaround code from 44a7e07; the problem was solved in react-native-device-info/react-native-device-info@95887635, released in v2.1.2. - Keep mock of this library from 8300c9f; experimentally, it's still necessary. - (Nothing else stands out.) - Upgrade version range of react-native-device-info from ^0.21.5 to ^6.0.2. - Skip some manual setup instructions labeled "AndroidX Support" [2] that say to add things in the `ext` block in `android/build.gradle`. - One chunk of these instructions says it's meant for supporting `deviceId` (it probably means `getDeviceId`), with a menu of different choices for that based on what modern new features we want to use. Probably best to make that choice if and when we actually decide to use `getDeviceId`. - Another chunk is labeled "include as needed". It suggests `compileSdkVersion` and `targetSdkVersion` be at least 28, in order to use AndroidX; ours are already. There are a few things there I don't quite understand, but we've been doing fine with AndroidX since we started using it in e433197, and presumably "as needed" implies we would know (or soon find out) if we needed that stuff. - Adjust our runtime code, if necessary (it's not necessary): - The two methods we do use, `getSystemName` and `getSystemVersion`, are still documented [3] [4] with the same usage as before. The changelog [5] doesn't suggest anything about these two methods, except for a blip with `getSystemName` where it had been returning "unknown" near-universally for one or two release candidates of v3, before that was promptly fixed. Manual testing on one physical Android device and one physical iOS device suggests that the same strings are given by those methods before and after the upgrade. (Also, notably, no build failures or runtime errors were observed.) In that experiment, the exported constant in src/utils/userAgent.js was: Before: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" After: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" If, one day, we're surprised by some unexpected string being used, we can dig into the implementation difference between v0.21.5 and v6.0.2 of this library and see what changed. [1] https://github.com/react-native-community/react-native-device-info/tree/v0.21.5#installation [2] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#androidx-support [3] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemname [4] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemversion [5] https://github.com/react-native-community/react-native-device-info/blob/v6.0.2/CHANGELOG.md Fixes: zulip#4240
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 18, 2020
This is such a big leap between versions that my approach is to just tear down the package and set it up again, all in the same commit. This actually went very smoothly, for a few reasons: - We use a very small part of its API, especially after 18c37ce. - At least in the part we use, the library's own Flow types seem to be up-to-date. (We could have switched entirely to `expo-device`, and we could still do that, except that Expo has abandoned Flow completely, in favor of TypeScript. React Native Community has much better Flow support, generally.) - Since the addition of this package, we started using CocoaPods (33f4b41) and autolinking (a9a9ac7), which make it much easier to manage dependencies that use native code. In this commit: - Look over past commits and the installation instructions for v0.21.5 of this package [1] to see what we need to tear down: - Remove workaround code from 44a7e07; the problem was solved in react-native-device-info/react-native-device-info@95887635, released in v2.1.2. - Keep mock of this library from 8300c9f; experimentally, it's still necessary. - (Nothing else stands out.) - Upgrade version range of react-native-device-info from ^0.21.5 to ^6.0.2. - Skip some manual setup instructions labeled "AndroidX Support" [2] that say to add things in the `ext` block in `android/build.gradle`. - One chunk of these instructions says it's meant for supporting `deviceId` (it probably means `getDeviceId`), with a menu of different choices for that based on what modern new features we want to use. Probably best to make that choice if and when we actually decide to use `getDeviceId`. - Another chunk is labeled "include as needed". It suggests `compileSdkVersion` and `targetSdkVersion` be at least 28, in order to use AndroidX; ours are already. There are a few things there I don't quite understand, but we've been doing fine with AndroidX since we started using it in e433197, and presumably "as needed" implies we would know (or soon find out) if we needed that stuff. - Adjust our runtime code, if necessary (it's not necessary): - The two methods we do use, `getSystemName` and `getSystemVersion`, are still documented [3] [4] with the same usage as before. The changelog [5] doesn't suggest anything about these two methods, except for a blip with `getSystemName` where it had been returning "unknown" near-universally for one or two release candidates of v3, before that was promptly fixed. Manual testing on one physical Android device and one physical iOS device suggests that the same strings are given by those methods before and after the upgrade. (Also, notably, no build failures or runtime errors were observed.) In that experiment, the exported constant in src/utils/userAgent.js was: Before: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" After: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" If, one day, we're surprised by some unexpected string being used, we can dig into the implementation difference between v0.21.5 and v6.0.2 of this library and see what changed. [1] https://github.com/react-native-community/react-native-device-info/tree/v0.21.5#installation [2] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#androidx-support [3] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemname [4] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemversion [5] https://github.com/react-native-community/react-native-device-info/blob/v6.0.2/CHANGELOG.md Fixes: zulip#4240
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 19, 2020
This is such a big leap between versions that my approach is to just tear down the package and set it up again, all in the same commit. This actually went very smoothly, for a few reasons: - We use a very small part of its API, especially after 18c37ce. - At least in the part we use, the library's own Flow types seem to be up-to-date. (We could have switched entirely to `expo-device`, and we could still do that, except that Expo has abandoned Flow completely, in favor of TypeScript. React Native Community has much better Flow support, generally.) - Since the addition of this package, we started using CocoaPods (33f4b41) and autolinking (a9a9ac7), which make it much easier to manage dependencies that use native code. In this commit: - Look over past commits and the installation instructions for v0.21.5 of this package [1] to see what we need to tear down: - Remove workaround code from 44a7e07; the problem was solved in react-native-device-info/react-native-device-info@95887635, released in v2.1.2. - Keep mock of this library from 8300c9f; experimentally, it's still necessary. - (Nothing else stands out.) - Upgrade version range of react-native-device-info from ^0.21.5 to ^6.0.2. - Skip some manual setup instructions labeled "AndroidX Support" [2] that say to add things in the `ext` block in `android/build.gradle`. - One chunk of these instructions says it's meant for supporting `deviceId` (it probably means `getDeviceId`), with a menu of different choices for that based on what modern new features we want to use. Probably best to make that choice if and when we actually decide to use `getDeviceId`. - Another chunk is labeled "include as needed". It suggests `compileSdkVersion` and `targetSdkVersion` be at least 28, in order to use AndroidX; ours are already. There are a few things there I don't quite understand, but we've been doing fine with AndroidX since we started using it in e433197, and presumably "as needed" implies we would know (or soon find out) if we needed that stuff. - Adjust our runtime code, if necessary (it's not necessary): - The two methods we do use, `getSystemName` and `getSystemVersion`, are still documented [3] [4] with the same usage as before. The changelog [5] doesn't suggest anything about these two methods, except for a blip with `getSystemName` where it had been returning "unknown" near-universally for one or two release candidates of v3, before that was promptly fixed. Manual testing on one physical Android device and one physical iOS device suggests that the same strings are given by those methods before and after the upgrade. (Also, notably, no build failures or runtime errors were observed.) In that experiment, the exported constant in src/utils/userAgent.js was: Before: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" After: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" If, one day, we're surprised by some unexpected string being used, we can dig into the implementation difference between v0.21.5 and v6.0.2 of this library and see what changed. [1] https://github.com/react-native-community/react-native-device-info/tree/v0.21.5#installation [2] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#androidx-support [3] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemname [4] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemversion [5] https://github.com/react-native-community/react-native-device-info/blob/v6.0.2/CHANGELOG.md Fixes: zulip#4240
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 21, 2020
This is such a big leap between versions that my approach is to just tear down the package and set it up again, all in the same commit. This actually went very smoothly, for a few reasons: - We use a very small part of its API, especially after 18c37ce. - At least in the part we use, the library's own Flow types seem to be up-to-date. (We could have switched entirely to `expo-device`, and we could still do that, except that Expo has abandoned Flow completely, in favor of TypeScript. React Native Community has much better Flow support, generally.) - Since the addition of this package, we started using CocoaPods (33f4b41) and autolinking (a9a9ac7), which make it much easier to manage dependencies that use native code. In this commit: - Look over past commits and the installation instructions for v0.21.5 of this package [1] to see what we need to tear down: - Remove workaround code from 44a7e07; the problem was solved in react-native-device-info/react-native-device-info@95887635, released in v2.1.2. - Keep mock of this library from 8300c9f; experimentally, it's still necessary. - (Nothing else stands out.) - Upgrade version range of react-native-device-info from ^0.21.5 to ^6.0.2. - Skip some manual setup instructions labeled "AndroidX Support" [2] that say to add things in the `ext` block in `android/build.gradle`. - One chunk of these instructions says it's meant for supporting `deviceId` (it probably means `getDeviceId`), with a menu of different choices for that based on what modern new features we want to use. Probably best to make that choice if and when we actually decide to use `getDeviceId`. - Another chunk is labeled "include as needed". It suggests `compileSdkVersion` and `targetSdkVersion` be at least 28, in order to use AndroidX; ours are already. There are a few things there I don't quite understand, but we've been doing fine with AndroidX since we started using it in e433197, and presumably "as needed" implies we would know (or soon find out) if we needed that stuff. - Adjust our runtime code, if necessary (it's not necessary): - The two methods we do use, `getSystemName` and `getSystemVersion`, are still documented [3] [4] with the same usage as before. The changelog [5] doesn't suggest anything about these two methods, except for a blip with `getSystemName` where it had been returning "unknown" near-universally for one or two release candidates of v3, before that was promptly fixed. Manual testing on one physical Android device and one physical iOS device suggests that the same strings are given by those methods before and after the upgrade. (Also, notably, no build failures or runtime errors were observed.) In that experiment, the exported constant in src/utils/userAgent.js was: Before: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" After: - "ZulipMobile/27.154 (iOS 13.7)" - "ZulipMobile/27.154 (Android 9)" If, one day, we're surprised by some unexpected string being used, we can dig into the implementation difference between v0.21.5 and v6.0.2 of this library and see what changed. [1] https://github.com/react-native-community/react-native-device-info/tree/v0.21.5#installation [2] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#androidx-support [3] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemname [4] https://github.com/react-native-community/react-native-device-info/tree/v6.0.2#getsystemversion [5] https://github.com/react-native-community/react-native-device-info/blob/v6.0.2/CHANGELOG.md Fixes: zulip#4240
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I see the following warning on running
./gradlew help --warning-mode=allfromandroid(recommended by this doc):It looks like this package is still being maintained, by react-native-community: https://github.com/react-native-community/react-native-device-info#readme. So, we might be able to upgrade to a version that doesn't have this warning, following their upgrade guides and handling any breaking changes.
Another route we could take is to get rid of this dependency and consider having
expo-applicationdo its job, as we did partially in 18c37ce.expo-devicemight be needed, too.The text was updated successfully, but these errors were encountered: