Xamarin android version support

Xamarin android version support

If you use the Xamarin platform to develop Android apps, you can use the SDK that Oracle Mobile Cloud Service (MCS) provides for Xamarin Android apps. This SDK simplifies authentication with MCS and provides native wrapper classes for MCS platform APIs.

Getting the SDK for Xamarin Android

To get the MCS client SDK for Xamarin Android, go to the Oracle Technology Network’s MCS download page.

To use this SDK, you should have the following software on your system:

Microsoft Visual Studio, with support for Xamarin development.

Java Development Kit (JDK) 1.7.0_67 or compatible.

Adding the SDK to a Xamarin Android Project

If you haven’t already done so, extract the contents from the SDK zip.

In Visual Studio, create a Visual C# Android app.

Make sure you can connect to the internet from Visual Studio connection so that NuGet packages are reachable.

Add GCM and Facebook dependencies to your project:

If a Packages node appears in the Solution Explorer for your project, do the following:

Right-click the Packages node.

Type GCM in the search field, select Xamarin.GooglePlayServices.Gcm ( not Crosslight.Xamarin.GooglePlayServices.GCM ), and click Add Package . The remaining GCM dependencies will be added automatically.

Accept the terms to add the packages successfully.

Add Xamarin.Facebook.Android by searching for it in the NuGet packages and adding it in the same way you added the GCM packages.

If a Packages node doesn’t appear in the Solution Explorer for your project, do the following:

Select Tools > NuGet Package Manager > Manage NuGet Packages for Solution .

Select the Browse tab.

Type GCM in the search field, select Xamarin.GooglePlayServices.Gcm ( not Crosslight.Xamarin.GooglePlayServices.GCM ), select the checkbox for your app, and click Install . The remaining GCM dependencies will be added automatically.

After previewing the changes, click OK .

Add Xamarin.Facebook.Android by searching for it in the NuGet packages and adding it in the same way you added the GCM packages.

At the end make sure you have all the below dependencies. If any of them are missing, search for them in the NuGet package manager.

Add the SDK’s DLL file to your app by right-clicking the project’s References node and selecting Edit References or Add Reference (depending on which menu item is available).

If you select Edit References , click the .NET Assembly tab, and then browse to the Android.dll file in the extracted SDK zip.

If you select Add Reference , click the Browse tab, click the Browse button, and then navigate to the Android.dll file in the extracted SDK zip.

Add the configuration file to the app by right-clicking the project’s Assets node and selecting either Add > Add Files or Add > Existing File (depending which is available) and then navigating to the SDK’s oracle_mobile_cloud_config.xml file.

Select the node for oracle_mobile_cloud_config.xml so that it’s properties are displayed in the Properties pane. Then make sure that the Build Action property is set to AndroidAsset .

Open oracle_mobile_cloud_config.xml and fill in the environment details for the mobile backend that the app will be using. See Configuring SDK Properties for Xamarin Android.

Update the AndroidManifest.xml file with the necessary properties as detailed in Configuring Your AndroidManifest.xml File.

Configuring SDK Properties for Xamarin Android

To use the SDK in an Android app, you need to add the oracle_mobile_cloud_config.xml configuration file to the app and fill it in with environment details for your mobile backend. In turn, the SDK classes use the information provided in this file to access the mobile backend and construct HTTP headers for REST calls made to APIs.

mobileBackends — The config file’s root element, containing one or more mobileBackend elements.

mobileBackend — The element for a mobile backend.

mbeName — The name of the mobile backend associated with your app.

mbeVersion — The version number of your app (for example, 1.0 ).

default — If true , that mobile backend is treated as the default and thus can be easily referenced using the getDefaultMobileBackend(Context context) method in the SDK’s MobileBackendManager class.

appKey — The application key, which is a unique string assigned to your app when you register it as a client in MCS. See Registering an App as a Client in MCS.

baseUrl — The URL your app uses to connect to its mobile backend.

enableLogger — When set to true , logging is included in your app.

enableAnalytics — When set to true , analytics on the app’s use can be collected.

authorization — Use the sub-elements of this element to define the authentication the app will be using and specify the required credentials.

authenticationType — Define the kind of authentication mechanism being used to connect your app to MCS. Possible values are oauth (for OAuth Consumer) , basic (for HTTP Basic), sso , tokenAuth (for SSO token exchange), and facebook (for logging in with Facebook credentials). If this element isn’t specified, OAuth Consumer is used. The other contents and sub-elements of the authorization element depend on the type of authentication.

oAuthTokenEndPoint — The URL of the OAuth server your app goes to, to get its authentication token.

oAuthClient — The unique client identifier assigned to all apps when they’re first created in your mobile backend.

oAuthClientSecret — The unique secret string assigned to all apps they’re first created in your mobile backend.

The resulting authorization element might look something like this:

The resulting authorization element might look something like this:

SSO with a Third Party Token

The resulting authorization element might look something like this:

mobileBackendID — The unique identifier assigned to a specific mobile backend. It gets passed in an HTTP header of every REST call made from your app to MCS, to connect it to the correct mobile backend. When calling platform APIs, the SDK handles the construction of the authentication headers for you.

anonymousKey — A unique string that allows your app to access APIs that don’t require login. In this scenario, the anonymous key is passed to MCS instead of an encoded user name and password combination.

The resulting authorization element might look something like this:

facebookAppId — The Facebook application ID.

scopes — You can use this element to specify Facebook permissions (optional).

The resulting authorization element might look something like this:

Configuring Your AndroidManifest.xml File

Permissions for operations such as accessing the network and finding the network state are controlled through permission settings in AndroidManifest.xml . These permissions are required:

permission.INTERNET — Allows your app to access open network sockets.

permission.ACCESS_NETWORK_STATE — Allows your app to access information about networks.

Other permissions are optional. For example, the Analytics platform API uses location to provide detailed information about the usage and performance of your app. If you’re using the Analytics library from the SDK, you’ll want to add these permissions as well.

permission.ACCESS_COARSE_LOCATION — Allows your app to access approximate location information, derived from sources such as wi-fi and cell tower positions.

permission.ACCESS_FINE_LOCATION — Allows your app to access precise location information, derived from sources such as GPS.

For more information about permissions in your Android application, see Android Manifest Permissions in the Google documentation.

Add the permissions at the top of your AndroidManifest.xml file, as shown in the following example:

If you are using the Notifications API in your app, you may also need to add a broadcast receiver element. See Setting Up a Mobile App for Notifications.

Loading a Mobile Backend’s Configuration into a Xamarin Android App

For any calls to MCS APIs using the Xamarin Android SDK to successfully complete, you need to have the mobile backend’s configuration loaded from the app’s oracle_mobile_cloud_config.xml file. You do this using the MobileBackendManager class:

Authenticating and Logging In Using the SDK for Xamarin Android

Here is some sample code that you can use for authentication through MCS in your Xamarin Android apps.

First you initialize the authorization agent and set the authentication type to OAUTH .

Then you use the authenticate method to attempt authentication. The call includes parameters for Android context, user name, password, and a callback that completes the authorization process.

Here’s the definition for the callback.

SSO with a Third-Party Token

First, your app needs to get a token from the third-party token issuer. The way you can obtain the token varies by issuer. For detailed information on obtaining third-party tokens and configuring identity providers in MCS, see Third-Party SAML and JWT Tokens.

The default expiration time for storing a third-party token in MCS is 6 hours. You can adjust this time by changing the Security_TokenExchangeTimeoutSecs policy.

Here’s the callback:

HTTP Basic Authentication

The code for handling login with HTTP Basic is nearly the same as the code for OAuth.

First you initialize the authorization agent and set the authentication type to BASIC_AUTH .

Then you use the Authenticate method to attempt authentication. The call includes parameters for Android context, user name, password, and a callback that completes the authorization process.

Here’s the definition for the callback.

First you initialize the authorization agent and set the authentication type to Facebook .

Using a CallbackManager object from Facebook’s SDK, initiate authentication.

Here’s code you can use for the callback that is passed above.

Override the OnActivityResult() method to use the callback.

Calling Platform APIs Using the SDK for Xamarin Android

Once the mobile backend’s configuration info is loaded into the app and you have made a call to get the mobile backend, you can use SDK classes for various platform APIs.

Here are some code snippets that illustrate how to access these APIs with the SDK.

Источник

Xamarin.Android 10.0 release notes

Installing

What’s new in Xamarin.Android 10.0

Xamarin.Android 10.0 releases

• November 5, 2019 — Xamarin.Android 10.0.6.2 in Visual Studio 2019 version 16.3.8 and the Stable updater channel of Visual Studio 2019 for Mac version 8.3.7
• October 8, 2019 — Xamarin.Android 10.0.3.0 in Visual Studio 2019 version 16.3.3
• October 7, 2019 — Xamarin.Android 10.0.3.0 in the Stable updater channel of Visual Studio 2019 for Mac version 8.3.2
• September 23, 2019 — Xamarin.Android 10.0.0.43 in Visual Studio 2019 version 16.3 and the Stable updater channel of Visual Studio 2019 for Mac version 8.3

Corresponding Visual Studio 2019 release notes

November 5, 2019 — Xamarin.Android 10.0.6.2

This version is included in the Visual Studio 2019 version 16.3.8 release and in the Stable updater channel of Visual Studio 2019 for Mac version 8.3.7.

Issues fixed in Xamarin.Android 10.0.6.2

Application Mono Framework behavior on device and emulator

This version of Xamarin.Android updates the Mono 6.4 runtime and class libraries from Commit 5608fe0a to Commit 476d72b9, adding 7 new commits.

The primary reason for this update is to keep the Mono commit aligned with Xamarin.iOS and Visual Studio for Mac, but it also provides a fix for one issue that was reported in Xamarin.Android applications:

• GitHub 3726: System.NotSupportedException: ‘TypeConverter cannot convert from System.String. prevented apps from using TypeConverter.ConvertFromString() to create an instance of System.Drawing.Color .

October 7 and 8, 2019 — Xamarin.Android 10.0.3.0

This version is included in the Visual Studio 2019 version 16.3.3 release and in the Stable updater channel of Visual Studio 2019 for Mac version 8.3.2.

Issues fixed in Xamarin.Android 10.0.3.0

Application Mono Framework behavior on device and emulator

This version of Xamarin.Android updates the Mono 6.4 runtime and class libraries from Commit 7af64d1e to Commit 5608fe0a, adding 18 new commits.

Fixes included for issues reported with Xamarin.Android applications:

• Mono GitHub 16395: DateTime.Now transitioned to daylight saving time an hour late in certain time zones.
• Mono GitHub 16950: Starting in Xamarin.Android 9.4, NotImplementedException for DeflateStream.WriteCore() prevented using StreamWriter with GZipStream .
• Mono GitHub 17064, GitHub 3723: Errors similar to System.TypeLoadException: ‘Could not resolve type with token 01000143 from typeref (expected class ‘System.Diagnostics.CodeAnalysis.MaybeNullAttribute’ in assembly ‘netstandard, Version=2.1.0.0 could cause apps to abort when they tried to use types from .NET Standard 2.1 libraries such as Microsoft.EntityFrameworkCore 3.0.

Application and library build process

• Mono GitHub 17064, GitHub 3723: Errors similar to Failed to resolve System.Void System.Diagnostics.CodeAnalysis.DoesNotReturnIfAttribute. ctor(System.Boolean) could prevent deploying or archiving successfully in the Release configuration for apps that referenced .NET Standard 2.1 libraries such as Microsoft.EntityFrameworkCore 3.0.

September 23, 2019 — Xamarin.Android 10.0.0.43

This version is included in the Visual Studio 2019 version 16.3 release and in the Stable updater channel of Visual Studio 2019 for Mac version 8.3.

Summary of what’s new in Xamarin.Android 10.0.0.43

Bindings for Android 10

Xamarin.Android 10.0 includes bindings for the Android 10 release from Google. See the Android 10 documentation for additional information about the behavior and API changes in this new Android version. To use the bindings for the new APIs in a Xamarin.Android project, set Compile using Android version: (Target Framework) to Android 10.0 (Q) under the Application tab of the Visual Studio project property pages.

Improved support for Android App Bundle publishing format

The previous limitation with the Install location when using the Android App Bundle Bundle publishing format is now resolved. Projects that have the $(AndroidPackageFormat) MSBuild property set to aab that are built on the command line using the SignAndroidPackage MSBuild target now produce .aab packages compatible with any Install location. This resolves the following issue:

• GitHub 3298: JNI DETECTED ERROR IN APPLICATION: mid == null or CallStaticIntMethodV received NULL jclass . in call to CallStaticIntMethodV . from void mono.android.Runtime.init prevented apps packaged using the Android App Bundle publishing format and an Install location other than Internal Only from running successfully when installed via Google Play on devices running Android versions between 6.0 Marshmallow (API level 23) and 8.1 Oreo (API level 27).

The version of the bundletool executable included in Xamarin.Android has also been updated from 0.8.0 to 0.10.0, bringing in several improvements and bug fixes.

Known issues

• GitHub 3596: Strings from .resx files are not localized in apps packaged using the Android App Bundle publishing format.
• GitHub 3598: Errors similar to Java.IO.IOException: This file can not be opened as a file descriptor; it is probably compressed can occur when attempting to use binary assets in apps packaged using the Android App Bundle publishing format.

Enable Startup Tracing no longer requires the Android NDK

The new Enable Startup Tracing option introduced in Visual Studio Enterprise 2019 version 16.2 no longer requires an Android NDK installation. Xamarin.Android now includes its own versions of the as , ld , and strip utilities that it uses to compile the startup methods to unmanaged code when Enable Startup Tracing is enabled. Additionally, the Enable Startup Tracing option is now available in the project property pages for all editions of Visual Studio.

To try this feature, configure the project to use Enable Startup Tracing in the Android Options section of the Visual Studio project property pages for the Release configuration. This sets the $(AndroidEnableProfiledAot) MSBuild property to true in your .csproj file:

For Visual Studio Enterprise users, note that this change also means the AOT Compilation option no longer requires the Android NDK. In contrast, the Use LLVM Optimizing Compiler option still does require the Android NDK.

AAPT2 enabled by default for all projects

AAPT2 will in some cases enforce stricter rules on resource files than the previous AAPT, so some adjustments might be needed if you see new error messages that come from AAPT2 itself rather than from the Xamarin.Android build tasks.

The previous release enabled AAPT2 by default for new projects. Xamarin.Android 10.0 now enables AAPT2 by default for existing projects as well.

To switch back from AAPT2 to AAPT for a particular project, check and then re-uncheck the Use incremental packaging system (aapt2) setting in the Visual Studio project property pages, or set the $(AndroidUseAapt2) MSBuild property to false by hand in your .csproj file:

Known issues

• GitHub 3344: In app projects configured to use AAPT2, builds show incorrect file paths for AAPT2 errors caused by existing library projects built with AAPT that have Android resource elements that are now invalid with AAPT2.

Mono Framework version update to 6.4

This version of Xamarin.Android updates the Mono runtime and class libraries from Mono 6.0 to Mono 6.4 Commit 7af64d1e, adding about 1,500 new commits.

In Xamarin.Android 10.0, HttpClient currently no longer calls methods that are set on System.Net.ServicePointManager.ServerCertificateValidationCallback . To perform custom certificate validation with HttpClient in Xamarin.Android 10.0, apps must instead set a callback method on System.Net.Http.HttpClientHandler.ServerCertificateCustomValidationCallback .

For maximum compatibility across previous and future versions of Xamarin.Android, it is recommended to set both ServicePointManager.ServerCertificateValidationCallback and HttpClientHandler.ServerCertificateCustomValidationCallback , especially for Xamarin.Android library projects that are distributed publicly, such as NuGet packages.

The change in callback behavior comes from Mono GitHub PR 13338, which updated HttpClient on Xamarin.Android to use the implementation from CoreFX. The result is that Xamarin.Android 10.0 now follows the behavior of other CoreFX target frameworks like .NET Core, where HttpClient only uses HttpClientHandler.ServerCertificateCustomValidationCallback during certificate validation.

Some highlights of fixes included for issues reported with Xamarin.Android applications:

• GitHub 3388: Starting in Xamarin.Android 9.4, DllImport could fail for certain unmanaged libraries, resulting in DllNotFoundException exceptions.
• GitHub 3397: Starting in Xamarin.Android 9.4, NotImplementedException exceptions prevented using Stream.CopyToAsync() to copy into a GzipStream .

Build and deployment performance

• GitHub PR 3068: Change the two build tasks that were using %(HintPath) to use ItemSpec instead. With the way MSBuild currently works, %(HintPath) can sometimes contain incorrect leftover metadata from unrelated items, whereas ItemSpec is always correct. Also change some LINQ expressions to loops. This reduced the time for GenerateResourceDesigner from about 200 milliseconds to about 150 milliseconds in a clean build of a test project.

R8 version update to 1.4.93

GitHub PR 3121: The version of the R8 code shrinker included in Xamarin.Android has been updated from 1.3.52 to 1.4.93.

Important change

Existing Xamarin.Android projects that have the Code shrinker set to r8 and that have the Minimum Android version set to at least Android 5.0 Lollipop (API level 21) will now ignore any custom class lists provided via the MultiDexMainDexList build action. The build will output a new warning in this case:

This change was introduced to improve compatibility with R8 version 1.4.93, which now only allows customizing the list of classes in the primary DEX file for apps with minimum Android versions lower than API level 21. For apps with higher minimum Android versions, R8 determines the list of classes automatically.

Issues fixed in Xamarin.Android 10.0.0.43

Application and library build process

• GitHub 2584: Starting in Xamarin.Android 9.2, Error processing method: ‘System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)’ could occur if the Compile using Android version: (Target Framework) setting had been changed between two successive builds.
• GitHub PR 2967: The error XA0115: invalid value ‘armeabi’ error message did not suggest how to remove the invalid value in cases where the value did not appear in the Visual Studio property pages.
• GitHub PR 3115: One of the steps in the BuildApk build task did not yet log a diagnostic MSBuild message to record the outcome of the step.
• GitHub 3083: Projects that had both Use incremental packaging system (aapt2) and Generate one package (.apk) per selected ABI enabled and that had Compile using Android version: (Target Framework) set to Android 7.1 or lower would fail to build due to The «BuildApk» task failed unexpectedly. Could not find file ‘obj\Release\71\android\bin\packaged_resources-armeabi-v7a.
• GitHub 3237: In projects configured to use AAPT2, errors similar to error CS0117: ‘Resource’ does not contain a definition for ‘Layout’ could sometimes abort the build when attempting to build solutions with parallel builds enabled.
• GitHub PR 3243: Warnings similar to warning XA0106: Skipping AndroidApp.Resource.Drawable.avd_hide_password_1. Please check that your Nuget Package versions are compatible. appeared during builds when libraries referenced Android resources in certain ways. These items are now logged as informational messages instead of warnings.
• GitHub 3276: The «GenerateJavaStubs» task failed unexpectedly. System.ArgumentNullException . at Mono.Cecil.AssemblyNameReference.Parse(String fullName) prevented projects from building successfully if they tried to use an ApplicationAttribute.NetworkSecurityConfig property on a custom Android.App.Application subclass.
• GitHub PR 3327: Errors similar to APT0000: Invalid file name: It must contain only [^a-zA-Z0-9_.-]+ could prevent projects from building successfully if they used LogicalName metadata on Android resources and had Use incremental packaging system (aapt2) enabled.
• GitHub 3336: In projects configured to use AAPT2, invalid Android resource elements added after an initial successful design-time build did not produce errors during subsequent incremental builds.
• GitHub PR 3379: Starting in Xamarin.Android 9.4.0.52, The «FilterAssemblies» task was not given a value for the required parameter «DesignTimeBuild». error prevented projects from building successfully when they used certain additional MSBuild targets, such as the targets from the NuGet.Build.Packaging NuGet package.
• GitHub PR 3430: The Xamarin.Android build process added a trailing \ to certain properties such as $(AndroidNdkDirectory) and $(AndroidSdkDirectory) even when they were set to the empty string. This was a compatibility issue for upcoming IDE features.
• GitHub PR 3445: The Java compilation build step did not yet have a dedicated error code for failures when running javac .
• GitHub PR 3463: Errors similar to error: class Class1 is public, should be declared in a file named Class1.java prevented incremental builds from completing successfully if a custom subclass of Java.Lang.Object was changed by capitalizing or lowercasing some letters of the class name between builds.
• GitHub 3494: Errors similar to error APT0000: resource . not found. could prevent builds from completing successfully until the project was cleaned if a build was started shortly after a layout file was changed.
• GitHub 3564: error XA3001: Could not link native shared library: libxamarin-app.so prevented projects from building successfully on the macOS Catalina preview.
• GitHub Java.Interop PR 425: JniFieldInfo.ToString() and JniMethodInfo.ToString() threw NotSupportedException . These methods now return strings as expected.
• warning XA5300: Unable to determing Xamarin.Android version could appear during one build and then disappear on the next build because the ResolveXamarinAndroidTools build task was not always running before the GetPrimaryCpuAbi task.
• Some of the steps in the DetectIfAppWasUninstalled and GetPrimaryCpuAbi build tasks did not yet log diagnostic MSBuild messages to record their outcomes.

Application behavior on device and emulator

• GitHub 3058: Starting in Xamarin.Android 9.2, HttpClient no longer respected the system-wide proxy settings when configured to use the default AndroidClientHandler . It would only use a proxy if the app explicitly configured one on the HttpClient instance.
• GitHub 3395: In apps built using AAPT2, managed Resource.Styleable IDs were incorrect when a contained more than ten elements. This could result in absent or incorrect resource content in running apps.
• GitHub 3314: Java.Lang.Exception: android.content.res.Resources$NotFoundException: File res/drawable/abc_vector_test.xml from drawable resource ID #0x7f080058 error would abort app execution on Android 4.4 KitKat (API level 19) or lower for apps built with AAPT2 that used Android Support Libraries.

Android API bindings

• GitHub 3313: The Xamarin.Android API bindings for AudioRecord did not yet inherit from AudioRouting , so the AudioRouting.OnRoutingChangedListener API introduced in Android 7.0 Nougat (API level 24) was not yet available via AudioRecord . Starting with the Xamarin.Android bindings for Android 10.0 (API level 29), the AudioRouting.OnRoutingChangedListener API is now available via AudioRecord .

Xamarin.Android SDK installation

• GitHub 3457: Starting in Xamarin.Android 9.4, the Xamarin.Android SDK .pkg installer package for macOS changed how it created symlinks in the /Library/Frameworks/Xamarin.Android.framework/ install location. This broke a special usage scenario where some users might have occasionally installed two versions of the Xamarin.Android SDK into the Xamarin.Android.framework/ directory and switched between the versions by changing the Versions/Custom symlink. That special usage now behaves as before.

Known issues in Xamarin.Android 10.0.0.43

GitHub 3370: warning XA4306: R8 does not support `MultiDexMainDexList` files is shown when building projects that have the Code shrinker set to r8, Enable Multi-Dex enabled, and Minimum Android version set to at least Android 5.0 Lollipop (API level 21), even if no @(MultiDexMainDexList) items are set.

GitHub PR 3561: The _GenerateJavaStubs target can run during builds where it isn’t needed if any of the previous builds involved a change to a class that inherited from Java.Lang.Object .

GitHub 3562: Building a Xamarin.Android app that includes an embedded Android Wear app reruns a number of expensive MSBuild tasks even when the outputs are already up-to-date.

GitHub 3626: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value can prevent using Newtonsoft.Json.JsonConvert.DeserializeObject() successfully in some apps.

Workaround:

Add a new linker.xml file to the project, set the Build Action to LinkDescription, and add the following lines to it to preserve the AndroidClientHandler type:

Feedback

Your feedback is important to us. If there are any problems with this release, check our GitHub Issues, Xamarin.Android Community Forums and Visual Studio Developer Community for existing issues. For new issues within the Xamarin.Android SDK, please report a GitHub Issue. For general Xamarin.Android experience issues, let us know via the Report a Problem option found in your favorite IDE under Help > Report a Problem.

Contributors

A big Thank You! to contributors who made improvements in this release:

• Sam (@SamuelDebruyn), GitHub PR 3060: Fix GitHub 3058 so that AndroidClientHandler will use the system-wide proxy settings in cases where a system-wide proxy is configured and no proxy is explicitly configured on the HttpClient instance.

Источник