* [Mono.Android] update API description with the latest class-parse output.
It seems to add java.util.Hashmap#put() override, which does not affect
the public API.
* [Mono.Android] add API Level 25 description.
Since there is no documentation component yet, it is actually generated
with API Level 24 docs, so it lacks parameter names for newly added
abstract methods that class-parse cannnot extract. But there is only one
method that falls to the issue.
* [msbuild] add new droiddoc related arguments in ClassParse task.
Note that this task is not functional enough to support javadocs correctly
as it does not distinguish doclet type while it pretends to be able to.
- removed unused methods
- process only System assembly, because we are looking just for
Mono.Net.Security.MonoTlsProviderFactory.CreateDefaultProviderImpl
method
Commit 25663510 overlooked adding the `TileState` enum type to the
`Mono.Android.dll` build, meaning that the
`Android.Service.Quicksettings.TileState` type wasn't present in the
resulting assembly.
Add the `Android.Service.Quicksettings.TileState` enum to the build.
We had ProguardToolPath and it could be used for custom proguard tools,
which should be useful if we want to support Java8 based libraries which
doesn't work with the one in Android SDK. In theory.
In fact, it was not sufficient because proguard is also used by multidex.
To support multidex, we have to generate correct mainDexClasses rules
that should depend on Android SDK path, not proguard.
To support custom proguard, we need PROGUARD_HOME environment variable
in mainDexClasses(.bat). That actually uncovered another issue we had:
we were using ToolTask.EnvironmentOverride which is [Obsolete] and
converts every entry to lowercase, which can work on Windows but not
elsewhere i.e. even if we had PROGUARD_HOME, it became proguard_home(!)
Therefore we use ToolTask.EnvironmentVariables instead from now on.
Due to xbuild property parser issue, it differentiates MSBuild on
Windows and xbuild elsewhere to give some additional env. variables.
There were non-breaking API definition files changes caused by
https://github.com/xamarin/java.interop/pull/94
This update reflects the changes.
Additionally, the pre-API-24 API descriptions were generated by
`jar2xml`, not `class-parse`, which generated extraneous
generic constraints. Update all API descriptions to be generated by
`class-parse` and `api-xml-adjuster`.
With Android 7.0 (Nougat) it is no longer possible to read some
information about network interfaces from the /sys filesystem. Google
placed restrictions on two files used by the Mono BCL to read
information about the interface:
/sys/class/net/[DEVICE]/flags
/sys/class/net/[DEVICE]/operstate
The information we used to read from `flags` let us determine whether
the interface supports multicast and the `operstate` file provided us
with detailed information on the current device state.
Additionally, it is now impossible to read the hardware MAC address used
by any interface. This bit of information is also unavailable when using
the Java APIs and therefore applications running on devices with API
24 (and possibly newer) will not be able to access this information.
More details about the issue are available from the upstream Android
bug:
https://code.google.com/p/android/issues/detail?id=205565
In order to obtain the required information, we now need to use the Java
APIs on devices with API 24+ and this commit implements the backend to
retrieve this information. It is done in C in order to avoid overhead of
creating mirror .NET objects when calling Java, thus saving time and
memory during an operation which may be performed by some applications
quite frequently.
Part of fix for https://bugzilla.xamarin.com/show_bug.cgi?id=44296
The Bridgeless SCC support (commit 70807523) requires the
`mono.android.GCUserPeer` type to work, which is a type located within
`classes.dex`.
On the main/UI/startup thread, `JNIEnv::FindClass()` uses a
`ClassLoader` that will find types located within `classes.dex`. Other
threads do *not*. Other threads...such as mono's GC thread.
Unfortunately, this means that the `JNIEnv::FindClass()` use within
`gc_prepare_for_java_collection()` -- called from the mono GC thread
-- would always return `NULL`, with a pending exception, which would
cause the process to exit with an untimely death:
F/art : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION:
JNI GetMethodID called with pending exception java.lang.ClassNotFoundException:
Didn't find class "mono.android.GCUserPeer" on path: DexPathList[[directory "."],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
Move the `JNIEnv::FindClass()` lookup for `mono.android.GCUserPeer`
into `JNI_OnLoad()`, which *is* invoked on the UI thread, and thus
*can* find the `mono.android.GCUserPeer` type. This avoids the error.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44528
Something changed between C6 and the current master of xbuild or mono.
Before adding a reference like so
<Reference Include="Foo.dll" />
used to work without any issues. Now we get the following
Error executing task ResolveAssemblyReference: Path is empty
This is because xbuild seems to interogate the path from the reference
and it gets an empty string. But apprarently this is a problem.
This commit adds a call to Path.GetFullPath when resolving the assemblies
to work around this problem.
* Bump Mono to mono-4.8.0-branch commit 90699022b6fed7fd273ba3379a2e3696bbd8956f.
* Add new PreserveTlsProvider step, which rewrites MonoTlsProviderFactory.CreateDefaultProviderImpl()
to only include the selected TLS Provider.
* Added 'TlsProviderType' to <LinkAssemblies>.
Context https://bugzilla.xamarin.com/show_bug.cgi?id=39910
Under certain circumstances users can end up in a situation
where the Resource.Designer.xx file being generated will NOT
compile. This is normally down to a miss match between Nuget
packages like Xamarin.Forms and Android.Support libraries. It
is possible to have incpmpatible versions of Xamarin.Forms
(or other third party library like ZXing) which contain references
in the Resource.Designer.xx which DO NOT exist in the main application.
As a result when the code generator emits the code to set the field values
like
global::ZXing.Mobile.Resource.Id.contentFrame = global::Bug39910Repro.Droid.Resource.Id.contentFrame;
you can get into a situation where "contentFrame" does NOT exist in
the app (in this case Bug39910Repro) Id class. This results in a
compilation error CS0117.
This commit makes sure the compilation error is removed by checking
that the target type exists before emitting the code. If the type does
NOT exist we will emit a Warning XA0106 which will inform the user
they might have a problem with the Nuget versions.
While this might not be ideal as it may result in runtime issues. It
seems to be preferable to compilation errors that stop a user completely.
Possible runtime issues might be errors in the android app because certain
resource id's do not exist or refer to different resources.
`Mono.Android.dll` is [supposed to contain][0] an
[`AssemblyInformationalVersionAttribute`][1] `assembly:`-level
attribute which contains the version number, git commit, and various
other bits of information related to which commit `Mono.Android.dll`
"came from."
var attrs = (System.Reflection.AssemblyInformationalVersionAttribute[])
typeof (Java.Lang.Object)
.Assembly
.GetCustomAttributes(typeof(System.Reflection.AssemblyInformationalVersionAttribute), inherit: true);
string version = attrs [0].InformationalVersion;
// version is like "7.0.99.113; git-rev-head:d02845e; git-branch:master"
Unfortunately, in the open-source migration this was lost, and the
above code would throw an `IndexOutOfRangeException`, as
`attrs.Length` would be 0. (Xamarin.Android 7.0 likewise doesn't
contain the `AssemblyInformationalVersionAttribute`. Oops!)
Add `<GitBlame/>`, `<GitCommitsInRange/>`, and
`<ReplaceFileContents/>` tasks, along with various bits of MSBuild-fu,
to use `src/Mono.Android/Properties/AssemblyInfo.cs.in` as a
"template" for the `AssemblyInfo.cs` to include in the
`Mono.Android.dll` build, so that an appropriate
`AssemblyInformationalVersionAttribute` value is present.
[0]: https://developer.xamarin.com/releases/android/xamarin.android_4/xamarin.android_4.14/#Xamarin.Android_4.14.0
[1]: https://msdn.microsoft.com/en-us/library/system.reflection.assemblyinformationalversionattribute(v=vs.110).aspx
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=43287
Most of the ProcessStartInfo instances did NOT include
CreateNoWindow=true
WindowStyle=ProcessWindowStyle.Hidden
As a result on windows at least developers would see a
DOS prompt pop up during the build process. This is very
distracting. This commit fixes up the various uses to include
the new properties
api-24.xml.in was already generated with the almost latest tools,
but it has some new members probably due to android.jar updates.
Others were generated by old tools so they had extraneous generic
constraints.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=45018
The MSBuild Tasks setting the AndroidLogger event handlers were
not cleaning them up afterwards. This is not a problem on the
Command Line or in VS since the build Tasks are disposed of
once the build is complete. Or at least is appears to do so
in VS.
However in XS the entire build structure thing is kept in
memory. This appears to suggest that the event handers are
not removed and are constantly being set. Which in turn would
probably produce a memory leak.
This commit reworks the two Tasks which use these event handlers to
remove them after the task has completed.
We want to be able to add just callback to the AndroidLogger, not just
hardcode it to only take an MSBuild TaskLogger. This commit adds a new
method which takes MessageHandler's for each of the event handlers
available on the AndroidLogger. This will allow us to just provide
Lambda expressions for the events.
It appears that sometimes calling .ResponseCode on an instance
of the Java class HttpURLConnection will trigger network activity
and if the AndroidHttpCliendHandler was invoked on the main thread,
the activity will take place there as well and that causes Android
to throw the NetworkOnMainThreadException.
Wrap the offending code in a task to avoid the exception.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44961
- this should make $(AndroidHttpClientHandlerType) survive linking
- it is used by settting msbuild property
AndroidHttpClientHandlerType to the http client handler type name
(could be assembly qualified). the linker then doesn't strip
related parts. if everything work as it should then you will not
see this in the adb logcat:
I mono-stdout: Xamarin.Android returned no custom HttpClientHandler. Defaulting to System.Net.Http.HttpClientHandler
- also see
https://developer.xamarin.com/releases/android/xamarin.android_6/xamarin.android_6.1/#Native_HttpClientHandler
* Tasks/BuildApk.cs: Add 'TlsProvider' parameter.
* Xamarin.Android.Common.targets: Add <AndroidTlsProvider> property
and pass it to BuildApk.
Add this to your .csproj file to select the TLS Provider. Valid
values are "legacy" and "btls".
We now add a new 'XA_TLS_PROVIDER' environment variable to the .apk,
which is read by System/Mono.Net.Security/MonoTlsProviderFactory.Droid.cs
to select the TLS Provider.
Linker support (to eliminate the unused provider, similar to how it's
already done in xamarin-macios) is coming shortly.
- so that following tasks will not run into stream sharing
(violation) issues as in #44529
- bump Java.Interop to get:
commit 40b75e9c4b7b986f3bb31254a4aab3d60e0ef74e
Author: Radek Doulik <radekdoulik@users.noreply.github.com>
Date: Wed Sep 28 21:25:26 2016 +0200
[Java.Interop.Tools.JavaCallableWrappers] Add TypeNameMapGenerator.Dispose() (#91)
* [libmonodroid] Add support for waiting for a native debugger to attach.
When the `debug.mono.gdb` property is set to `wait:<timestam>`,
libmonodroid will wait in a loop for the native debugger to attach.
The debugger can set the `monodroid_gdb_wait` C variable to `0`
to break the wait after attaching.
This is useful to support use cases where the debugger attaches to
the process after it starts instead of the debugger being started by
libmonodroid.
The startup sequence should be:
1. Set system properties:
$ adb shell setprop debug.mono.gdb wait:`date +%s`
2. Launch the app:
$ adb shell am startup ...
3. Start the debugger
4. Attach to the process
5. Clear the `monodroid_gdb_wait` variable:
(gdb) p monodroid_gdb_wait=0
Context https://bugzilla.xamarin.com/show_bug.cgi?id=44633
Enabling <AndroidUseSharedRuntime> in some projects causes
`classes.dex` to not deploy to device.
For some bizzare reason when running a build vs XS the
AfterTargets are NOT being called for _CompileDex. As a
result the targets that need to be called to support
debugging are not being run.
This commit adds a bunch of new property extension points
which will allow the debugging targets to inject the
additonal target requirements directly rather than relying
on Before/After targets.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=44391
`java.util.concurrent.atomic.AtomicInteger.getAndDecrement()` is
bound as the `AtomicInteger.AndDecrement` property, which is "weird".
Similarly, `AtomicLong.getAndDecrement()` is bound as the
`AtomicLong.AndDecrement` property.
Fix the `AtomicInteger` and `AtomicLong` types so that the
`AndDecrement` and `AndIncrement` properties are `[Obsolete]`,
with "proper" method bindings of `GetAndDecrement()` and
`GetAndIncrement()`.
Additionally, `metadata` had wrong relative path specification
which broke our internal "monodroid" build, so correct them.
[Xamarin.Android.Build.Tasks] StripEmbeddedLibraries and ReadWrite
Fixes part of: https://bugzilla.xamarin.com/show_bug.cgi?id=44529
When running the `<StripEmbeddedLibraries/>` task, an `IOException`
may be thrown:
Error executing task StripEmbeddedLibraries: System.IO.IOException: Sharing violation on path .../obj/Release/linksrc/Xamarin.Android.NUnitLite.dll
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0025f] in <253a3790b2c44512bbca8669ecfc1822>:0
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <253a3790b2c44512bbca8669ecfc1822>:0
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at Mono.Cecil.ModuleDefinition.GetFileStream (System.String fileName, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00007] in :0
at Mono.Cecil.ModuleDefinition.Write (System.String fileName, Mono.Cecil.WriterParameters parameters) [0x00007] in :0
at Mono.Cecil.AssemblyDefinition.Write (System.String fileName, Mono.Cecil.WriterParameters parameters) [0x00001] in :0
at Xamarin.Android.Tasks.StripEmbeddedLibraries.Execute () [0x0034a] in <3d5202a5d4874a76a99388021bf1ab1a>:0
This was caused as part of commit 1d658252, which bumped us to
Cecil 0.10.0-beta1-v2, in which `AssemblyDefinition` now holds a
`Stream` to the file that was opened, instead of being a purely
in-memory construct, which was the case in Cecil 0.9.x.
Because `AssemblyDefinition` held a `Stream` to the source assembly,
calling `AssemblyDefinition.Write(string, WeriterParameters)` would
attempt to *re-open* the file for writing, which resulteed in the
above `IOException`.
Fix this by telling `DirectoryAssemblyResolver` to open all
assemblies as read/write and using the
`AssemblyDefinition.Write(WriterParameters)` overload, so that
`AssemblyDefinition` re-uses the existing `Stream` to write the file.
[The Jenkins build isn't using the bundle file][0]:
Target _BuildUnlessCached needs to be built as output file '../../bin/Debug//lib/xbuild-frameworks/MonoAndroid/v1.0/Mono.Cairo.dll' does not exist.
Another day, another "How did that ever work?!"
In particular, `Mono.Cairo.dll` was *never* built for the
Xamarin.Android profile, so *seriously*, how did the mono bundle,
"fixed" in 10b1c2a4, *actually work*?
Not only is `Mono.Cairo.dll` not built for the "monodroid" profile,
`SMDiagnostics.dll` is no longer built for MOBILE configurations
either.
Remove `Mono.Cairo.dll` and `SMDiagnostics.dll` from
`@(MonoProfileAssembly)`, which should allow the bundle to be used.
Xamarin Studio doesn't like `build-tools/libzip/libzip.mdproj`: it
refuses to load the project, stating:
> Invalid configuration mapping
This isn't a particularly helpful error. The *actual* issue is that
Xamarin Studio requires that an MSBuild project have
`<PropertyGroup/>`s with `Condition` attributes which correspond to a
"known" configuration. *It doesn't matter* that, in the case of
`libzip.mdproj`, *all* configurations use the same `$(OutputPath)`
property value, we still need separate Debug and Release configuration
sections in order to appease the Xamarin Studio masters.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/101/consoleText
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=44529
Commit 1d658252 bumped to Cecil 0.10.0-beta1-v2 and
Java.Interop/a1d3ecc8, which likewise uses Cecil 0.10.0-beta1-v2.
Among the various API changes in Cecil 0.10.x vs. Cecil 0.9.x is a
change to `Mono.Cecil.IAssemblyResolver`, implemented by
`Java.Interop.Tools.Cecil.DirectoryAssemblyResolver`, to implement the
`IDisposable` interface.
Java.Interop/a1d3ecc8 added a `DirectoryAssemblyResolver.Dispose()`
method, but this method didn't *do* anything.
Cecil 0.10.0-beta1-v2 also has a *semantic* change vs. Cecil 0.9.x:
`AssemblyDefinition` is no longer a "purely in-memory" construct.
Instead, it holds a `System.IO.Stream` to the assembly it's reading
(unless `Mono.Cecil.ReaderParameters.InMemory` is `true`).
This semantic change means that an assembly can't be read from and
written to at the same time via different mechanisms, so long as there
is an `AssemblyDefinition` instance to that file.
Which brings us to (private) Bug #44529, in which an `IOException` is
thrown from the `<StripEmbeddedLibraries/>` task:
Error executing task StripEmbeddedLibraries: System.IO.IOException: Sharing violation on path .../obj/Release/linksrc/Xamarin.Android.NUnitLite.dll
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0025f] in <253a3790b2c44512bbca8669ecfc1822>:0
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <253a3790b2c44512bbca8669ecfc1822>:0
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at Mono.Cecil.ModuleDefinition.GetFileStream (System.String fileName, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00007] in :0
at Mono.Cecil.ModuleDefinition.Write (System.String fileName, Mono.Cecil.WriterParameters parameters) [0x00007] in :0
at Mono.Cecil.AssemblyDefinition.Write (System.String fileName, Mono.Cecil.WriterParameters parameters) [0x00001] in :0
at Xamarin.Android.Tasks.StripEmbeddedLibraries.Execute () [0x0034a] in <3d5202a5d4874a76a99388021bf1ab1a>:0
The underlying cause of the `IOException` is twofold:
1. `AssemblyDefinition` instances now hold a `FileStream` to the file
they're reading from (and optionally writing to), and this
`FileStream` will be kept open until
`AssemblyDefinition.Dispose()` is called.
2. Nothing in `Xamarin.Android.Build.Tasks` calls
`AssemblyDefinition.Dispose()`.
Nor should anything in `Xamarin.Android.Build.Tasks` call
`AssemblyDefinition.Dispose()`! (Almost) All `AssemblyDefinition`
instances are *cached* within `DirectoryAssemblyResolver` instances,
and nothing calls `DirectoryAssemblyResolver.Dispose()` either!
(Not that this matters *too* much, becuase
`DirectoryAssemblyResolver.Dispose()` is currently a no-op.)
There is no sane reasoning here: so long as we're using
`DirectoryAssemblyResolver`, we're going to have more files open
(compared to when Cecil 0.9.x was used), which can result in file
sharing problems and the above `IOException`.
The way foward is:
1. `Java.Interop.Tools.Cecil.DirectoryAssemblyResolver` needs to be
updated so that
[`DirectoryAssemblyResolver.Dispose()` is useful][0], i.e. that it
will `Dispose()` of all held `AssemblyDefinition` instances.
2. Bump to Java.Interop/084e9f7f to pick up (1).
3. `Xamarin.Android.Build.Tasks.dll` needs to be updated so that
`DirectoryAssemblyResolver.Dispose()` is used.
4. All code, in particular `Xamarin.Andorid.Build.Tasks.dll`, needs to
be reviewed to ensure it doesn't do anything "stupid" with
`AssemblyDefinition` instances and/or `DirectoryAssemblyResolver.`
Examples of "stupid" things include:
* `Dispose()`ing of the return value from
`DirectoryAssemblyResolver.Load()`:
resolver.Load (assemblyName).Dispose();
* Treating `AssemblyDefinition` instances in a manner inconsistent
with how `DirectoryAssemblyResolver` loads them.
`DirectoryAssemblyResolver` will be getting a new constructor
overload which takes an `Mono.Cecil.ReaderParameters` parameter;
the default will be the default Cecil behavior, which is for
read-only behavior. Thus, trying to use the `AssemblyDefinition`
in a "write" context will fail:
var r = new DirectoryAssemblyResolver (...);
var a = r.Load (assemblyName);
a.Write (); // BOOM
[0]: https://github.com/xamarin/java.interop/pull/88
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44447
"Xamarin.Android uses AndroidManagedSymbols to control whether an mSYM
is
produced. Since it's disabled by default, it needs a property in the
project file to enable it, so affects templates too.
This does not match the final spec, which uses a MonoSymbolArchive
property instead. MonoSymbolArchive should default to true for
symbolicatable, releaseable builds - i.e. when there are debug symbols
and the shared runtime is not in use.
Basically, users shouldn't have to ever see MonoSymbolArchive in their
csproj, it only exists in case users need to disable it. This also means
that existing projects will get symbols."
This commit changes the AndroidManagedSymbols over to use the
newer MonoSymbolArchive naming. It also adds logic to detect when this
should be enabled. Namely when
MonoSymbolArchive is blank
AndroidUseSharedRuntime is False
EmbedAssembliesIntoApk is True
DebugSymbols is True
DebugType is PdbOnly
We still fallback to setting MonoSymbolArchive to False if
we still do not have a value after evaluating all of those
properties.
Change triggered by https://bugzilla.xamarin.com/show_bug.cgi?id=44448
It's possible for the register call to be called on a thread that hasn't been registered with Mono
yet. As such, the `mono_domain_get` call will return NULL until `mono_jit_thread_attach` is invoked where
domain information for the current thread becomes correct.
This is an issue because it means we invoke `monodroid_runtime_invoke` passing NULL as a bogus domain
argument. This caused a crash with `mono_domain_set` as it doesn't support being passed a NULL domain.
This commit solves the problem by re-requesting the current domain after the `mono_jit_thread_attach`
call. If the thread had been registered beforehand, this will essentially be a no-op as it should return
the same domain again. If it hadn't, attaching the thread will have set the current domain to be the
root appdomain which will be returned by `mono_domain_get` making our current domain variable now valid.
Turns out that the MSbuild task MakeDir handles quotes on
paths already. So there is no need to add them manually when
passing in a list of directories.
This also fixes the following error
Unable to create directory ""bin\Release\App84.App84.apk.mSYM"".
Illegal characters in path.
Atsushi Eno
Radek Doulik
Jonathan Pryor
Jo Shields
Marek Habersack
Bernhard Urban
Dean Ellis
Martin Baulig
Samuel Debruyn
Zoltan Varga
Jérémie Laval