Mono For Android 4.2
Visual Studio Users: You should be prompted with this update when you open a MfA project. You can also check manually in Tools > Options > Mono for Android.
MonoDevelop Users: You should be prompted to upgrade next time you open MonoDevelop, or you can use Help > Check for Updates. IDE support requires MonoDevelop 3.0.
Documentation for major components of this release can be found in these articles:
- Binding a Java Library - Describes how to use the new Java Library Binding project to create a Managed Callable Wrapper (Binding) for arbitray java libraries (jars).
- API Metadata Reference - Companion documentation to the Binding a Java Library doc, this doc covers binding transformation file syntax.
- Fragments Walkthrough - Describes how to use fragments to reuse controls across different form factors. Also covers Android Compatibility Libraries to support fragments on older OS versions.
Changes since 4.0.6
Visual Studio Integration Enhancements
NOTE: If you are opening an existing MfA solution, you may need to set it to Deploy in Build > Configuration Manager.
We are extremely pleased to introduce our graphical designer for producing Android layout files. This should make designing views for applications much easier.
There is now a toolbar available that provides a dropdown list of all running emulators and attached devices. This allows you to quickly set your default device and avoid being prompted to choose your device for every run.
The toolbar will remember your choice even if the device isn't available. For example, you can set it to your phone, and it will switch to your phone every time your phone is attached.
Choosing "-- Prompt for Device --" will utilize the current behavior of prompting you on each run.
Deploying to an emulator/device no longer blocks your work. Deployment is now done in the background, with updates displayed in the status bar. Deployment can be cancelled via Build->Cancel, and should now cancel immediately if requested.
Which projects will be deployed follows the same model as Windows Phone 7, and can be configured via the Deploy checkbox in Build -> Configuration Manager.
When running in Debug mode, Visual Studio will now automatically attach to the device's logcat and display the results in the Output pane. Many types of logging and exceptions may only show up in logcat. Now they appear automatically instead of being another place to remember to check.
- Additional parameters can be passed to emaulators started in Visual
- Tools > Options > Mono for Android > Additional Emulator Launch Arguments
- Project templates for Honeycomb/Ice Cream Sandwich applications.
- Item template for a Fragment file.
MonoDevelop 3.0 also includes our graphical designer for producing Android layout files.
- Project templates for Honeycomb/Ice Cream Sandwich applications.
- Item template for a Fragment file.
- MonoDevelop got "Publish Android Application" signing wizard that lets
you sign the application package (
.apk) and get ready to publish to Google Play (formerly Android Market).
Java Binding Library project and tool
In this release we introduced a new library generator tool that makes it
possible to bind existing Android Java library (
.jar) to C#
.dll). Now you can consume external Java library from
This includes support for importing Android Library Project into managed
library, either via local library project description files
project.properties) or archived bin files (
These new features are available in Visual Studio or MonoDevelop as a new project type (Java Bindings Library project).
Smaller Shared Runtime
The shared runtime needed is now about 50% smaller. This was accomplished by splitting each architecture into it's own runtime and removing debug symbols for Mono and the BCL. (Debug symbols for your code are still used.) If you have a situation where debug symbols for Mono help you, remove any existing shared runtime from your device, and turn on "Provide shared runtime debug symbols" from Tools > Options > Mono for Android. Then re-deploy and full debug symbols will be available.
x86 emulator support
x86 emulators are now fuly supported in the trial and full MfA editions. This
release includes fixes for library loading errors with logcat messages such as
java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library:
799 cannot locate 'atexit'..."
More event listener methods are bound to events
Previously, event listener methods would only be mapped to events if the event listener interface contained only one method. We now support event listener interfaces that have more than one method, generating one event per event listener interface method.
Improved API level support
Historically, Applications (and Debug Platform packages) would target a "minimum" API level, and could only be installed on targets running that API level or later. For example, if an Application was built against Android v2.3 (API level 10), it couldn't reliably run on a lower API level (e.g. API level 8) ("the MotionEvent problem").
This has been fixed so that it is now possible to sanely target an API level that is higher than the target's API level (e.g. target API 14 and run on API 8). Care must still be taken to only use types and members that exist on the target.
Earlier error checking
Build steps that used to be done at package creation time are now done as part of the normal build process, allowing errors to be flagged earlier. This includes Android Callable Wrapper generation and linking.
API Level 15 support
This release contains support for API Level 15 (updated Ice Cream Sandwich API).
Almost complete enum migration
Our API conversion from classic int constants to decent enum has always been incomplete and changes were based on feedback. This time we took time to review the entire API and introduced a lot of new enums, as well as fixed method parameters and return values from int to enum.
Since this brings a lot of API breakage, we also introduced some transitive
fields whose name match the old int-based fields (with
for easier application upgrades.
Android Compatibility Library binding
As we have received many requests for this, this release contains bindings for Android compatibility library that brings Fragments, ViewPager and many other useful stuff from Honeycomb to old Android platform.
Exporting arbitrary Java member for better Java integration
It is now easier to export methods for invocation and fields for access by
Java. The new
Mono.Android.Export.dll assembly allows using the new
[Export] custom attribute so that methods will be declared
on the generated Android Callable Wrapper, and the new [ExportField] custom attribute allows fields to be declared
in the generated Android Callable Wrapper.
These remove a couple of limitations in Mono for Android limitations:
- You can implement Java.IO.ISerializable interface in managed code, as it is
possible to give
writeObjectnames in Java (Android Callable Wrapper) code.
- You can implement Android.OS.IParcelable interface in managed code, as it is
possible to export
- You can use android:onClick attribute to pass a Java method name as a click handler, as it is possible to export arbitrary managed method in Java code, unlike non-export methods which are unavailable to Java.
In this release, we added DLR support which also enables C# 4.0 dynamic
System.Core.dll is expanded to include them, and
Mono.CSharp.dll joined the
framework assemblies party.
(Note that there is some limitation on using dynamic types to interoperate with Java code and the underlying dalvik runtime.)
In this release, we changed the bootstrap hook to initialize mono runtime to support Instrumentation aside from existing ordinal applications. This means now you can write your Instrumentation and start it from adb shell commands.
Java annotations and managed attributes
This release supports generating managed attributes from Java annotations. For example, we create Java.Lang.DeprecatedAttribute from java.lang.Deprecated annotation type. This is achieved by new AnnotationAttribute (Java.Lang.DeprecatedAttribute class has this managed attrubute).
When these annotation attributes were used in managed code, our build process generates corresponding Java annotation in the Java code (Android Callable Wrapper).
.NET names can now be used in Resource XML
In previous releases, when writing a Resource XML file that referenced a
managed class, the Java name of the Android Callable Wrapper had to be used. For
example, the GLCube Resources\Layout\main.xml file uses the
<mono.samples.glcube.PaintingView/> element to refer to the
Mono.Samples.GLCube.PaingintView type. Starting in this
release, the fully-qualified managed name can be used, resulting in
<Mono.Samples.GLCube.PaintingView/>. Android v4.0 Fragments
may also use the fully-qualified managed name instead of the Android Callable
Wrapper Java name.
- API Level 4: Mono.Android.dll, Mono.Android.GoogleMaps.dll, OpenTK.dll
- API Level 7: Mono.Android.dll, Mono.Android.GoogleMaps.dll, OpenTK.dll
- API Level 8: Mono.Android.dll, Mono.Android.GoogleMaps.dll, OpenTK.dll
- API Level 10: Mono.Android.dll, Mono.Android.GoogleMaps.dll, OpenTK.dll
- API Level 12: Mono.Android.dll, Mono.Android.GoogleMaps.dll, OpenTK.dll
- API Level 14: Mono.Android.dll, Mono.Android.GoogleMaps.dll, OpenTK.dll
- IJavaObject now implements IDisposable.
ToJniHandle()methods have been renamed to
ToLocalJniHandle(), and now always return a JNI local reference.
intto enum changes
- Due to the event listener change, we had to replace ItemEventArgs which was used in some limited classes with AdapterView.ItemClickEventArgs which is used everywhere applicable. ItemEventArgs still exists, but since event signature has changed, your delegate methods need to be changed as well. Use of type-inferred lambda delegates should not be effected by this change.
intto Color changes on properties, method return types, and constructor and method parameters.
- The various
<em>Foo</em>EventArgs.Eproperties are now named
- The various
<em>Foo</em>EventArgs.Vproperties have been removed, and their value is now the sender parameter of the EventHandler delegate.
- RemoteViews.SetViewVisibility() now takes ViewStates enum, not SystemUiFlags enum.
- Use of SimpleAdapter and SimpleExpandableListAdapter will need to change to use JavaList and JavaDictionary instead of List and Dictionary. This change is necessitated by the object identify fix in bug 2147. See also the mailing list threads:
- Java library binding assemblies will now register the Java package to C#
type mapping during process startup. This allows Activity.FindViewById(int) to e.g. return a MapView instead of a
- GC fixes: TODO description regarding null handle check in libmonodroid, removal of JLO fields from Framework Peers
- Better gref behavior when using
foreachover Android.Runtime.JavaList and related collection types.
- Android.App.Application.SynchronizationContext is now thread-aware, so that it won't deadlock when trying to Send() a message when already on the UI thread.
- Android Callable Wrappers no longer emit
@Override. This is to avoid the unmitigated evil that is declaring a custom Override annotation. (Granted, [Export] is a much better fix, but there's not any actual need for
@Overridein the Android Callable Wrappers...)
Java.Lang.Object coercion operators now null-check their
parameters, so implicitly converting a
nullSystem.String to a
nullinstead of throwing an exception.
- Application startup now performs a zipalign check to ensure that zipalign was run before installing the .apk. This helps reduce a source of really bizarre and obscure errors due to unaligned assemblies.
- System.Data.Services.Client now contains string resources. Exception messages should actually be useful now.
- NTLM authentication fixes: set the correct flags when the domain is not
domain/useras the user name and set domain and user accordingly.
- Fix Java.Lang.Object deserialization for JSON in Release builds.
<application/>within AndroidManifest.xml. (Failure to do so results in Android ignoring themes.)
- The Java.Lang.Throwable.StackTrace property no longer
- We now validate at build-time that the package name contains a period
'.'). If the package name doesn't contain a period, then Android will give a
INSTALL_FAILED_INVALID_APKwhen installing the package.
- Mono for Android assemblies are now strong-named.
- Building a Release build twice in a row no longer generates javac errors.
- Unsubscribing from an event will now remove the Java-side Listener implementation, reducing gref count. Previously the entire object graph would need to be collectable and a full GC would be required to collect the Listener implementation. Mailing list reference.
- 210: Fixup package names so that Android will accept them
374: Paint.Color should be of type
- 382: Add [Export] support to mandroid.
- 638: invalid format string when loading into a datatable records from the sqlite db where they have datetime fields with null values.
- 645:: MfA should allow missing library at build/run steps.
- 795: System.MethodAccessException when creating generic class.
- 981: sbyte.Parse, short.Parse raise OverflowException when parsing hexadecimal negative numbers.
- 1164: TargetInvocationException / SerializationException on response from a web service (which works on MonoTouch).
- 1416: Linker in 1.9.1 removing override methods?
- 1437: WCF FaultException<TDetail> support missing.
Android.Runtime.JavaObjectinstances should no longer be returned to developer code. It should be automatically "unwrapped" to provide the original instance.
- 2190: sdb interrupt code not signal safe.
- 2191: SqliteDataReader throws on GetDecimal()
- 2347: The ArrayAdapter<T>(..., T) constructors do not support value types.
- 2422: OpenTK.FrameEventArgs.set_Time crash
- 2483: Calling CancelAsync when using DownloadDataAsync causes System.Threading.ThreadInterruptedException: Thread interrupted
- 2769: System.Core does not include Task.Unwrap()
- 2775: Debugger tooltips for DateTimes are corrupted
- 2843: WCF: SerializationException when processing response that contains a nullable enum
- 2859: WCF: SerializationException trying to process FaultException
- 2926: DataTable.ImportRow causes InvalidCastException
- 2936: DateTime.FromFileTimeUTC has incorrect Kind set
- 3100: Error With System.Net.WebClient.UploadProgressChanged Event
- 3137: german country code creates a floating-point number problem
- 3476: culture-data return wrong values
- 3479: All linked assemblies need to check for IJavaObject
- 3497:: Package building step uses excessive memory that then is not GCed
- 3500:: Bindings generator crashes on Parse .jar
- 3634: XElement with decimal date get formatted has wrong ToString representation
- 3641: Mono 2.11 make check failures on Cygwin
- 3827: SortedSet missing from System.dll
- 3876: HttpWebRequest chunked reading problem
- 3894: Async HttpWebRequest with NTLM authentication does not auto redirect when a 301/303 response received
- 4040:: System.ArgumentException when inheriting AsyncTask<,,> and overriding RunInBackground but not DoInBackground
- 4441: Compatibility library should be called Support Packages
- 4485: Java Binding Library generates C# code that does not build
4571: .jar library binding doesn't work with
- 4592: [Export] + Release builds == TargetInvocationException
ToLocalJniHandle()methods in Release builds.
- 4594: API Demo exception thrown on Graphics->Alpha Bitmap on Release configuration
- 4605: Android.Widget.RemoteViews.SetViewVisibility does not exist for all API versions
- 4783: Check types when marshaling arrays.
- 4821: Support marshaling arrays of enum types.
ResolveLibraryProjectImportscan't find assembly via
Warning: Samsung shipped a broken kernel with Android 2.1, which is not able to support JIT compilation. If you possess a Galaxy-class device with Android 2.1, you will get unexpected results, this is caused by a kernel bug that breaks cache coherency, rendering any engine doing JIT compilation useless. Check with your manufacturer/carrier for an Android 2.2 update.