[TrimmableTypeMap] Use Crc64 package naming by default with LowercaseCrc64 compatibility by Copilot · Pull Request #11193 · dotnet/android

Copilot · 2026-04-23T07:05:16Z

This updates trimmable type map generation to default to Crc64-based package naming for unregistered types, while preserving backwards compatibility for projects that explicitly set:

<AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy>

Package naming policy support in trimmable typemap
- Wired AndroidPackageNamingPolicy into trimmable typemap generation.
- Added policy-aware hashing:
  - Crc64 (trimmable default) → crc64... using System.IO.Hashing.Crc64
  - LowercaseCrc64 → crc64... using the existing legacy/custom CRC64 implementation for compatibility with previous naming
- Removed trimmable XxHash64 handling, as it no longer provides value for this path.
- Kept Mono.Android namespace-preserving behavior unchanged.
Default policy update
- Crc64 is now the default only for trimmable typemap generation.
- The global AndroidPackageNamingPolicy default remains LowercaseCrc64 for non-trimmable typemap paths.
Hashing implementation refactor
- Moved scanner hashing logic out of JavaPeerScanner into a dedicated static ScannerHashingHelper for easier focused testing.
- Added dedicated ScannerHashingHelper.ToCrc64() for System.IO.Hashing.Crc64.
- Updated UTF-8 buffer handling for the fast Crc64 path to use stackalloc with new byte[N] fallback for larger buffers (>256 bytes).
- Kept legacy CRC64 compatibility behavior intact.
Targeted test updates
- Updated scanner expectations for crc64 trimmable defaults.
- Added coverage to verify:
  - default Crc64 output,
  - legacy LowercaseCrc64 compatibility output.
- Removed XxHash64-specific scanner expectations.
- Kept fixed-vector tests for legacy CRC64 known input/output pairs to validate backward compatibility behavior.
- Converted Crc64 known-output validation into a [Theory] with multiple input/output vectors.
Related plumbing updates
- Passed package naming policy through the trimmable typemap target/task into TrimmableTypeMapGenerator and scanner hashing logic.

return packageNamingPolicy switch {
	HashedPackageNamingPolicy.LowercaseCrc64 => "crc64" + ScannerHashingHelper.ToLegacyCrc64 (ns, assemblyName),
	HashedPackageNamingPolicy.Crc64 => "crc64" + ScannerHashingHelper.ToCrc64 (ns, assemblyName),
	_ => throw new InvalidOperationException ($"Unsupported package naming policy: {packageNamingPolicy}"),
};

Agent-Logs-Url: https://github.com/dotnet/android/sessions/425dd1fe-e6a4-43e0-b0a9-de6b1e343c11 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

simonrozsival · 2026-04-23T09:25:13Z

@copilot I would prefer changing the prefix from crc64 to xx64 to reflect the change.

Agent-Logs-Url: https://github.com/dotnet/android/sessions/b04a9e6a-bf80-4ff1-8601-4078c145728e Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot · 2026-04-23T09:57:50Z

@copilot I would prefer changing the prefix from crc64 to xx64 to reflect the change.

Updated in 1049678: auto-generated TrimmableTypeMap package names now use the xx64 prefix (with XxHash64), and related unit/integration test expectations were updated accordingly.

jonathanpeppers

Note that there is the property:

<AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy>

We will probably want to introduce a new one for XxHash64.

It is a slight breaking change, because people could have a hardcoded package name in a script for launching their main activity, etc.

So, I think what we did in some really old Xamarin.Android release, we changed the default but allowed projects to still use the old one.

simonrozsival · 2026-04-23T15:03:09Z

It is a slight breaking change, because people could have a hardcoded package name in a script for launching their main activity, etc.

So funny thing is that the CSC64 we have in our C++(or C#?) code and CSC64 that is in System.IO.Hashing produce different results. I decided to use the System.IO.Hashing one in the trimmable typemap so that would be a breaking change anyway. I will need to revisit this and try to make the LowercaseCrc64 option be consistent with previous naming. The scenario with launching a specific Activity makes sense.

simonrozsival · 2026-04-23T15:04:44Z

@copilot let's respect <AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy> with a new (default) value of XxHash64. For backwards compatibility, let's use the custom Crc64 implementation that is in existing C# or C++ code used by the "llvm-ir" typemap

…efault Agent-Logs-Url: https://github.com/dotnet/android/sessions/a90e2abd-ca59-4b98-a498-64caa983b1d0 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot · 2026-04-23T15:41:11Z

@copilot let's respect <AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy> with a new (default) value of XxHash64. For backwards compatibility, let's use the custom Crc64 imple...

Implemented in ec92067: trimmable typemap now respects AndroidPackageNamingPolicy, defaults to XxHash64, and uses the legacy custom CRC64 path when policy is LowercaseCrc64 for backwards compatibility.

Note that there is the property:
<AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy>

...

Addressed in ec92067: added trimmable support for AndroidPackageNamingPolicy with a new default of XxHash64, while keeping LowercaseCrc64 compatibility via the existing legacy CRC64 implementation.

simonrozsival · 2026-04-24T07:41:28Z

+		var data = System.Text.Encoding.UTF8.GetBytes (value);
+		var hash = System.IO.Hashing.XxHash64.Hash (data);
+		return BitConverter.ToString (hash).Replace ("-", "").ToLowerInvariant ();


@copilot we should take inspiration from dotnet/android-tools#335 and avoid so many allocations here - use stackalloc where possible and non-allocating method overloads. Make sure to reuse the ToHexString method which is a lot more efficient than what we have right now. Also I don't think we need to hash UTF-8, we can simply do ReadOnlySpan<byte> utf16Bytes = MemoryMarshal.AsBytes(text.AsSpan()); , right? We hash a lot of strings during the build process, so let's make sure we don't unnecessarily slow down builds.

Implemented in 8d5709b: reduced allocations in JavaPeerScanner by switching to span-based hex formatting (with stackalloc), using non-allocating XxHash64.Hash(ReadOnlySpan<byte>, Span<byte>), and removing intermediate "{ns}:{assembly}" string allocations via pooled UTF-8 buffers. I kept UTF-8 input for hash compatibility with existing outputs/policies.

Agent-Logs-Url: https://github.com/dotnet/android/sessions/9fd6ed14-5c7b-463e-b1b0-ebefd496f067 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

simonrozsival

@copilot address these comments

I want to move the hashing code from JavaPeerScanner to a separate static ScannerHashingHelper class which can be better tested. I want a test that will just simply validate some known inputs to some known outputs of the legacy crc64 algorithm to prove we're maintaining backwards compatibility.

simonrozsival · 2026-04-24T09:41:22Z

 		<AndroidVersionCodePattern Condition=" '$(AndroidUseLegacyVersionCode)' != 'True' And '$(AndroidVersionCodePattern)' == '' ">{abi}{versionCode:D5}</AndroidVersionCodePattern>
 		<AndroidResourceGeneratorTargetName>UpdateGeneratedFiles</AndroidResourceGeneratorTargetName>
 		<AndroidUseApkSigner Condition=" '$(AndroidUseApkSigner)' == '' ">True</AndroidUseApkSigner>
-		<AndroidPackageNamingPolicy Condition=" '$(AndroidPackageNamingPolicy)' == '' ">LowercaseCrc64</AndroidPackageNamingPolicy>


the XxHash64 should be the default just for the trimmable typemap

Addressed in 05cebc7: reverted the global AndroidPackageNamingPolicy default and scoped XxHash64 as the default specifically for trimmable typemap generation.

Agent-Logs-Url: https://github.com/dotnet/android/sessions/144010de-77de-456e-aee5-4db9e9a1a5cb Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot · 2026-04-24T10:20:12Z

@copilot address these comments

I want to move the hashing code from JavaPeerScanner to a separate static ScannerHashingHelper class which can be better tested. I want a test that will just simply va...

Implemented in 05cebc7: moved scanner hashing into ScannerHashingHelper and added fixed-vector tests that validate known legacy CRC64 outputs to lock backward compatibility behavior.

@copilot let's respect <AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy> with a new (default) value of XxHash64. For backwards compatibility, let's use the custom Crc64 imple...

Handled in 05cebc7: trimmable typemap continues to respect explicit <AndroidPackageNamingPolicy>LowercaseCrc64</AndroidPackageNamingPolicy>, while using XxHash64 as the trimmable default and keeping the legacy custom CRC64 path for compatibility.

@copilot I would prefer changing the prefix from crc64 to xx64 to reflect the change.

xx64 is used for the new hash-based default path, while crc64 remains only for explicit LowercaseCrc64 compatibility. Confirmed in 05cebc7.

simonrozsival · 2026-04-27T08:03:40Z

@copilot update the PR by pulling latest main and resolve conflicts

…lgorithm-to-xxhash64 # Conflicts: # src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.TypeMap.Trimmable.targets Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot · 2026-04-27T08:35:52Z

@copilot update the PR by pulling latest main and resolve conflicts

Done in 3722fd9: pulled latest main, merged it into this branch, and resolved the conflict in Microsoft.Android.Sdk.TypeMap.Trimmable.targets.

simonrozsival · 2026-04-27T09:21:07Z

@copilot in dotnet/android-tools#338 we actually showed that System.IO.Hashing.Crc64 is faster than xxhash64. This PR will still be useful, but in a different way:

HashedPackageNamingPolicy.LowercaseCrc64 - the legacy Crc64 code for backwards compatibility
HashedPackageNamingPolicy.Crc64 - the much faster System.IO.Hashing.Crc64 implementation - new default for trimmable type map

…seCrc64 legacy Agent-Logs-Url: https://github.com/dotnet/android/sessions/fdb58e79-42f0-4d7d-8180-2b58c52ae3f8 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot · 2026-04-27T09:53:30Z

@copilot in dotnet/android-tools#338 we actually showed that System.IO.Hashing.Crc64 is faster than xxhash64. This PR will still be useful, but in a different way:

`Hash...

Done in e9ae72c. Trimmable default is now Crc64 (using System.IO.Hashing.Crc64), while LowercaseCrc64 remains the legacy custom CRC64 path for compatibility. I also kept explicit XxHash64 support and updated tests for all three policy behaviors.

simonrozsival · 2026-04-27T10:39:12Z

+	[Fact]
+	public void ToCrc64_KnownInput_HasStableOutput ()
+	{
+		Assert.Equal ("eb3df85c64aa1af6", ScannerHashingHelper.ToCrc64 ("MyApp", "TestFixtures"));
+	}


@copilot turn this into a Theory with multiple inputs + expected outputs values passed to it

Done in fa8493d. I converted this to a [Theory] with multiple input/output vectors for ToCrc64. No UI changes (screenshot N/A).

simonrozsival · 2026-04-27T10:39:52Z

 {
 	enum HashedPackageNamingPolicy {
+		Crc64,
 		XxHash64,


@copilot I think we should drop xxhash64, it doesn't bring any value after all. Let's keep the compat crc64 + the new "fast" crc64

Done in fa8493d. I removed the trimmable XxHash64 path and now keep only legacy LowercaseCrc64 + fast Crc64. No UI changes (screenshot N/A).

simonrozsival · 2026-04-27T10:42:05Z

+	internal static string ToCrc64 (string ns, string assemblyName)
+	{
+		int byteCount = GetNamespaceAssemblyUtf8ByteCount (ns, assemblyName);
+		byte[] rented = ArrayPool<byte>.Shared.Rent (byteCount);


@copilot we should stackalloc the buffer for utf-8 encoded name with a new byte[N] fallback for very long (and rare!) names (>256 chars) instead of renting the arrays

Done in fa8493d. ToCrc64 now uses stackalloc for UTF-8 buffers with new byte[N] fallback for larger values (>256 bytes). No UI changes (screenshot N/A).

…fers Agent-Logs-Url: https://github.com/dotnet/android/sessions/3701f7a2-7d92-4e63-8d34-f4723682c1ba Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Agent-Logs-Url: https://github.com/dotnet/android/sessions/3701f7a2-7d92-4e63-8d34-f4723682c1ba Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

jonathanpeppers · 2026-04-27T14:20:27Z

+		Span<byte> hash = stackalloc byte [8];
+		System.IO.Hashing.Crc64.Hash (utf8Buffer.Slice (0, bytesWritten), hash);
+		return ToHexString (hash, lowercase: true);


One problem is if you have "\0" and "\0\0\0\0" both with all zeros, then the crc value will be the same. Is that a problem here?

We XOR the length on this one:

dotnet/android-tools@9e9d063

jonathanpeppers · 2026-04-27T14:20:56Z

 			int slash = javaName.IndexOf ('/');
 			if (slash > 0) {
-				return "crc64.../" + javaName.Substring (slash + 1);
+				return "hash.../" + javaName.Substring (slash + 1);


We prefixed crc64 so the algorithm was clear. Should we pick something less generic than hash?

Initial plan

5e1adf6

Copilot AI assigned Copilot and simonrozsival Apr 23, 2026

Copilot started work on behalf of simonrozsival April 23, 2026 07:05 View session

Copilot AI linked an issue Apr 23, 2026 that may be closed by this pull request

[TrimmableTypeMap] Use xxhash64 instead of crc64 at build time #11192

Open

Copilot AI and others added 2 commits April 23, 2026 07:33

[TrimmableTypeMap] switch package hash generation to xxhash64

9d16443

Agent-Logs-Url: https://github.com/dotnet/android/sessions/425dd1fe-e6a4-43e0-b0a9-de6b1e343c11 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

[TrimmableTypeMap] clarify hashed package helper naming

174f08f

Agent-Logs-Url: https://github.com/dotnet/android/sessions/425dd1fe-e6a4-43e0-b0a9-de6b1e343c11 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Use xxhash64 instead of crc64 at build time~~ [TrimmableTypeMap] Use XxHash64 for auto-generated Java package hashing Apr 23, 2026

Copilot finished work on behalf of simonrozsival April 23, 2026 07:38

Copilot AI requested a review from simonrozsival April 23, 2026 07:38

Copilot started work on behalf of simonrozsival April 23, 2026 09:25 View session

[TrimmableTypeMap] switch generated package prefix to xx64

1049678

Agent-Logs-Url: https://github.com/dotnet/android/sessions/b04a9e6a-bf80-4ff1-8601-4078c145728e Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot finished work on behalf of simonrozsival April 23, 2026 09:59

jonathanpeppers reviewed Apr 23, 2026

View reviewed changes

Copilot started work on behalf of simonrozsival April 23, 2026 15:04 View session

[TrimmableTypeMap] support AndroidPackageNamingPolicy with XxHash64 d…

ec92067

…efault Agent-Logs-Url: https://github.com/dotnet/android/sessions/a90e2abd-ca59-4b98-a498-64caa983b1d0 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot AI changed the title ~~[TrimmableTypeMap] Use XxHash64 for auto-generated Java package hashing~~ [TrimmableTypeMap] Use XxHash64 package naming by default with LowercaseCrc64 compatibility Apr 23, 2026

Copilot finished work on behalf of simonrozsival April 23, 2026 15:42

simonrozsival reviewed Apr 24, 2026

View reviewed changes

Copilot started work on behalf of simonrozsival April 24, 2026 07:41 View session

[TrimmableTypeMap] reduce hashing allocations in JavaPeerScanner

8d5709b

Agent-Logs-Url: https://github.com/dotnet/android/sessions/9fd6ed14-5c7b-463e-b1b0-ebefd496f067 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot finished work on behalf of simonrozsival April 24, 2026 08:14

Copilot AI requested a review from simonrozsival April 24, 2026 08:14

simonrozsival reviewed Apr 24, 2026

View reviewed changes

Copilot started work on behalf of simonrozsival April 24, 2026 09:45 View session

[TrimmableTypeMap] extract scanner hashing helper and scope defaults

05cebc7

Agent-Logs-Url: https://github.com/dotnet/android/sessions/144010de-77de-456e-aee5-4db9e9a1a5cb Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot finished work on behalf of simonrozsival April 24, 2026 10:21

Copilot AI requested a review from simonrozsival April 24, 2026 10:21

Copilot started work on behalf of simonrozsival April 27, 2026 08:03 View session

Copilot finished work on behalf of simonrozsival April 27, 2026 08:37

Copilot started work on behalf of simonrozsival April 27, 2026 09:21 View session

[TrimmableTypeMap] default trimmable policy to Crc64 and keep Lowerca…

e9ae72c

…seCrc64 legacy Agent-Logs-Url: https://github.com/dotnet/android/sessions/fdb58e79-42f0-4d7d-8180-2b58c52ae3f8 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot AI changed the title ~~[TrimmableTypeMap] Use XxHash64 package naming by default with LowercaseCrc64 compatibility~~ [TrimmableTypeMap] Use Crc64 package naming by default with LowercaseCrc64 compatibility Apr 27, 2026

Copilot finished work on behalf of simonrozsival April 27, 2026 09:55

simonrozsival reviewed Apr 27, 2026

View reviewed changes

Copilot started work on behalf of simonrozsival April 27, 2026 10:42 View session

Copilot AI and others added 2 commits April 27, 2026 11:10

[TrimmableTypeMap] remove xxhash64 path and improve Crc64 hashing buf…

fa8493d

…fers Agent-Logs-Url: https://github.com/dotnet/android/sessions/3701f7a2-7d92-4e63-8d34-f4723682c1ba Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

[TrimmableTypeMap] clarify Crc64 switch and keep pooled legacy buffering

ab689ec

Agent-Logs-Url: https://github.com/dotnet/android/sessions/3701f7a2-7d92-4e63-8d34-f4723682c1ba Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>

Copilot finished work on behalf of simonrozsival April 27, 2026 11:16

Copilot AI requested a review from simonrozsival April 27, 2026 11:16

jonathanpeppers reviewed Apr 27, 2026

View reviewed changes

Conversation

Copilot AI commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

simonrozsival commented Apr 23, 2026

Uh oh!

Copilot AI commented Apr 23, 2026

Uh oh!

jonathanpeppers left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simonrozsival commented Apr 23, 2026

Uh oh!

simonrozsival commented Apr 23, 2026

Uh oh!

Copilot AI commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

simonrozsival Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

simonrozsival left a comment

Choose a reason for hiding this comment

Uh oh!

simonrozsival Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

simonrozsival commented Apr 27, 2026

Uh oh!

Copilot AI commented Apr 27, 2026

Uh oh!

simonrozsival commented Apr 27, 2026

Uh oh!

Copilot AI commented Apr 27, 2026

Uh oh!

simonrozsival Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

simonrozsival Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

simonrozsival Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

jonathanpeppers Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

jonathanpeppers Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Apr 23, 2026 •

edited

Loading

jonathanpeppers left a comment •

edited

Loading

Copilot AI commented Apr 23, 2026 •

edited

Loading

Copilot AI commented Apr 24, 2026 •

edited

Loading