Automatic signing services
To enable users to sign apps when uploading them to Digital Lab, the administrator needs to set up the signing services.
About app signing services
Whenever an app is repackaged with Digital Lab record and replay libraries, the app needs to be re-signed. By default, Android apps are signed with a debug certificate, and no additional action is required by the administrator. For iOS apps, or for Android apps that use services requiring a private key such as Google Maps or the Authentication service, the administrator needs to set up Digital Lab for automatic signing.
You can also package and sign apps manually and then upload them to Digital Lab. For details, see Package an Android app manually or Package an iOS app manually with the packager service.
Signing service for iOS apps
You set up the iOS signing service so that iOS apps can be signed when they are uploaded to Digital Lab. The signing service is also used for signing the Agents. For details, see iOS signing service.
Signing service for Android apps requiring a private key
This section is relevant only for UFT Digital Lab.
In general, packaging of Android apps on upload to Digital Lab requires no additional action. To view the settings configured for the Android packager, click Administration > Settings tab and select Android packaging service. For more details, see Administration settings.
By default, Digital Lab signs your app with a debug certificate. If your app uses services that require a private key, for example Google Maps or the Authentication service, you need to sign your app with your own private key during the packaging process. To enable Digital Lab to sign using a private key, you need configure the app packager to use your signing details.
To configure Digital Lab to automatically sign your app with your own certificate:
- Open the packager properties file on the Digital Lab Server machine:
Linux: <Path to your server installation folder>/server/conf/packager.properties
Windows: <Path to your server installation folder>\server\conf\packager.properties
- Enter the following information:
- ANDROID_KEYSTORE_PATH = The path to your key store, which is a binary file containing your set of private keys.
- ANDROID_KEY_PASSWORD = The password for the private key to be used to sign the app.
- ANDROID_STORE_PASSWORD = The password for the key store.
- ANDROID_ALIAS_NAME =The name used to identify the private key entry in the key store.
Note: All four values are required. If any of the values is left empty, the app packaging process fails.
Automatic signing for UFT Digital Lab Managed SaaS and ValueEdge Digital Lab
To set up automatic signing services for iOS and Android:
iOS |
Configure the embedded signing service. For details, see iOS signing service. When this service is set up, the Agents and all other apps uploaded to Digital Lab can be signed with your Apple certificate and provisioning profile. Alternatively, if you choose not to set up automatic signing, you can manually sign the Agents and your apps using the iOS Enabler. For details, see Package an iOS app manually with the iOS Enabler. |
Android |
By default, Digital Lab signs your app with a debug certificate. If your app uses services that require a private key, for example Google Maps or the Authentication service, you can package the app manually and then upload it. For details, see Package an Android app manually. |
Troubleshooting the app packager
There may be times when the packaging process does not succeed. When Digital Lab is unable to create a packaged version of the app, a notification is displayed. Packaging is not essential for testing, however, there are certain test cases that require the app to be packaged. For details, see When to use a packaged app.
Packaging may not succeed for the following reasons:

- Check the settings that you defined for the packaging service in Administration > Settings.
Android:
- If you are using your own key to sign Android apps, check that the details in the app packager file on the server machine are correct.
iOS:
- Check that you have provided the correct settings for the Mac machine on which the packager service is installed if you are using the remote packager, or that the provisioning profile and Apple certificate are valid if you are using the embedded packaging service.
- Check the packaging service logs. Click the about icon
in top right of the packager UI, and download the log files.

- Try uploading the original application again.
- Android apps: If you use the Android Enabler tool to package your app, check that you are using the latest version.
- iOS apps: If you use the remote signing service or the iOS Enabler to package your app, make sure that the signing service/ iOS Enabler version matches the Digital Lab server version. For details, see and Package an iOS app manually with the packager service or Package an iOS app manually with the iOS Enabler.

- The maximum file size that you can upload is 1 GB.

To package an iOS app successfully, the Team identifier must be specified in your provisioning profile.

When uploading your Digital Lab apps, if you encounter a packaging error, use this list to determine the cause of the error. For assistance, contact your administrator.
Error Code |
Description |
2802 |
A general packaging error occurred. |
2803 |
The application couldn't be uploaded, because it used an incorrect version of the iOS Enabler. For details, see Package an iOS app manually with the packager service. |
2807 |
The version of the app packager is not compatible with this version of the Digital Lab server. |
2808 |
The app packager was not configured correctly. |
2809 |
This application no longer exists due to an upgrade of the Digital Lab server. You need to upload the application again. |
2810 |
One of the properties (PROTOCOL/IP/PORT) of the app packager is missing or incorrect. An administrator can modify these values in Administration |
2821 |
General Error: The application couldn't be packaged by the iOS Enabler. |
2822 |
The application couldn't be packaged due to an incorrect usage of the iOS Enabler. For details, see Package an iOS app manually with the packager service. |
2823 |
The application couldn't be packaged because the app was previously packaged manually with a static library using Xcode. |
2824 |
The application couldn't be packaged because the iOS Enabler couldn't code sign the app. For details, see Package an iOS app manually with the packager service. |
2825 |
The application couldn't be packaged because the iOS Enabler couldn't code sign Dylib. Check the UFT Mobile dylib file. For details, see Package an iOS app manually with the packager service. |
2826 |
The application couldn't be packaged because the iOS Enabler couldn't inject the Dylib. For details, see Package an iOS app manually with the packager service. |
2827 |
The application couldn't be packaged because the Dylib is not valid. For details, see Package an iOS app manually with the packager service. |
2829 | The application couldn't be packaged because the provisioning profile is missing a team identifier. |
2850 |
The app was successfully uploaded and Digital Lab created a packaged version of the app. However, remote content debugging could not be enabled. Note: For this error, you are not able to record, replay, or perform spy actions on unpackaged Android apps. As a workaround, try to manually Enable remote content debugging of Android apps. Alternatively, use the packaged app. |
2851 |
The app was successfully uploaded. However, Digital Lab was unable to create a packaged version of the app, nor could it enable remote content debugging. Note: For this error, try to manually Enable remote content debugging of Android apps. |
See also: