Material Components (MDC) help developers implement Material Design. Created by a team of engineers and UX designers at Google, MDC features dozens of beautiful and functional UI components and is available for Android, iOS, web and Flutter. material.io/develop |
Aug 03, 2017 Onsen UI 2.0 To-Do sample application implemented in Vanilla JavaScript. frandiox/OnsenUI-Todo-App. Basic navigation. Android Wear 2.0 still relies heavily on gestures and taps for navigation. Press the power button to view your app list. On the LG Watch Style ($100 at. How to build.
In codelabs MDC-101 and MDC-102, you used Material Components (MDC) to build the basics of an app called Shrine, an e-commerce app that sells clothing and home goods. This app contains a user flow that starts with a login screen and takes the user to the home screen that displays products.
The recent expansion of Material Design gives designers and developers increased flexibility to express their product's brand. You can now use MDC to customize Shrine and reflect its unique style.
In this codelab, you'll customize Shrine to reflect its brand using:
- Color
- Typography
- Elevation
- Layout
This is the third of 4 codelabs that will guide you through building an app called Shrine, an e-commerce app that sells clothing and home goods. The related codelabs can be found at: By the end of MDC 104, you'll build an app that looks like this: |
What you'll need
- Basic knowledge of Android development
- Android Studio (download it here if you don't already have it)
- An Android emulator or device (available through Android Studio)
- The sample code (see next step)
How would you rate your level of experience building Android apps?
System requirements| What's new| Blogs| Open source
Installing
- Visual Studio 2019 version 16.2 — Visual Studio Installer
- Visual Studio 2019 for Mac version 8.2 — Visual Studio for Mac Installerwith the Stableupdater channel
What's new in Xamarin.Android 9.4
Xamarin.Android 9.4 releases
- September 5, 2019 — Xamarin.Android 9.4.1.1in Visual Studio 2019 version 16.2.4.
- August 6, 2019 — Xamarin.Android 9.4.1.0in Visual Studio 2019 version 16.2.1.
- August 5, 2019 — Xamarin.Android 9.4.1.0in the Stable updater channel of Visual Studio 2019 for Mac.
- July 24, 2019 — Xamarin.Android 9.4.0.51in Visual Studio 2019 version 16.2 and the Stable updater channel of Visual Studio 2019 for Mac.
Corresponding Visual Studio 2019 release notes
September 5, 2019 — Xamarin.Android 9.4.1.1
This version is included in the Visual Studio 2019 version 16.2.4 release.
Issues fixed in Xamarin.Android 9.4.1.1
Application and library build process
- GitHub 3454:Starting in Xamarin.Android 9.4.1.0, the fix for GitHub 3263unintentionally preserved additional types during managed linking, resultingin APK files that were about 7 megabytes larger than expected, depending onwhich libraries the app used.
August 5, 2019 — Xamarin.Android 9.4.1.0
This version is included in the Visual Studio 2019 version 16.2.1 release andin the Stable updater channel of Visual Studio 2019 for Mac.
Issues fixed in Xamarin.Android 9.4.1.0
Application behavior on device and emulator
- GitHub 3263:Errors similar to 'System.TypeLoadException: Could not load type'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android' would causeapp execution to abort during calls to certain C# bindings for Androidmethods in apps built with the manager linker enabled.
Application and library build process
- GitHub 3343:Errors similar to 'error: cannot access ListenableFuture ... class file forcom.google.common.util.concurrent.ListenableFuture not found' could causethe build to fail during the
_CompileJava
target when using certainlibraries like Xamarin.Google.Guava.ListenableFuture that included anembedded .jar file and no public managed types.
Xamarin.Android SDK installation
- GitHub PR 3350:'Package contains system volume install location content' error wouldprevent successful installation of the Xamarin.Android SDK on the macOSCatalina preview.
Style App 2.0 (build 2) Free
July 24, 2019 — Xamarin.Android 9.4.0.51
This version is included in the Visual Studio 2019 version 16.2 release and inthe Stable updater channel of Visual Studio 2019 for Mac.
Summary of what's new in Xamarin.Android 9.4.0.51
Build and deployment performance
- GitHub PR 2536,with follow-up adjustments inGitHub PR 2870,GitHub PR 2878,GitHub PR 2916:Add a .jar file to the Xamarin.Android installer package that containspre-built versions of a number of Java classes that are used by everyXamarin.Android project. That way the individual projects don't need tobuild the Java classes themselves. This reduced the total time for the Javacompilation step on a clean build of a test app from about 2.7 seconds toabout 2.5 seconds.
- GitHub PR 2896:Adjust the Android resource compilation build step to avoid re-running AAPT(or AAPT2) individually for each library and to avoid generating many extraunused resource IDs. For example, in a test Xamarin.Forms application, thenumber of references in the .dex file dropped from about 30,000 to about18,000, the .dex file size decreased from about 3.5 megabytes to about 3.4megabytes, and the total time for the resource compilation step in a cleanbuild dropped from approximately 3 seconds to about 20 milliseconds.
- GitHub PR 2930:Revise the
Inputs
andOutputs
for the_BuildLibraryImportsCache
target, and adjust theGetImportedLibraries
to take advantage of thoseadjustments. This allows incremental builds to skip the_BuildLibraryImportsCache
target when appropriate. It also improves theperformance ofGetImportedLibraries
for clean builds. For example, in atest Xamarin.Forms app, this change saved approximately 100 milliseconds foran incremental build after a XAML file change, and it reduced the cleanbuild time for theGetImportedLibraries
target from approximately 300milliseconds to approximately 170 milliseconds in the same project. - GitHub PR 2934,with follow-up adjustments inGitHub PR 2958:Avoid running the Xamarin.Android-specific
_BuildAdditionalResourcesCache
or_ResolveLibraryProjectImports
build steps on assembly types like .NETStandard assemblies that never contain Xamarin.Android library projectfeatures such as Android resources. This reduced the incremental build timefor these steps from about 360 milliseconds to about 80 milliseconds in atest Xamarin.Forms app where only the .NET Standard project was modifiedbetween builds. This also reduced the clean build time for these steps inthe same project from about 1.8 seconds to about 1.2 seconds. - GitHub PR 2935:Avoid copying extra .pdb or .mdb debugging symbol files to the binoutput directory in cases where the corresponding .dll assembly filesthemselves are not copied to the output directory. Depending on the sizeand number of debugging symbols for a project and the speed of the drivewhere the output directory is stored, this change can potentially save anoticeable amount of time. In a smaller test project built on an SSD, thischange saved roughly a few dozen milliseconds for an incremental build wherean assembly changed.
- GitHub PR 2952:Remove old debug logging messages from several of the build tasks. SinceMSBuild prints this information automatically when building with diagnosticverbosity, these additional logging messages are no longer needed. In somecases this change can also reduce the total build time. For example, in atest app, it reduced the clean build time from roughly 25.5 seconds to about25.0 seconds.
- GitHub PR 2956:Expand on the previous improvement from GitHub PR 2643that allowed the
GenerateJavaStubs
task to skip over .NET Standardassemblies by now also skipping the whole parent_GenerateJavaStubs
target in cases where only .NET Standard assemblies have changed. Thisallowed a small test Xamarin.Forms project to skip the_GenerateJavaStubs
target successfully, saving approximately 860 milliseconds for anincremental build in the case where only a XAML file was changed.
App startup performance
Option to compile app startup methods to unmanaged code
Visual Studio Enterprise 2019 version 16.2 includes a new Enable StartupTracing option that provides finer control over the trade-offs between AndroidAPK size and startup time as compared to the existing AOT Compilationoption.
Instead of compiling as much of the app as possible to unmanaged code, this newoption compiles only a particular set of managed methods that represent the mostexpensive parts of application startup in a blank Xamarin.Forms app. Thisapproach consumes less space in the APK compared to the AOT Compilationoption while still providing similar app startup performance improvements. In atest Xamarin.Form app, enabling this setting reduced the Mono runtimeinitialization step of application startup from approximately 370 millisecondsto approximately 250 milliseconds.
To try this feature in Visual Studio Enterprise, configure the project to useboth AOT Compilation and Enable Startup Tracing in the AndroidOptions section of the Visual Studio project property pages for the Releaseconfiguration. This sets the
$(AndroidEnableProfiledAot)
MSBuild property totrue
in your .csproj file:Other improvements
GitHub PR 2718, withfollow-up adjustments in GitHub PR3010, GitHub PR3026: Generate unmanagednative shared libraries to provide the per-application Java-to-managed andmanaged-to-Java type mappings and environment settings that Xamarin.Androidapplications use. Previously, this information was stored in data files withinthe APK that the applications would load and parse during startup, but now theapplication can directly run the unmanaged executable instructions instead.This reduced the startup time from about 240 milliseconds to about 230milliseconds for a Release configuration build of a small test Xamarin.Forms appon a Google Pixel 3 XL device.
Known issues
The GitHub PR 2718feature that generates unmanaged native shared libraries for the type mappingsand the environment settings currently depends on running the unmanaged nativelinker from the Android SDK toolchain. For 32-bit target ABIs such asarmeabi-v7a and x86, the unmanaged linkers are themselves currently 32-bitexecutables. macOS will in some cases show a 'App' is not optimized for yourMac and needs to be updated' warning when these 32-bit executables run.
Fewer DEX references, so fewer apps will need multidex
GitHub PR 2896: Improvethe Android resource compilation build step to avoid generating as many unusedresource IDs. This means that more apps will now fit within the DEX 64Kreference limit.
If you have a project that is currently configured to use Enable Multi-Dexfor the Release configuration in the Visual Studio project property pages, youcan now try disabling multidex to see if it is still needed.
Mono Framework version update to 6.0
This version of Xamarin.Android updates the Mono runtime and class librariesfrom Mono 5.18 toMono 6.0Commit e6f5369c,adding about 1,800 new commits.
Preview bindings for Android Q Beta 2
Xamarin.Android 9.4 includes preview bindings for the Android Q Beta2 release from Google. See the Android Q Betadocumentation for additional information about the behaviorand API changes in this new Android version. To try the bindings for the newAPIs in a Xamarin.Android project, set Compile using Android version: (TargetFramework) to Android 9.0.99 (Q) under the Application tab of theVisual Studio project property pages.
AAPT2 enabled by default for new projects
Xamarin.Android has included an option to use the Android Asset Packaging Tool2.0 (AAPT2) since Xamarin.Android 9.0, but ishas so far been disabled by default to provide a gradual path for finding andaddressing compatibility issues. A number of issues have now been resolved, andan up-to-date version of AAPT2 is now included as part of the Xamarin.Androidinstallation to avoid depending on the older version that is part of the AndroidSDK, so the option is now enabled by default for new projects.
Note that AAPT2 will in some cases enforce stricter rules on resource files thanthe previous AAPT, so some adjustments might be needed if you see new errormessages that come from AAPT2 itself rather than from the Xamarin.Android buildtasks. Authors of new projects are encouraged to follow the stricter AAPT2rules when possible. Authors of existing projects are encouraged to migrate toAAPT2 at their convenience.
To enable AAPT2 for a particular project, enable the Use incremental packagingsystem (aapt2) setting in the Visual Studio project property pages, or set the
$(AndroidUseAapt2)
MSBuild property to true
by hand in your .csproj file:To switch back from AAPT2 to AAPT for a particular project, uncheck the Useincremental packaging system (aapt2) setting in the Visual Studio projectproperty pages, or set the
$(AndroidUseAapt2)
MSBuild property to false
byhand in your .csproj file:Known issues
- GitHub 3083:Projects that have both Use incremental packaging system (aapt2) andGenerate one package (.apk) per selected ABI enabled and that haveCompile using Android version: (Target Framework) set to Android 7.1 orlower will fail to build due to 'The 'BuildApk' task failed unexpectedly...Could not find file'objRelease71androidbinpackaged_resources-armeabi-v7a'.
- GitHub 3237:Errors similar to 'error CS0117: 'Resource' does not contain a definitionfor 'Layout' can sometimes abort the build when attempting to buildsolutions with parallel builds enabled. Parallel builds are enabled bydefault in Visual Studio. The setting can be found in Tools > Options >Build and Run > maximum number of parallel project builds.
- GitHub 3314:'Java.Lang.Exception: android.content.res.Resources$NotFoundException: Fileres/drawable/abc_vector_test.xml from drawable resource ID #0x7f080058'will abort app execution on Android 4.4 KitKat (API level 19) or lower forapps built with AAPT2 that use Android Support Libraries.Workaround:Add the
--no-version-vectors
option to the$(AndroidAapt2LinkExtraArgs)
MSBuild property in your .csproj file:Then clean and rebuild the project. - GitHub 3336:In projects configured to use AAPT2, invalid Android resource elements addedafter an initial successful design-time build do not produce errors duringsubsequent incremental builds.
- GitHub 3344:In app projects configured to use AAPT2, builds show incorrect file pathsfor AAPT2 errors caused by existing library projects built with AAPT thathave Android resource elements that are now invalid with AAPT2.
Initial support for Android App Bundle publishing format
At Google I/O 2018, Android introduced a new AndroidApp Bundle publishing format for Google Play.Xamarin.Android 9.4 includes a new build option to generate Android App Bundlesfor Xamarin.Android apps.
Limitation: For apps deployed to devices running Android versions between6.0 Marshmallow (API level 23) and 8.1 Oreo (API level 28), this featurecurrently only works if the app has the
android:installLocation
attribute set to'internalOnly'
in the Android manifest. This setting can be configured underInstall location > Internal Only in the Android Manifest section of theVisual Studio project property pages. This limitation will be resolved in afuture Xamarin.Android release.To try the new format with your project, you can set the
$(AndroidPackageFormat)
MSBuild property to aab
for the Releaseconfiguration in your .csproj file:When this property is set, the
SignAndroidPackage
MSBuild target will createan archive in the bin directory that uses the Android App Bundle format.This new build option is not yet surfaced in the Visual Studio project propertypages. Additionally, the Build > Archive command does not yet support thisfeature. To create a .aab file that is suitable for submission to GooglePlay, you can instead run a command similar to the following in a DeveloperCommand Prompt:
Replace the values for the signing properties with the appropriate key storefile name, key alias, and passwords for your distribution key. See thedocumentation for additional information about theseproperties.
After running the
msbuild
command, locate the signed .aab file in the binoutput directory.Known issues
- GitHub 3298:'JNI DETECTED ERROR IN APPLICATION: mid null' or 'CallStaticIntMethodVreceived NULL jclass' '... in call to CallStaticIntMethodV ... from voidmono.android.Runtime.init' will prevent apps built using an Installlocation other than Internal Only from running successfully wheninstalled via Google Play on devices running Android versions between 6.0Marshmallow (API level 23) and 8.1 Oreo (API level 28).
- Setting
$(AndroidPackageFormat)
toaab
currently increases build timesfor the Use Fast Deployment Debug configuration setting, so it isrecommended to set the new property only for the Release configuration fornow.
jit-times
analysis tool
Xamarin.Android 9.4 includes a new command-line tool to help analyze JIT timinglog information emitted by the Mono runtime for Xamarin.Android apps for userswho might be curious to look at some details about how time is spent by the JIT.See the tool's README for additional information.
Issues fixed in Xamarin.Android 9.4.0.51
Application and library build process
- Developer Community 396678:Bindings library projects could fail to build because they failed togenerate corresponding C# constructors for certain Java constructors.
- Developer Community 435034:Deployment to device or emulator would fail with 'error MSB4018: The'CopyFileFromZipToZip' task failed unexpectedly.' for projects that used the
Assemblies:Dexes
fast deployment mode incombination with the D8 Dex compiler. - GitHub 2680:Xamarin.Android projects that referenced Android libraries containingresource files could sometimes fail on 'The process cannot access the file... objDebug90lp26jlmanifestAndroidManifest.xml' because itis being used by another process.'
- GitHub PR 2795,GitHub PR 2849,GitHub 1128:Several of the MSBuild targets were using
BeforeTargets
orAfterTargets
in cases where they could be avoided. One consequence was that theLinkAssemblies
task would still run in cases where theCompile
targethad failed. This resulted in misleading extra error messages about thefailure of theLinkAssemblies
task. - GitHub PR 2881:Xamarin.Android build tasks that used
Parallel.ForEach()
could producenon-descriptive 'One or more errors occurred.' errors when they failed.Several of those cases have now been improved to produce 'XA0000' errorswith more descriptive inner exception messages. - GitHub PR 2896:The Xamarin.Android build process would launch many
aapt
(oraapt2
)processes for apps that referenced many Android libraries containingresource files. These builds now no longer launch as many separateprocesses. - GitHub PR 2896:The Android resource compilation build step was generating a large number ofextra unused resource IDs for Xamarin.Android apps that referenced librariescontaining many resources, such as the Xamarin.Android.Support andXamarin.GooglePlayServices libraries. This meant that those applicationswere more likely to exceed the DEX 64K reference limit and morelikely to require the Enable Multi-Dex setting compared to similar appswritten in Java or Kotlin.
- GitHub PR 2905:The error message from
adb
was not included as part of the MSBuild errormessage in cases whereadb
exited due to an error during deployment. - GitHub PR 2975:The
ResolveAndroidTooling
MSBuild task took roughly 80 milliseconds longerfor incremental builds when projects enabled the Use incremental packagingsystem (aapt2) setting. - GitHub PR 2984:The diagnostic MSBuild log output for Xamarin.Android projects did not listthe input file locations used to generate intermediate outputs likeobjDebug90lp12jlresdrawable. This could make it moredifficult to identify the responsible input file if one of the intermediatefiles caused a build error. The paths for the input files are now includedas
%(OriginalFile)
metadata on the items so that the input file for eachitem will be recorded in the diagnostic log output. - GitHub PR 3114:Projects that had Use incremental packaging system (aapt2) enabled couldencounter relatively slower builds in apps that used custom subclasses of
Android.View.View
. In these cases, AAPT2 was being run on each of theavailable resource directories instead of only on the parent directories oflayout files that contained custom views. This could potentially cost anextra 10 seconds for a medium sized project during both clean builds andincremental builds where a XAML file had changed. - GitHub PR 3174:Builds could fail due to 'error APT0000: failed parsing overlays.' forprojects with Use incremental packaging system (aapt2) enabled.Xamarin.Android 9.4.0.34 updates the included
aapt2
executable to version3.4.1-5326820 to resolve this issue. - GitHub PR 3196:In certain build scenarios for projects that used AAR files, some of theXamarin.Android MSBuild targets including
_ConvertLibraryResourcesCases
,_UpdateAndroidResgen
, and_CreateBaseApk
would always run. - GitHub xamarin-android-tools PR 72:In some environments, antivirus software could block access to the registry,preventing the Xamarin.Android build process from locating the default JDKinstallation as expected.
- Builds could occasionally fail during the
ResolveXamarinAndroidTools
taskwith 'Did not find Xamarin.Android at path ... warning XA5300: Unable todetermine Xamarin.Android version' due to the order in which MSBuild ran theResolveXamarinAndroidTools
task relative to theDetectIfAppWasUninstalled
task. @(AndroidAsset)
MSBuild items that used%(LogicalName)
metadata withrelative paths were not copied to the correct intermediate output locationduring the build.
Application behavior on device and emulator
- GitHub 3049:Projects with Use incremental packaging system (aapt2) enabled couldencounter 'java.lang.ArrayIndexOutOfBoundsException' errors when running ondevice because incorrect resource IDs were being generated in theResource.designer.cs file for resources that referenced
android:
resource names either directly or indirectly. - GitHub 3123:Apps built with Use incremental packaging system (aapt2) enabled couldhit an error similar to 'Android.Views.InflateException: Binary XML fileline #1: Binary XML file line #1: Error inflating classInflatedLibrary.CodeBehindClass occurred' after an incremental build where acustom view defined in a library project had been updated.
- GitHub 3169:Applications could hit an exception similar to 'Failed resolution of:Landroid/support/v7/appcompat/R$drawable; --->Java.Lang.ClassNotFoundException: Didn't find class'android.support.v7.appcompat.R$drawable' on path: DexPathList' in projectsthat had Use incremental packaging system (aapt2) enabled.
Design-time build process
- Developer Community 461522,GitHub 3007:Xamarin.Android's built-in managed parser for Android resource files wasgenerating resource ID fields that used the
.
character as a nameseparator for certain resource file inputs, resulting in 'A const fieldrequires a value to be provided' and 'Syntax error, ',' expected'IntelliSense errors.
Android API bindings
- GitHub 2864:The
Android.Security.Keystore.KeyStorePurpose
type did not include a[Flags]
attribute, so using bitwise operators on it would produce warningsin static analysis tools.
Xamarin.Android SDK installation
- GitHub 2686,GitHub PR 2733,with follow-up adjustments inGitHub PR 2826:The .vsix installer package for Windows contained a few unnecessary filesthat were not present in the .pkg installer package for macOS.Additionally, the .pkg installer for macOS did not automatically removethe previous version during installation, so unused old versions couldaccumulate under /Library/Frameworks/Xamarin.Android.framework/Versions.
Known issues in Xamarin.Android 9.4.0.51
- GitHub 3263:Errors similar to 'System.TypeLoadException: Could not load type'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android' cause appexecution to abort during calls to certain C# bindings for Android methodsin apps built with the manager linker enabled.Workaround:Use a custom linker configuration to preserve themissing types. To do that, add a new linker.xml file to the project, setthe Build Action to LinkDescription, and add the XML lines topreserve the missing types. For example, for the
ITextWatcherInvoker
error, add the following lines to the file: - GitHub 3322:Errors similar to 'error MSB4018: The 'LinkAssemblies' task failedunexpectedly. ... System.IO.FileNotFoundException: Could not load assembly'prevent successful completion of the build when attempting to use the oldRun Code Analysis static style of code analysis that runs binaryanalyzers.
- GitHub 3343:Errors similar to 'error: cannot access ListenableFuture ... class file forcom.google.common.util.concurrent.ListenableFuture not found' can cause thebuild to fail during the
_CompileJava
target when using certain librarieslike Xamarin.Google.Guava.ListenableFuture that include an embedded .jarfile and no public managed types.Workaround:Add the following lines to the bottom of your app project's .csproj file (just before the closing</Project>
tag): - GitHub PR 3350:The Xamarin.Android SDK installer .pkg file for macOS is not yetcompatible with the macOS Catalina preview.
- GitHub PR 3379:'The 'FilterAssemblies' task was not given a value for the requiredparameter 'DesignTimeBuild'.' error prevents projects from buildingsuccessfully when they use certain additional MSBuild targets, such as thetargets from the NuGet.Build.Packaging NuGet package.Workaround:In your .csproj file, conditionally set the
$(DesignTimeBuild)
MSBuildproperty to a placeholder value offalse
when it is empty:
Feedback
Your feedback is important to us. If there are any problems with this release, check ourGitHub Issues,Xamarin.Android Community Forums andVisual Studio Developer Communityfor existing issues. For new issues within the Xamarin.Android SDK, please report aGitHub Issue.For general Xamarin.Android experience issues, let us know via theReport a Problemoption found in your favorite IDE under Help > Report a Problem.
Contributors
A big Thank You! to contributors who made improvements in this release:
- Atsushi Eno (@atsushieno),GitHub PR 2829:Add initial preview bindings for Android Q Beta.
- Atsushi Eno (@atsushieno),GitHub PR 2830:Remove unneeded api*.xml.in files from the xamarin-android repositorybecause those files are now generated.
- Evgeniy Stepanov (@xtmq),GitHub PR 2905:Include the error message from
adb
as part of the MSBuild error message incases whereadb
exits due to an error during deployment. - Atsushi Eno (@atsushieno),GitHub PR 2965:Add preview bindings for Android Q Beta 2.
- Atsushi Eno (@atsushieno),GitHub Java.Interop PR 419:Update the Android API bindings generator tools to support additional Javalanguage constructs that are used by the Android Q Beta stub .jar files.
OSS core
Xamarin.Android 9.4 is based on the open-source Xamarin.Android repositories:
- Core JNI interaction logic is in the Java.Interop repo.
- Android bindings and MSBuild tooling are in the xamarin-android repo.
- Chat is in the
xamarin/xamarin-android
Gitter channel.