offline

Date post:16-Jan-2016
Category:
View:26 times
Download:8 times
Share this document with a friend
Transcript:
  • Part 1 - Preparing an Application for Release

    After an application has been coded and tested, it is necessary to prepare a package for distribution.

    Preparing the package consists of the following steps:

    Compile For Release This step involves setting some application attributes.

    Create a Private Key This step needs to be performed only once. A private key is necessary to

    digitally sign the APK. After the private key has been prepared, this step can be skipped for future

    release builds.

    Sign the APK This step involves signing the APK with the private key that was created in the

    previous step.

    Zipalign the APK Zipalign is an optimization process that is performed on an application. It

    enables Android to interact more efficiently with the APK at runtime. Xamarin.Android conducts a

    check at runtime, and will not allow the application to run if the APK has not been zipaligned.

    The last two steps of preparing an application for release differ in Xamarin Studio and Visual Studio. The

    difference between these two steps will be covered in more detail below.

    Compile the Application for Release

    The first step in distribution is to compile the Xamarin.Android application for release. Compiling for release

    involves:

    Disable Debugging This prevents users from trying to debug the application on a device by using

    ADB or other tools.

    Specify the Application Icon Each Xamarin.Android application should have an application icon

    specified. It is not technically required; however, some markets, such as Google Play, require it.

    Version the Application This step involves initializing or updating the versioning information. This

    is important for future application updates and to ensure that the users are aware of which version of

    the application they have installed.

    Configure the Linker Linking is a step that is specific to Xamarin.Android and can substantially

    reduce the size of the final APK by removing un-used code.

    Compile This step will compile the code and assets into an APK that is ready for signing.

    Each of these steps is described in more detail below.

    Disable Debugging

  • During development of an Android application, debugging is performed with the use of the Java Debug

    Wire Protocol (JDWP). This is a technology that allows tools such as ADB to communicate with a JVM for

    the purposes of debugging. JDWP is turned on by default for Debug builds of a Xamarin.Android

    application. While JDWP is important during development, it can pose a security issue for released

    applications.

    Note:

    Always disable the debug state in a released application as it is possible (via JDWP) to gain full access to

    the Java process and execute arbitrary code in the context of the application, if this debug state is not

    disabled.Inside the Android manifest exists the attribute android:debuggable, which controls whether

    or not the application may be debugged. It is considered a good practice to set the android:debuggable

    to false.

    The simplest way to do this is by adding a conditional compile statement to AssemblyInfo.cs:

    #if DEBUG

    [assembly: Application(Debuggable=true)]

    #else

    [assembly: Application(Debuggable=false)]

    #endif

    Specify The Application Icon

    It is strongly recommended that a Xamarin.Android application should specify an application icon. Some

    application marketplaces will not allow an Android application to be published without one.

    The Icon property of the ApplicationAttribute is used to specify the application icon for a

    Xamarin.Android project. This attribute can be declared in the file Properties\AssemblyInfo.cs, as

    shown in the sample snippet:

    [assembly: Application(Icon = "@drawable/ic_launcher")]

    With Xamarin Studio, it is also possible to specify the application icon through the Project Options dialog,

    under Xamarin.Android Application, as shown in the following screenshot:

  • The Xamarin.Android plug-in for Visual Studio 2010 does not have this setting, so the Application Icon must

    be set by using the ApplicationAttribute (described above).

    Versioning

    Versioning is important for Android application maintenance and distribution. Without some sort of

    versioning in place, it is difficult to determine if or how an application should be updated.

    To assist with versioning, Android recognizes two different types of information. The first is a version code,

    which is used internally by Android and the application. The second type of information, a version name, is

    only used for communicating information to the user about the version of the application that is installed on

    the specific device that is in use.

    There are two attributes that are available to provide version information:

    android:versionCode This is an integer value that represents the version of the application. Most

    applications start out with this value set to 1, and then it is incremented with each build. This value

    has no relationship or affinity with the android :v ersionName attribute (see below). Applications and

    publishing services should not display this value to users.

    android:versionName This is a string that is meant to be displayed to users or in Google Play.

    This string is not used internally by Android at all. This can be any string value that would help a user

    identify the build that is installed on their device.

    In Xamarin Studio, these values can be set via Project Options, under the Build Android

  • Applications tab, as shown in the following screenshot:

    In Visual Studio 2013, these values can be set in the Android Manifest section of Project Properties, as

    shown in the following screenshot:

  • Compile the Application for Release

    In general, applications are developed using Debug mode by default. It will be necessary to change this to

    Release mode. Release mode turns off the shared runtime and turns on linking so that the application only

    ships the pieces of Xamarin.Android required at runtime. The linker in Xamarin.Android will use static

    analysis to determine which assemblies, types, and type members are used or referenced by a

    Xamarin.Android application. The linker will then discard all the unused assemblies, types, and members

    that are not used (or referenced). This can result in a significant reduction in the package size. For

    example, consider the HelloWorld sample, which experienced an 83% reduction in the final size of the

    APK:

    Configuration Xamarin.Android 4.2.5 Size

    None 17.4 MB

    SDK Assemblies Only3.0 MB

    In Visual Studio 2013, you set linker options through project properties: Under Android Options, click the

    Linker tab as shown in the following screen shot:

    The Linking pull-down menu provides the following options for controlling the linker:

    None This turns off the linker; no linking will be performed.

  • Sdk Assemblies Only This will only link the assemblies that are required by Xamarin.Android .

    Other assemblies will not be linked.

    Sdk and User Assemblies This will link all assemblies that are required by the application, and not

    just the ones required by Xamarin.Android.

    In Xamarin Studio, you set linker options through the Linker tab of project properties in the Xamarin.Android

    Build section, as shown in the following screenshot:

    The options for controlling the linker are as follows:

    Don't link This turns off the linker; no linking will be performed.

    Link SDK assemblies only This will only link the assemblies that are required by Xamarin.Android

    . Other assemblies will not be linked.

    Link all assemblies This will link all assemblies that are required by the application, and not just

    the ones required by Xamarin.Android.

    Linking can have some unintended side effects, so it is important that an application be tested in Release

    mode. The testing must also occur on a physical device.

    After configuring the linker, compile the application. Next, you will create a signed APK in conjunction with a

  • private keystore. Xamarin Studio and Visual Studio 2010 have different workflows for signing a keystore;

    each of these workflows is covered in the following sections.

    Creating a Private Keystore

    A keystore is a database of security certificates that is created by using the program keytool from the Java

    SDK. A keystore is critical to publishing a Xamarin.Android application, as Android will not run applications

    that have not been digitally signed.

    During development, Xamarin.Android uses a debug keystore to sign the application, which allows the

    application to be deployed directly to the emulator or to devices configured to use debuggable applications.

    However, this keystore is not recognized as a valid keystore for the purposes of distributing applications.

    For this reason, a private keystore must be created and used for signing applications. This is a step that

    should only be performed once, as the same key will be used for publishing updates and can then be used

    to sign other applications.

    It is important to protect this keystore. If it is lost, then it will not be possible to publish updates to the

    application with Google Play. The only solution to the problem caused by a lost keystore would be to create

    a new keystore, re-sign the APK with the new key, and then submit a new application. Then the old

    application would have to be removed from Google Play. Likewise, if this n

Popular Tags: