Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android build: Address deprecation warning in react-native-device-info #4240

Closed
chrisbobbe opened this issue Aug 26, 2020 · 0 comments · Fixed by #4261
Closed

Android build: Address deprecation warning in react-native-device-info #4240

chrisbobbe opened this issue Aug 26, 2020 · 0 comments · Fixed by #4261
Assignees
Labels
a-Android dependencies Pull requests that update a dependency file

Comments

@chrisbobbe
Copy link
Contributor

I see the following warning on running ./gradlew help --warning-mode=all from android (recommended by this doc):

> Configure project :react-native-device-info
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

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-application do its job, as we did partially in 18c37ce. expo-device might be needed, too.

@chrisbobbe chrisbobbe added a-Android dependencies Pull requests that update a dependency file labels Aug 26, 2020
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 chrisbobbe self-assigned this Sep 16, 2020
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
Labels
a-Android dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant