Hildon Application Manager

Overview  Development  Documentation  Testing 

Testing the Hildon Application Manager

Most testing of the Application Manager is done by installing/updating/removing packages that are in a specially prepared test repository. There are also a number of standalone packages and a number of ".install" files.

The test repository

The test repository is only available via HTTP:

The easiest way to configure the Application Manager for the test repository is to use this .install file:

It will add many new catalogues, and then install the "testrepo-conf" package which performs additional actions to configure the system for testing.

After installing one this file, you need to restart the Application Manager, disable the two "New" distributions and execute "Tools > Refresh application list".

The test repository contains six distributions:

You can switch between the "new" and "old" distributions by enabling one of them and disabling the other, obviously.

The packages and the distributions they are in:

Standalone packages

The server with the test repository also contains a number of .deb files that can be used to test the "Install from file" feature. The files can be found here.

You can open them directly with the browser or copy them to your device and open them with the File manager or via "Package / Install from file".

These standalone .deb files are available:

Files for the Single-Click-Install feature

The server with the test repository also contains .install files. These files contain instructions for the Application Manager to add repositories and/or install a package. The files can be found on here.

You can open them directly with the browser or copy them to your device and open them with the File manager or via "Package / Install from file".

These .install files are available:

Memory card repositories

The Application Manager can use repositories that are accessible in the local filesystem, such as on a memory card.

To test this, you can untar the cardrepos.tar.gz archive to your memory card or to your internal flash and then open the card-old.install and/or card-new.install files.

The archive contains two repositories, cardrepo-old and cardrepo-new. These packages are available:

How to break packages to be half-installed

Some test cases below ask you to break a package in a specific way in order to test whether the Application Manager can fix them again.

These broken packages normally result from interrupted installations, such as when the device reboots in the middle of an operation or when you take out the MMC at the wrong time.

For testing the behavior of the Application Manager, it is sufficient to trick dpkg into thinking that the package is in a intermediate state. It is not necessary to actually interrupt the installation.

A simple way to modify the state of a package is to edit /var/lib/dpkg/status. However that file is too big for the nimble busybox vi. Therefore, the following method is recommended.

You can reuse the status.broken file when you run the test case again.

Sample test cases

Here are some test cases you can do with the packages in the test repository.

Install, then update, then uninstall

Install dependencies

Detect and resolve direct conflict

Detect and resolve indirect conflict

Detect and resolve direct conflict by updating

Refusal to uninstall needed package

Install Nokia certfied software

Refusal to edit/remove essential repositories

Installing a package with a menu entry

Removing a package while its application is running

Installing/removing a big package

Install a package with a license agreement

Refusal to install a package with a missing dependency

Failure to install a corrupted package

Automatic installation/removal of non-user packages

Automatic installation/removal of non-user packages (2)

Basic single-click-install

Single-click-install with existing repository

Single-click-install with existing repository and package

Basic single-click-configure of new repository

Single-click-configure of existing repository

Single-click-configure of incompatible distribution

Single-click-configure of the maemo.org "Extras" repository

Updating to a corrupted package

Updating with a missing dependency

Updating using a incompatible package

Directly fixing a broken, half-installed package

Indirectly fixing a broken, half-installed, non-user package

Replacing a system package with a different one

Failing to replacing a system package with a different one

Installing packages from a memory card

Partially installing packages from a memory card

Updating packages from a memory card

Updating a package within its domain

Attempting to update a package from a wrong domain

Seeing translated package names and descriptions

Seeing a upgrade description

Using domains identified by URIs

Not seeing a system update meta package that is not installed

Seeing a system update meta package that is installed

Updating many packages at the same time.

Ignoring updated conffiles.

Locking down packages

Updating a lockdown meta package

Testing the update-notifier

The following describes how to force the update-notifier into certain states in order to test individual features of it. At the end of this description there is a high-level testcase that brings it all together.

The update-notifier is a statusbar plugin that is loaded all the time but invisible most of the time.

When you have installed a new version of the update-notifier, you need to restart the hildon-desktop to load the new version. A reboot is one way to do that.

It's visibility status can be checked and controlled via the GConf key


The state is an integer: 0 - invisible, 1 - visible, 2 - blinking. For example, this will cause the icon to blink:

    $ gconftool-2 -t int -s /apps/hildon/update-notifier/state 2

The update-notifier will periodically execute the apt-worker in the following way:

    # /usr/libexec/apt-worker check-for-updates [proxy]

The interval between runs is determined by the


GConf key, in minutes. Changing this key should take effect immediately; there is no need to restart hildon-desktop or to reboot. For example, this will set the checking interval to 1 minute:

    $ gconftool-2 -t int -s /apps/hildon/update-notifier/check-interval 1

Setting the check-interval to zero means to use the default interval, which is 24 hours.

You can trigger the update-notifier to run apt-worker at any time with this command:

    $ hildon-application-manager-util check-for-updates

When the Application Manager is open, the update-notifier plugin will not run apt-worker itself; it will pass on the check-for-updates requests to the Application Manager.

In general, the update-notifier should start blinking when there are updates available that the user has not yet seen. A update is 'available' when it would be listed in the "Check for updates" view (in blue-pill mode). A update has been 'seen', when the "Check for updates" view has actually been activated and the update has been shown in that view.

Thus, it is important to actually switch to the "Check for updates" view when the test cases tell you to do so, since that action will record which updates have been 'seen'.

Getting the update-notifier to blink.

Updating the Operating System

Getting the update-notifier to blink for a "Ad-push"

The test repository package

Testing customization points

Some defaults of the Application manager can be determined by an external 'settings' package. Here is such a package that configures the system to access the test repository:

To install it, you first need to remove the hildon-application-manager-settings-standard package:

  # dpkg --remove hildon-application-manager-settings-standard
  # dpkg --install hildon-application-manager-settings-testrepo_5+1_all.deb

If you want to instantiate your own variant of hildon-application-manager-settings-template, you can use the following files to get you started:

Now you should see the testrepo related catalogues in the "Application Catalogues" dialog, and almost all test cases should run normally. The exceptions are related to the update notifier; see below for alternative test cases.

Checking the default distribution

Checking the update notifier URL

Checking the list of catalogues

Checking backup/restore of customized catalogues

Checking the domain configuration

Checking the available signature-verification keys