…#7873)

Context: bec42ef
Context: 9752257
Context: …
Context: https://dl-ssl.google.com/android/repository/repository2-3.xml

Whenever Google updates their `repository2-3.xml`, there is a chance
that our `AndroidDependenciesTests.InstallAndroidDependenciesTest()`
unit test will fail, as `repository2-3.xml` containsn *only one*
platform-tools package version, and when that changes, out test breaks.

Tracking down the cause of this breakage is annoying, usually because
when this happens we've forgotten that platform-tools package version
changes are the primary reason `InstallAndroidDependencies()` fails. 😅

Update `AndroidDependenciesTests.InstallAndroidDependenciesTest()`
to set `$(AndroidSdkPlatformToolsVersion)`=34.0.1, fixing the test,
*and also* update the test so that when the wrong
`$(_AndroidSdkDirectory)` value is found, we read the *current version*
of the platform-tools package from `repository2-3.xml` and include
that information in our assertion message.

Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7102687&view=logs&j=270ba80a-9de5-5c73-abb9-bb787532a07c&s=25cdcba1-3ecb-5490-0002-daf27c697525&t=306f7057-edf0-58b5-5004-8b3b311950d4&l=449

`provisionator` is a source of random failures like:

	[21:41:23 ERR] Error Xamarin.Provisioning.ProvisioningException: Failed to provision C:\a\_work\1\s\xamarin-android\Xamarin.Android.Sdk-13.1.99.88.vsix

In this case, we were downloading a Classic Xamarin.Android build for
use on a test lane for `One .NET` tests?

Improve things, and skip this step completely for `One .NET` tests.
We don't need to provision Classic Xamarin.Android on these lanes.

This also has the added benefit of faster test runs, just
spot-checking the time spent on the above build:

  * Saves 1-2 min of time for `provisionator` on macOS lanes.
  * Saves up to ~24 min of time for `provisionator` on Windows lanes.

Our SSL test can fail quite often with a HTTP-429 Too Many Requests
error.  This makes the CI very unstable as we are constantly having
to wait and retry the tests.

Improve this by putting that logic into the test itself.  If we get
an HTTP-429 we should try some other SSL site.

Changes: dotnet/runtime@b68fd88...1e9466d
Changes: dotnet/emsdk@ba16583...3d7178d

Updates: Microsoft.NETCore.App.Ref: from 7.0.4 to 7.0.5

Other changes: feeds for dotnet/runtime 6.0.16

Co-authored-by: Jonathan Peppers <[email protected]>

Changes: dotnet/installer@aca89f1...ecacef4

Updates: Microsoft.Dotnet.Sdk.Internal: from 7.0.201-rtm.23116.12 to 7.0.203-servicing.23166.13

Co-authored-by: Jonathan Peppers <[email protected]>

Changes: dotnet/installer@ecacef4...332c2bc

Updates: Microsoft.Dotnet.Sdk.Internal: from 7.0.203-servicing.23166.13 to 7.0.203-servicing.23170.23

Changes: dotnet/runtime@1e9466d...43b5822
Changes: dotnet/emsdk@3d7178d...b0eec69

Updates:

* Microsoft.NETCore.App.Ref: from 7.0.5 to 7.0.6
* Microsoft.NET.Workload.Emscripten.*.Manifest-7.0.100: from 7.0.4 to 7.0.6

Other changes:

* Feeds for dotnet/runtime 6.0.17

Co-authored-by: Jonathan Peppers <[email protected]>

Changes: dotnet/installer@332c2bc...2c6d668

Updates: Microsoft.Dotnet.Sdk.Internal: from 7.0.203-servicing.23170.23 to 7.0.204-servicing.23214.3

Co-authored-by: Jonathan Peppers <[email protected]>

Fixes: #7939

Context: dotnet/runtime#13363
Context: https://www.unicode.org/charts/PDF/U2200.pdf (page 2)
Context: 5271f3e

The LLVM IR generator (5271f3e) outputs a number of integer values,
relying on the standard `int.ToString()` method to convert the value
to a string.  However, since .NET 6, this conversion is culture-
sensitive and in certain cultures (list below) it will output the
minus sign not as the "standard" ASCII \u002d character `-` but
instead as something else (see complete list below for details).

This breaks LLVM LLC:

	llc: environment.arm64-v8a.ll:554:7: error: expected value token
	  stderr |                 i32 −1, ; apk_fd

Fix the problem by using invariant culture when converting ***all***
integers and unknown objects to strings.  The reason all of them are
converted in this way is to avoid future changes to ICU and/or .NET
to-string conversion that might affect the resulting integer format.

Workaround: export `$LANG` to a locale that uses 0x2D `-` for
negation, e.g. `LANG=C`.

Locales/cultures affected by this issue are as follows:

  * ARABIC LETTER MARK + HYPHEN-MINUS `؜-` (\u061c \u002d): 26 cultures
    * ar
    * ar-001
    * ar-BH
    * ar-DJ
    * ar-EG
    * ar-ER
    * ar-IL
    * ar-IQ
    * ar-JO
    * ar-KM
    * ar-KW
    * ar-LB
    * ar-MR
    * ar-OM
    * ar-PS
    * ar-QA
    * ar-SA
    * ar-SD
    * ar-SO
    * ar-SS
    * ar-SY
    * ar-TD
    * ar-YE
    * sd
    * sd-Arab
    * sd-Arab-PK
  * LEFT-TO-RIGHT MARK + HYPHEN-MINUS `‎-` (\u200e \u002d): 10 cultures
    * ar-AE
    * ar-DZ
    * ar-EH
    * ar-LY
    * ar-MA
    * ar-TN
    * he
    * he-IL
    * ur
    * ur-PK
  * RIGHT-TO-LEFT MARK + HYPHEN-MINUS `‏-` (\u200f \u002d): 3 cultures
    * ckb
    * ckb-IQ
    * ckb-IR
  * MINUS SIGN `−` (\u2212): 38 cultures
    * et
    * et-EE
    * eu
    * eu-ES
    * fi
    * fi-FI
    * fo
    * fo-DK
    * fo-FO
    * gsw
    * gsw-CH
    * gsw-FR
    * gsw-LI
    * hr
    * hr-BA
    * hr-HR
    * ksh
    * ksh-DE
    * lt
    * lt-LT
    * nb
    * nb-NO
    * nb-SJ
    * nn
    * nn-NO
    * no
    * rm
    * rm-CH
    * se
    * se-FI
    * se-NO
    * se-SE
    * sl
    * sl-SI
    * sv
    * sv-AX
    * sv-FI
    * sv-SE
  * LEFT-TO-RIGHT MARK + MINUS SIGN `‎−` (\u200e \u2212): 3 cultures
    * fa
    * fa-AF
    * fa-IR
  * LEFT-TO-RIGHT MARK + HYPHEN-MINUS + LEFT-TO-RIGHT MARK `‎-‎` (\u200e \u002d \u002e): 16 cultures
    * ks
    * ks-Arab
    * ks-Arab-IN
    * lrc
    * lrc-IQ
    * lrc-IR
    * mzn
    * mzn-IR
    * pa-Arab
    * pa-Arab-PK
    * ps
    * ps-AF
    * ps-PK
    * ur-IN
    * uz-Arab
    * uz-Arab-AF

Update `BuildTest2.BuildBasicApplication()` to export
`LANG=sv_SE.UTF-8` as part of the `dotnet build` command to test this
scenario on macOS and Linux.  (This change is ignored on Windows.)

Fixes: #7953

Context: 11f0e1b

When a timezone changes in a `Release` config app, it can crash with:

	[monodroid] Unable to find Android.Runtime.AndroidEnvironment.NotifyTimeZoneChanged()!

In commit 11f0e1b, we removed the line:

	<?xml version="1.0" encoding="utf-8" ?>
	<linker>
	    <assembly fullname="Mono.Android">
	--      <type fullname="Android.Runtime.AndroidEnvironment" />

Unfortunately, `AndroidEnvironment.NotifyTimeZoneChanged()` is called
from non-managed code, via:

  * The `NotifyTimeZoneChanges` broadcast receiver
    (in `src/java-runtime/java/mono/android/app/NotifyTimeZoneChanges.java`)
    which calls-
  * The `Rutime.notifyTimeZoneChanged()` `native` method
    (in `src/java-runtime/java/mono/android/Runtime.java`),
    implemented in-
  * `Java_mono_android_Runtime_notifyTimeZoneChanged()`
    (in`src/monodroid/jni/timezones.cc`).

The managed linker cannot "see" any of these references, so we
need to *always* preserve this method, as it is always callable.

Update `src/Microsoft.Android.Sdk.ILLink/PreserveLists/Mono.Android.xml`
so that `Android.Runtime.AndroidEnvironment.NotifyTimeZoneChanged()`
is always preserved.

Added a test for this scenario.

TODO: we may want to audit all `mono_class_get_method_from_name()`
calls and add more tests cases.

I also cleaned up the tests a bit with a `getResource()` local function.