Xamarin android build apk

Toggle on the option for Android App Bundle to produce an .aab and an .apk . If the .csproj file contains aab in the AndroidPackageFormat property, this option will automatically be toggled on. Building an .aab is supported for Xamarin.Android 9.4 and higher.

3.5. Increment version number

When enabled, the version code in the AndroidManifest.xml of your app automatically increments for each build. The change happens pre build and won’t be committed to your repository.

3.6. Code signing

A successful build will produce an .apk file and an additional .aab file if enabled. To release the build to the Play Store, it must be signed with a valid Keystore and Alias. To sign the builds produced from a branch, enable code signing in the configuration pane, upload your Keystore, and provide the values needed in the configuration pane. You can read more detailed code signing instructions. The .aab will be signed using the same credentials as the .apk .

3.7. Launch your successful build on a real device

Use your newly produced .apk file to test if your app starts on a real device. This adds approximately 10 more minutes to the total build time. There’s more information in our test integration guide.

3.8. NuGet restore

If the NuGet.config file is checked-in into the repository and sitting next to the .sln file or at the root level of your repository, App Center restores your private NuGet feeds when they’re added as shown in the example below. Credentials can be added safely by using environment variables:

If you have complex configurations and need more information, refer to Configuring NuGet behavior.

3.9. Distribute the build

You can configure each successful build from a branch to be distributed to a previously created distribution group or a store destination. You can add a new distribution group or configure a store connection from within the Distribute service. There’s always a default distribution group called «Collaborators» that includes all the users who have access to the app.

If distributing to the Google Play Store, an Android App Bundle ( .aab ) is preferred and will be distributed if enabled. For App Center distribution groups and Intune store destinations, a regular .apk will be used even if an .aab is also generated.

4. Build results

After a build triggers, the build will be in one of the following states:

• queued — the build is in a queue waiting for resources to be freed up.
• building — the build is running.
• succeeded — the build completed successfully.
• failed — the build stopped with failures. You can troubleshoot what went wrong by downloading and inspecting the build log.
• canceled — the build was canceled by a user action or it timed out.

4.1. Build logs

For a completed build (succeeded or failed), download the logs to understand more about how the build went. App Center provides an archive with the following files:

The build step logs (located in the build/ directory of the archive) are helpful for understanding in which step and why the build failed.

4.2. The app (.apk)

The .apk file is an Android application packaged file that stores the Android app. If the build has been correctly signed, the .apk file can be installed on a real device and deployed to the Play Store. If the build hasn’t been signed, the app can run on an emulator or be used for other purposes.

Supported versions and requirements

App Center supports Portable Class Library (PCL) and .NET Standard projects. Refer to Cloud Build Machines for versions of .NET Standard.

App Center doesn’t support Components from the Xamarin Component Store and we advise using NuGet packages whenever they’re available. If you’re using a Component that can’t be replaced, contact us. See help and feedback.

Источник

Build Process

The Xamarin.Android build process is responsible for gluing everything together: generating Resource.designer.cs , supporting the @(AndroidAsset) , @(AndroidResource) , and other build actions, generating Android-callable wrappers, and generating a .apk for execution on Android devices.

Application Packages

In broad terms, there are two types of Android application packages ( .apk files) which the Xamarin.Android build system can generate:

Release builds, which are fully self-contained and don’t require extra packages to execute. These are the packages that are provided to an App store.

Debug builds, which are not.

These package types match the MSBuild Configuration which produces the package.

Shared Runtime

Prior to Xamarin.Android 11.2, the shared runtime was a pair of extra Android packages which provide the Base Class Library ( mscorlib.dll , etc.) and the Android binding library ( Mono.Android.dll , etc.). Debug builds rely upon the shared runtime in lieu of including the Base Class Library and Binding assemblies within the Android application package, allowing the Debug package to be smaller.

The shared runtime could be disabled in Debug builds by setting the $(AndroidUseSharedRuntime) property to False .

Support for the Shared Runtime was removed in Xamarin.Android 11.2.

Fast Deployment

Fast deployment works by further shrinking Android application package size. This is done by excluding the app’s assemblies from the package, and instead deploying the app’s assemblies directly to the application’s internal files directory, usually located in /data/data/com.some.package . The internal files directory is not a globally writable folder, so the run-as tool is used to execute all the commands to copy the files into that directory.

This process speeds up the build/deploy/debug cycle because the package is not reinstalled when only assemblies are changed. Only the updated assemblies are resynchronized to the target device.

Fast deployment is known to fail on devices which block run-as , which often includes devices older than Android 5.0. Fast deployment also fails for system applications (android:sharedUserId=»android.uid.system») since run-as is also blocked for system applications.

Fast deployment is enabled by default, and may be disabled in Debug builds by setting the $(EmbedAssembliesIntoApk) property to True .

The Enhanced Fast Deployment mode can be used in conjunction with this feature to speed up deployments even further. This will deploy both assemblies, native libraries, typemaps and dexes to the files directory. But you should only really need to enable this if you are changing native libraries, bindings or Java code.

MSBuild Projects

The Xamarin.Android build process is based on MSBuild, which is also the project file format used by Visual Studio for Mac and Visual Studio. Ordinarily, users will not need to edit the MSBuild files by hand – the IDE creates fully functional projects and updates them with any changes made, and automatically invoke build targets as needed.

Advanced users may wish to do things not supported by the IDE’s GUI, so the build process is customizable by editing the project file directly. This page documents only the Xamarin.Android-specific features and customizations – many more things are possible with the normal MSBuild items, properties and targets.

Binding Projects

The following MSBuild properties are used with Binding projects:

Resource.designer.cs Generation

The Following MSBuild properties are used to control generation of the Resource.designer.cs file:

Signing Properties

Signing properties control how the Application package is signed so that it may be installed onto an Android device. To allow quicker build iteration, the Xamarin.Android tasks do not sign packages during the build process, because signing is quite slow. Instead, they are signed (if necessary) before installation or during export, by the IDE or the Install build target. Invoking the SignAndroidPackage target will produce a package with the -Signed.apk suffix in the output directory.

By default, the signing target generates a new debug-signing key if necessary. If you wish to use a specific key, for example on a build server, the following MSBuild properties are used:

keytool Option Mapping

Consider the following keytool invocation:

To use the keystore generated above, use the property group:

Build Extension Points

The Xamarin.Android build system exposes a few public extension points for users wanting to hook into our build process. To use one of these extension points you will need to add your custom target to the appropriate MSBuild property in a PropertyGroup . For example:

Extension points include:

A word of caution about extending the build process: If not written correctly, build extensions can affect your build performance, especially if they run on every build. It is highly recommended that you read the MSBuild documentation before implementing such extensions.

Target Definitions

The Xamarin.Android-specific parts of the build process are defined in $(MSBuildExtensionsPath)\Xamarin\Android\Xamarin.Android.CSharp.targets , but normal language-specific targets such as Microsoft.CSharp.targets are also required to build the assembly.

The following build properties must be set before importing any language targets:

All of these targets and properties can be included for C# by importing Xamarin.Android.CSharp.targets:

This file can easily be adapted for other languages.

Источник

How do I create apk file for a Xamarin.Android application

I am new to android development and need to create an apk file for an android application I made in Xamarin Studios so my peer can test it on his device. How can I create the apk file?

4 Answers 4

For even simpler/faster testing, you can:

• connect an Android phone to the USB and use it for debugging/testing. See https://docs.microsoft.com/en-us/xamarin/android/get-started/installation/set-up-device-for-development.
• build your app (as debug, for example)
• Every time you test on your phone by clicking on the «play button» button example, it automatically creates an APK under bin\Debug\ or bin\Release.
• The file you are looking for is the «Signed apk», e.g. com.companyname.MyApp-Signed.apk
• Copy this file to the device using any method (I usually use USB or GDrive). On the device, download it and click on it to install.

Important:

«Use Shared Runtime» inside the project properties/Android Options must be Disabled, otherwise Mono Runtime won’t be included and your app will crash on phones where Mono isn’t installed.Example

1. Select Build menu next click Archive for Publishing
2. Right-Click on build which do you want get apk file next select Sign and Distribute
3. Select Ad Hock and click next button
4. Select testing certificate and click next button
5. Publish and choose where do you want save apk file.

For simple testing:

1. Build the project in Release mode
2. Go to your project’s /bin/Release folder
3. Inside the folder, you will find the required signed apk file.
4. The apk file should now be installable simply by running it from an Android device.

With the latest Visual Studio 2019 and the latest xamarin, I will literally walk you through all the steps:

1. Change your project from «Debug» mode to «Release» mode like below:

Build your android project first.

Right-click on your android project -> click «Archive. «

It’ll show something like this: Let it complete its processing

When it’s done, click the «Distribute» button, it’ll open a menu like this:

1. Click on the «Ad Hoc» button and click the «+» button like below:

1. fill the form and click the «Create» button

1. Select your saved settings and click the «Save As» button

1. Chose your location to save and save the APK file and get it from where you saved it 🙂

Источник

Вам также может понравиться

Как деактивировать режим наушников на смартфоне с Android?

Когда к мобильному устройству присоединены наушники

Обзор игры Джелли-Джу для Android

В последние годы популярность мобильных игр резко возросла

Лучшие шахматные приложения для iOS и Android

Нынешний читерский скандал в шахматном мире сейчас

Что хотят увидеть пользователи от Android 5.0 Key Lime Pie

ОС Google Android развивается, и по всему видимому