App packaging and signing services
Digital Lab supports testing both packaged and non-packaged native and hybrid apps.
A packaged app is an app that Digital Lab has repackaged with instrumented libraries.
Although both packaged and non-package apps are supported by Digital Lab, packaging is still required
To generate transaction response time information.
For photo, video, and fingerprint authentication simulation. iOS GPS simulation also requires a packaged app.
When conducting performance testing of hybrid apps.
There are also some differences between packaged and non-packaged apps in the following areas:
- Full Device Automation functionality such as cross-app recording and recording of system apps is not supported in packaged apps.
- Support for touch gestures.
- Object recognition.
For more details, see the known issues section in the Digital Lab Support matrix.
For UFT One, see also the Object Model Reference (OMR) for mobile in the UFT One Help Center.
Considerations when using non-packaged hybrid apps
When using non-packaged hybrid apps, note the following:
|Android apps||Remote content debugging must be enabled. For details, see Enable remote content debugging of Android apps.|
|iOS apps||Apps may need to be signed with a Development certificate of either an Apple Developer or Enterprise Account. For the certificates required, see iOS app signing.|
Digital Lab packaging and signing services
Digital Lab supports testing both packaged and non-packaged native and hybrid apps. This gives you the option of selecting either a packaged app, or the original version, when running a test.
Whenever the content of an app package is changed, for example when the app is repackaged with instrumented Digital Lab libraries, the app also needs to be re-signed. If the app package is not re-signed, the app cannot be installed on a device.
Note: You generally do not need to re-sign apps when packaging for labs that support automatic signing with their own certificate (OpenText hosted public devices, ADF devices, and WeTest devices).
When you upload an app, by default only the non-packaged version of the app is uploaded. To upload both a packaged and non-packaged version of the app, select the Package the application check box when uploading your app.
When the Package and re-sign the application option is selected, Android apps uploaded to the Mobile Lab are automatically packaged with instrumented Digital Lab libraries and signed with a debug certificate. However, if you want to package an Android app that uses services requiring a private key, such as Google Maps or the Authentication service, you need to configure the Android app packaging and signing services. For details, see Automatic signing services.
Note: For better performance, the minSDKversion for packaged Android apps should be 21 or later.
You can also package and sign apps manually and then upload them to Digital Lab. For details see, Package an Android app manually.
To enable users to sign apps when uploading them to Digital Lab, the administrator needs to set up Automatic signing services.
If you have not configured the signing services, you cannot select the Re-sign the application option on upload.
You can also package and sign apps manually and then upload them to Digital Lab. For details see, Package an iOS app manually with the packager service, or Package an iOS app manually with the iOS Enabler.
When working with many devices and workspaces, you may need to use different signing services for your devices. For example, in iOS environments you can only sign up to 100 devices with a single certificate. In addition, you may need to provide a solution for one group without having to rely on the certificate from another group.
This feature is available only with a Trial, Enterprise, or Ultimate license. For more details, see Digital Lab licenses.
This section is relevant only for the remote packaging service. Although you can add another service in the embedded iOS signing service settings, additional services are not supported with the embedded service and the primary service is always used. For more details, see iOS signing service.
Admin users can define other signing services in addition to the primary service, and assign them to different workspaces. After you assign a signing service to a workspace, all apps uploaded to that workspace are signed with the iOS signing service defined for that workspace. As an admin, you can also remove signing services, but not the primary one.
Note that the Agents are always signed with the primary service. For details on how to distribute the signed Agents, see View and manage connectors.
To test an iOS app with Digital Lab, you may need to re-sign your app. This section explains when you need to re-sign an iOS app.
Note: You do not need to re-sign the Agent apps for OpenText public and private hosted devices, ADF devices, and WeTest devices.
Other iOS apps
The following table details when app signing is required, and what certificates can be used for signing:
|Application under Test||Mode||Re-sign required?||Required certificate|
|iOS native app||Packaged app||Yes||Any type of certificate of either an Apple Developer or Enterprise account|
|iOS native app||Non- packaged app||No, unless your organization needs to re-sign the app for some specific reason.||Any type of certificate of either an Apple Developer or Enterprise account|
|iOS hybrid app||Packaged app||Yes||
Development certificate of either an Apple Developer or Enterprise account
|iOS hybrid app||Non-packed app||
|To identify WebView, development certificate of an Apple Developer account.
Important note for cloud labs:
You generally do not need to re-sign apps when packaging for labs that support automatic signing with their own certificate (OpenText hosted public devices, ADF devices, and WeTest devices).
iOS apps signed with an Enterprise certificate cannot be installed on WeTest devices