Closes#21920.
Weirdly enough this was semeingly fixed once before in ancient times in
3891f467a3, but then unfixed again in
566e09083f. The second change is no longer
needed since the toolbar became opaque in #9447.
With .NET 6, the way Xamarin package versioning works has changed.
- The `ApplicationVersion` MSBuild property aims to replace
`android:versionCode` in the manifest.
- The `ApplicationDisplayVersion` MSBuild property aims to replace
`android:versionName` in the manifest.
More about this can be read in Xamarin docs:
ec712da8c1/Documentation/guides/OneDotNetSingleProject.md
To this end:
- Manual `version{Code,Name}` specs are removed from
`AndroidManifest.xml`, as they were preventing MSBuild properties
from functioning properly.
- `Version` now defaults to 0.0.0, so that local builds don't appear
like they were deployed (see `OsuGameBase.IsDeployedBuild`).
- `ApplicationDisplayVersion` now defaults to `Version`.
This addresses the Android portion of #21498.
- `ApplicationVersion` can now be specified by command line,
but still needs to be supplied manually for version detection to
work correctly. See `OsuGameAndroid.AssemblyVersion` for more info.
Putting the pieces together, the complete publish command to deploy
a new build should look something like so:
dotnet publish -f net6.0-android \
-r android-arm64 \
-c Release \
-p:Version=2022.1228.0 \
-p:ApplicationVersion=202212280
This is more of a safety item. To avoid potential duplicate key in
dictionary errors (and also avoid being slightly memory-leaky), allow
`SoloStatisticsWatcher` consumers to dispose of the subscriptions they
take out.
If score submission fails, the score will not receive a correct online
ID from web, but will still be passed on to the solo statistics watcher
on the results screen. This could lead to the watcher subscribing to
changes with score ID equal to the default of -1. If this happened more
than once, that would cause a crash due to duplicate keys in the
`callbacks` dictionary.
Closes#21837.
- If the local user is restricted, then attempting to fetch their data
from the `/users` endpoint would result in an empty response.
- Even if the user was successfully fetched, their `RulesetsStatistics`
may not be populated (and instead be `null`). Curiously this was not
picked up by static analysis until the first issue was fixed.
Closes#21839.
This is a temporary change to target the new experimental/next deploy.
The main change that should result from this is having the user profile
show the pp^next values from the new domain.
