Remove Java.Interop.TypeNameMappings project, it is gone.

[atsushieno]

This fixes JavaNativeTypeManager.PackageNamingPolicy initialization issue
that blocks the entire use of package naming policy customization (one in
Xamarin.Android.Build.Tasks.dll is initialized in GenerateJavaStubs, while
the actual use in Java.Interop.Tools.JavaCallableWrappers.dll never gets
initialized).

Added test for PackageNamingPolicy.Lowercase. Deployed apps work fine too.

[atsushieno]

Do not merge this until we merge dotnet/java-interop#184 and bump Java.Interop reference.

[atsushieno]

build

[atsushieno]

The build failures on Jenkins is not reproducible on my environment (with make leeroy). There is no chance that my changes can result in the missing IMap interface that are reported there.

[jonpryor]

This feels like half the solution. Should we merge this and do the other half separately, or do both halves at the same time?

The missing half is in Mono.Android.dll, in JNIEnv.GetJniName(Type): If the monodroid_typemap_managed_to_java() codepath fails -- because typemap.mj doesn't contain an entry for the System.Type instance -- then we fallback to using JavaNativeTypeManager.ToJniName(Type). Logically, this should rely on the JavaNativeTypeManager.PackageNamingPolicy property value, but JNIEnv never sets that property.

This in turn means that JavaNativeTypeManager.PackageNamingPolicy will always be PackageNamingPolicy.LowercaseHash ("0") when running on device, which means we could generate the wrong names.

At least, that's the theory. In practice...how would monodroid_typemap_managed_to_java() fail? We'd have to "somehow" have a managed type + corresponding System.Type instance, for a bound type (e.g. not List<T>), and somehow not have this bound type contained within typemap.mj.

I'm not sure how to make that happen that wouldn't involve some form of System.Reflection.Emit/etc. and generating types at runtime. This could very well be a non-issue.

That said, let's call it a nagging concern in the back of my mind. It should probably be addressed.

Good way to test that setting JavaNativeTypeManager.PackageNamingPolicy within JNIEnv works: Update <GenerateJavaStubs/> so that it doesn't generate typemap.mj and typemap.jm. This will force execution of the Reflection-based JNI name generation path, and should quickly let you know if things are working as expected. :-)

[atsushieno]

That probably matches my observation that apps never failed for me, especially even that we have such a bogus code path for Mono.Android.dll https://github.com/xamarin/java.interop/blob/master/src/Java.Interop.Tools.TypeNameMappings/Java.Interop.Tools.TypeNameMappings/JavaNativeTypeManager.cs#L192 where lowercasing is not enough (what happens if it is given "Android.Views" ? It should look up [NamespaceMapping]s).

But my general doubt is that package naming doesn't actually matter for run-time lookup. If you think your concern is real, then that should be formed as a unit test. That's what Test First should mean.

[atsushieno]

Also note that this is being a blocking concern/issue for bringing Android support 26.1.0 support as Jon Dick reported that it depends on Android Architecture Components and MD5 hashing breaks AAC.