Creating the app package

Now that our app is finally finished, we can get started creating the final app package. We need to ensure that the actual package meets Google Play's requirements and is signed with a key from a keystore.

How to do it...

Before we can create the app package, we need to ensure that the package will be accepted by Google Play and the metadata describes the app correctly. To do this, we use the app's project settings to provide the correct values for the packaging process:

  1. We first need to provide a name that will be used when listing the app on the device. This should be a string resource, but can be a normal string:
    How to do it...

    The application name field

  2. Next, we will provide a unique package name, which is the ID that is used to identify our app on Google Play:
    How to do it...

    The package name field

  3. We now specify the Application icon, which represents the default image used for the app. We can do this using the [Application] attribute:
    [assembly: Application(Icon = "@drawable/iconit is just an alternati")]
  4. Also, we can set the Application icon in the AndroidManifest.xml file, using the project options:
    How to do it...

    The application icon field

  5. Then, we provide versioning information. The Version number text box is an integer used internally by Android, and the Version name text box is a user-facing string:
    How to do it...

    The version number and version name fields

  6. Finally, we specify the preferred install location of the app on the device:
    How to do it...

    The install location field

Now that the package is ready to be created, we can switch to the release configuration and start the build process:

  1. First, ensure that we are on the Release configuration.
  2. Next, we must package the app. In Xamarin Studio, we select the Build | Archive for Publishing menu item. In Visual Studio, this step is not required:
    How to do it...

    Archive for publishing

  3. After the project has been archived in Xamarin Studio, we select the archive that was just created and click on the Sign and Distribute button:
    How to do it...
  4. In the case of Visual Studio, we navigate to Tools | Android | Publish Android App... menu item. This performs both the archive and sign steps in a single wizard:
    How to do it...
  5. In either case, the packaging and signing wizard will appear and we just have to follow the onscreen instructions. The wizard will ask us to select a key from a keystore, and a location to save the final app package. If we don't have a keystore yet, we will create one in the wizard.

How it works...

Once an app's code is complete and the various compiler options have been set, we will create the final package that will be uploaded to Google Play. Just before we build the package, we need to first check that the packaging options are correct for this release of the app. These options are used to display and categorize the app of both the device as well as Google Play.

The first option is the Application name, which is used as the title for the app on Google Play. Once the app is installed, the name that appears on the launcher will actually be the name of the activity. In the same way, the Application icon option is also only used on Google Play, and the activity icon used on the device launcher. As these two fields are user-visible resources, they should be localized. The Application name field can be a plain string, but this is not recommended.

Tip

The app icon can also be provided using the Icon property of the [Application] attribute.

The Package name field is really the ID that is used to identify our app on Google Play. This has to be unique across the entire store and cannot be changed once the app has been published. As a result, it is important that we select a name that will remain relevant throughout our app's lifetime.

Note

The package name must be unique across the store and cannot be changed.

The next important part of the package is the version. Versioning consists of the internal, integer number representing our app's version. Every release must receive a higher number, and this is used by Google Play to determine whether the app needs to be updated on the user's device.

The other component to the version, is the user-friendly Version name. This can be any string that we want to present to the user, and it is not used by Google Play. Usually, this is in the form <major>.<minor>.<point>, or in the case of .NET versioning, <major>.<minor>.<build>.<revision>.

Note

The version number is an internally-used integer, and the version name is a publicly-visible string.

The last packaging option to set, is the install location. Here, we specify where to try and install to. We can request that we install to the external storage, or specify that we must always, and only, install to the internal storage. If the app is quite large, we should prefer the external storage.

When we want to actually create the app package, that is, the .APK file that we upload to Google Play, we must build the release configuration. When using Xamarin Studio, we must archive the app before signing the package for distribution. In Visual Studio, we do both steps when we publish the app.

Note

An APK file is the name given to the final Android application package, which is uploaded to an Android app store, such as Google Play.

When signing, we use a key, or certificate, from a keystore. This key is used by Android to verify the author of the app. We can reuse an existing keystore, or we can create a new one in the wizard. However, we must use a keystore that only expires after October 22, 2033.

All versions of the same app must be signed with the same key, otherwise Google Play can't verify that the app update was created by the same author. A new key will make it necessary for us to create a totally new app with a new package name. Although not required for many apps, only those signed with the same key can run in the same process and share code.

Note

The same key must be used to sign each version of the app, otherwise the app cannot be updated seamlessly.

There's more...

Maintaining the security of our keystore is of critical importance, both for us as developers and for the user. The keys can be used to impersonate the publisher and access users' private data.

The keystore is required for signing all future versions of our app. If we lose or misplace our keystore, we will not be able to publish updates to our existing app. This is because we cannot regenerate a previously generated key.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset