26 Deploying MAF Applications

This chapter describes how to deploy mobile applications for testing and for publishing.

This chapter includes the following sections:

• Introduction to Deployment of MAF Applications

• Working with Deployment Configurations

• Deploying an Android Application

• Deploying an iOS Application

• Deploying a MAF Application to the Universal Windows Platform

• Deploying Feature Archive Files (FARs)

• Creating a Mobile Application Archive File

• Creating Unsigned Deployment Packages

• Deploying with Oracle Mobile Security Suite

26.1 Introduction to Deployment of MAF Applications

MAF uses deployment configurations to deploy applications to a device or a virtual device. A MAF deployment configuration consists of a set of different libraries that is specific to the release or debug mode of deployment and to the deployment target.

Before you can publish an application for distribution to users, you must test it on a device or virtual device to assess its behavior and ease of use. You create deployment configurations which you use to deploy your MAF application to the device or virtual device (emulator or simulator) where you want to test your MAF application.

MAF uses the deployment configuration to execute the deployment of an application by copying a platform-specific template application to a temporary location, updating that application with the code, resources, and configuration defined in the MAF project. MAF then builds and deploys the application using the tools of the target platform. You can deploy a mobile application as the platform-specific package which you can make available from a download site or application marketplace (for example, the Apple App Store). For testing and debugging, you can deploy to a device or virtual device. You can reuse the application features by deploying the view projects as a feature archive (FAR). You also have the option to reuse the entire mobile application by deploying it as a Mobile Application Archive (.maa) file.

Each MAF deployment configuration (Android, iOS, Windows) includes a set of different libraries that are specific to the type of deployment (release or debug) in combination with the deployment target (simulators or actual devices). In addition, each set of these libraries includes a JVM JAR file. The application binding layer resides within this virtual machine, which is a collection of Objective-C libraries. For example, MAF deploys a JVM JAR file and a set of libraries for a debug deployment targeted at an iOS simulator, but deploys a different JVM JAR file and set of libraries to a debug deployment targeted to an actual iOS-powered device. The libraries that you declare for the project are included in the deployment artifacts for the project.

26.2 Working with Deployment Configurations

MAF provides platform-specific deployment configurations that define how an application is packaged into an archive for deployment to a platform device or virtual device.

You create a deployment configuration for the platform you want the application to run on (Android, iOS, Windows). A deployment configuration defines how an application is packaged into the archive that will be deployed to the platform device (for example, an Android-powered device or Android emulators). The deployment configuration does the following:

• Select the assembly project to package and deploy.

• Select the target to deploy to. The target is a combination of a platform (for example, Android) and a specific version of the MAF runtime.

• Selects the device profile, that is the emulator or device, to deploy to.

• Selects platform-specific advanced options.

• Specifies the application to deploy.

In addition to the platform-specific deployment configurations, MAF also enables you to package the MAF application as a MAF Application Archive (.maa) file. Using this file, you can create a new MAF application using a pre-existing application that has been packaged as an .maa file. By default, this deployment file bears the name of the MAF application followed by _archive. See Creating a Mobile Application Archive File.

26.2.1 About Deployment Configurations

MAF uses deployment configurations to deploy applications to a device or a virtual device. A MAF deployment configurations consists of a set of different libraries that are specific to the release or debug mode of deployment and the deployment target.

You can use deployment configurations to deploy a MAF application immediately after creating it using the Run button, as shown in Figure 26-1.

Figure 26-1 Creating a Run Configuration

26.2.2 Differences Between Run Configurations and Debug Configurations

Select Run Configurations or Debug Configurations from the Run menu. Select Debug Configurations to compile a build for application testing, or select Run Configurations to compile a build that is ready for release.

The Run Configurations and Debug Configurations are both invoked from the Run menu, and they differ in that Debug Configurations has an additional tab, the Debug tab, where you set debug options. See Testing and Debugging MAF Applications..

• Debug—Select this option for development builds. Designating a debug build results in the inclusion of debugging symbols.

  During development, you must select debug in order to use the default keystore.

  At runtime, MAF indicates that an application has been deployed in the debug mode by overlaying a debugging symbol that is represented by an exclamation point within a red triangle.

• Run—Select to compile the build ready for release, with libraries, and so on, release bits and libraries, and so on.

  Tip:

  Use the run mode, where the application is compiled for release, not the debug mode, to test application performance.

26.2.3 How to Create a Deployment Configuration

Create new deployment configurations, or edit them to deploy applications to platform-specific targets. Use the given procedure to create a deployment configuration.

When you create an application you select the deployment targets for the application. Later, when you create the deployment configuration you select the deployment targets to use. You can deploy an application using these configurations, edit them, or construct new ones using the MAF-specific configurations dialog. The Run configurations dialog and Debug configurations dialog enable you to create default deployment configurations. You can create as many deployment configurations as you want.

Before you begin

To enable OEPE to deploy mobile applications, you must designate the SDKs for the target platforms as described in Configuring Mobile Application Framework.

To enable OEPE to deploy mobile applications, you must designate the SDKs for the target platforms using the MAF Preferences page.

Tip:

For iOS deployments, run iTunes and the iOS Simulator at least once before you configure their directory locations in the MAF Platforms preferences page.

To create a deployment configuration:

1. For development, select Run, and then Debug Configurations.

   For production, select Run, and then Run Configurations.

2. Navigate to MAF Application, and right-click and select New to create a new configuration (see Figure 26-1).
3. Do the following:

   • Accept the default name for the configuration or enter a new one.

   • Select the Assembly project.

   • Select the target from the list of those available and the device or emulator from the list of those available. If necessary, refresh the list.

   • If necessary, select the keystore and key alias for the device you are deploying to.

4. If you want to deploy immediately, click Run. To save the configuration click Apply. Alternatively, click Close and in the Save Changes dialog, click Yes.

26.2.4 What Happens When You Create a Deployment Configuration

When you initiate an application deployment, OEPE creates a deployment package, and then deploys the package to the device or emulator.

When you deploy an application by clicking Run or Debug, it triggers the packaging and deployment of the application. OEPE creates a deployment directory and related subdirectory. It also creates Feature Archive files (FARs) for the view projects (which must have different names) and assembly project. In addition to these two FARs, OEPE creates copies of any FARs that were imported into the project. Finally, the package is deployed to the device or emulator.

To clean the deploy artifacts, use the Clean dialog to just one set of projects, or all projects. You can clean:

• Just one set of projects. This is the fastest way to do a clean-rebuild.

  Select Clean projects selected below then select the assembly project you want to clean, and click OK.

• All projects. This ensures that all user artifacts get rebuilt before being re-staged and deployed.

  Select Clean all projects, and click OK.

Once you have created a run configuration, you can select it by clicking the green Run arrow from the menu bar. Clicking the arrow will select the last-used run configuration. You can select a different run configuration by clicking the drop-down selector next to the green arrow and selecting the configuration you want to run from the context menu.

26.3 Deploying an Android Application

Use the Debug Configurations option to deploy an application to an Android-powered device for testing. Then, use the Run Configurations option to bundle the mobile application as an Android application package so that it can be published.

After you define the deployment configuration, you can deploy a mobile application to the Android platform from the run configuration dialog or debug configuration dialog, as shown in Figure 26-2.

Using the debug configuration dialog, you can deploy the completed application to an Android emulator or to an Android-powered device for testing. After you have tested and debugged the application, you can use the run configuration dialog to bundle the mobile application as an Android application package (.apk) file so that it can be published to users through an application marketplace, such as Google Play.

Figure 26-2 Deployment Configuration Dialog for Android Applications

26.3.1 How to Create an Android Deployment Configuration

The creation of a deployment configuration for the Android platform requires the setting of the Android SDK and signing properties for the application, defining the javaccompiler, and specifying the images used for application icons. Use the given procedures to set the MAF preferences for the Android platform SDKs, and to create the configuration.

To create the deployment configuration for Android, you must define the signing options for the application, the behavior of the javac compiler, and if needed, override the default Oracle images used for application icons with custom ones.

Before you begin

Install and download the Android SDK as described in How to Install the Android SDK.

If you deploy to an Android emulator, you must create a virtual device for each emulator instance using the Android Virtual Device Manager, as described in the Managing Virtual Devices document, available from the Android Developers website (http://developer.android.com/tools/devices/index.html).

You must also set the MAF preferences for the locations for the SDK and platform, which are part of the Android SDK package download

To set the MAF preferences for the Android platform SDKs

1. Open the Preferences dialog from the Window menu (Eclipse menu on MacOS) and navigate to Oracle > Mobile Application Framework > Android to open the Android preferences page, as show in Figure 26-3.

   Figure 26-3 Setting Android Preferences

   

2. Click Add to open the Select SDK dialog, and navigate to the location of the Android SDK. Click OK.

The SDK information for Android 4.4.2 (API 19), which is illustrated in Figure 26-4, differs from earlier versions.

Note:

Push notifications require devices and emulators running Android 2.2 platform (or later). The Google Play store must be installed on these devices. The Google API must be installed in the SDK to enable push notifications on emulators. Users must create a Google account (and be logged in) on devices running platforms earlier than 4.0.3 (API 15).

See also GCM Architectural Overview in Google Cloud Messaging for Android, available from the Android Developers website (http://developer.android.com/index.html) and How to Create an Android Deployment Configuration.

To create the configuration

1. Select Run > Run Configurations to open the Configurations dialog.
2. In the Configurations dialog, shown in Figure 26-4, enter a name for the configuration.
3. Select the assembly Project from the list of those available.
4. If you want to change the application ID, enter a new one in Deployed Bundle Id.

   Note:

   To ensure that an application deploys successfully to an Android-powered device or emulator, the ID must begin with a letter, not with a number or a period. For example, an ID comprised of a wholly numeric value, such as 925090 (com.company.925090) will prevent the application from deploying. An ID that begins with letters, such as hello925090 (com.company.hello925090) will enable the deployment to succeed.

5. Select the target, which is combination of the platform version and the MAF runtime version.
6. Select the target configuration, that is, the device or emulator where the application is to be deployed.

   Note:

   Sometimes OEPE cannot detect an Android emulator because the daemon associated with the adb server is not running. When the daemon is not running, OEPE displays an error message:

   Either the target device is not set or the selected device is invalid. Click Refresh if your device doesn't show in the dropdown. If you do not see your device, run the command 'adb devices' to check the status of your device.

   Running adb devices from the SDK/platform-tools directory starts the daemon as below:

   <sdk-install>\adt-bundle-windows-x86_64-20130717\sdk\platform-tools>adb devices
   * daemon not running. starting it now on port 5037 *
   * daemon started successfully *
   List of devices attached
   emulator-5554 device
   

   OEPE will then detect the emulator.

7. Enter the keystore. If necessary, click Select Keystore which opens the Android Keystores page of the Preferences dialog where you can add a keystore. See Defining the Android Signing Options. See also the application publishing information in the Signing Your Applications document, available from the Android Developers website (http://developer.android.com/tools/publishing/app-signing.html).

   Figure 26-4 Setting the Android SDK and Signing Properties

   

   Note:

   To deploy an application to an Android emulator, you must install API 14 or later (that is, Platform 4.0.n)

26.3.1.1 Setting Advanced Options

You can configure advanced settings for the Android platform, such as the minimum SDK API level and the preferred storage locations, or override the default application images using the Advanced Android Options page.

The Advanced Android Options page, shown in Figure 26-4, enables you to do the following:

• Set a number of advanced options, including the minimum SDK API level, the target SDK API level, the version code, source files, class files, zip alignment, and preferred storage location, as shown in Figure 26-5

  Figure 26-5 Setting SDK Levels

  

• Change the default application images, as shown in Figure 26-6.

  Figure 26-6 Setting Application Images

  

26.3.1.2 Setting Deployment Options

Set deployment options using Advanced Options. Use the procedure to set the JDK-Compatibility level for the R.java and .class files.

The Main and Common tabs of the deployment configurations dialog, and the Advanced Android Options dialog, invoked from the Advanced Options button, enable you to set values that are passed in by the javac compiler tool options, and also the Android API revisions.

To set the JDK-Compatibility level for the R.java and .class files:

1. In the deployment configuration dialog, click Options to open the Advanced Options dialog.
2. Select the minimum API Level on which the application is able to run from the Minimum SDK API Level dropdown list. The minimum and default value is 15, which corresponds to Android 4.0.3 platform.
3. Select the intended API Level on which the application is designed to run from the Target SDK API Level dropdown list. The minimum (and default) value is API Level 9, which corresponds to the Android 2.3.n platform. See the description of the <uses-sdk> attribute in the document entitled The AndroidManifest.xml File, available through the Android Developers website (http://developer.android.com/guide/topics/manifest/manifest-intro.html).

26.3.1.3 Defining the Android Signing Options

An application must be signed, or self-signed, and the build mode be specified for it to be deployed to an Android platform. Use the procedures to define release properties for the key that is used to sign the application, and to set the build mode.

An application must be signed before it can be deployed to an Android device or emulator. Android does not require a certificate authority; an application can instead be self-signed.

Before you begin

OEPE creates a keystore if one does not exist. In addition, you can create one using the keytool utility, as illustrated in the following example.

An application must be signed before it can be deployed to an Android device or emulator. Android does not require a certificate authority; an application can instead be self-signed.

Defining how the deployment signs a mobile application is a two-step process: within the MAF Platforms preference page, you first define release properties for a key that is used to sign Android applications. You only need to configure the release signing properties once. After you define these options, you configure the deployment configuration to designate if the application should be deployed in the release mode.

keytool -genkey
        -v
        -keystore c:\oepe\workspace\releasesigning.keystore
        -alias releaseKeyAlias
        -keyalg RSA
        -keysize 2048
        -validity 10000

In this example, the keystore contains a single key, valid for 10,000 days. As described in the Signing Your Applications document, available from the Android Developers website (http://developer.android.com/tools/publishing/app-signing.html), the keytool prompts you to provide passwords for the keystore and key, and to provide the Distinguished Name fields for your key before it generates the keystore. See Java SE Technical Documentation (https://download.oracle.com/javase/index.html) for information on how to use the keytool utility.

To configure the key options:

1. Select Window, Preferences, Oracle, Mobile Application Framework, and then Android Keystore.

2. Click and in the Select Keystore dialog, navigate to the location of the keystore, as shown in Figure 26-7 and click OK.

   Figure 26-7 Selecting the Keystore Location

   

3. Enter the password for the keystore. When you enter a correct password, the Add button is enabled.

4. Click Add to open the Select Key Alias dialog, as shown in Figure 26-8.

   Figure 26-8 Selecting the Key Alias

   

5. Enter the password for the key alias and click OK.

   The keystore and key alias are now available to be used in the deployment configuration dialog.

To set the Android build mode:

1. Do one of the following:

   • From the Run menu, select Debug Configurations. Select Debug for developing and testing an application (such as Java and JavaScript debugging). This option enables you to deploy an application on the Android platform without having to provide a private key. Use this option when deploying an application to an Android emulator or to an Android-powered device for testing. See also How to Enable Debugging of Java Code and JavaScript.

     Note:

     You cannot publish an application signed with the debug keystore and key; this keystore and key are used for testing purposes only and cannot be used to publish an application to users.

   • From the Run menu, select Run Configurations. When the application is ready to be published, select Release. Use this option when the application is ready to be published to an application marketplace, such as Google Play.

2. In the deployment configuration dialog, after the .apk file is signed in either debug or release mode, you can deploy it to a device or to an emulator. At runtime, MAF indicates that an application has been deployed in debug mode by overlaying a debugging symbol that is represented by an exclamation point within a red triangle, as shown in Figure 26-9.

   Figure 26-9 Deployment Modes

   

26.3.1.4 What You May Need to Know About Credential Storage

Eclipse Secure Storage stores credentials for keystore access. Use the procedure to find the secure storage location.

Credentials for keystore access are stored in Eclipse Secure Storage, which stores data outside the workspace. The location is usually in your home directory, although the specific location varies depending on the OS platform.

To find the Secure Storage Location

1. Open the Preferences dialog from the Window menu (Eclipse menu on MacOS) and navigate to General, Security, and Secure Storage to display the Secure Storage page.
2. Click the Contents tab. The storage location is displayed at the bottom of the dialog, for example, user-home/.eclipse/org.elipse.equinox.security/secure_storage.
3. You can see the passwords that are stored by expanding nodes oracle , eclipse, tools, oepe, maf, android, and keystores.

   There is a node for each keystore that is declared in the Oracle > Mobile Application Framework > Android > Android Keystores page of the Preferences dialog.

   Click on the node to show the data (the password is obfuscated).

Note:

Because iOS keys are Mac-specific, there is no need to store them in Eclipse. The iOS XcodeBuild will extract them directly from the Mac Keychain based on the mobileprovision that is specified at launch (configured from the Oracle >Mobile Application Framework > Android > Android Keystores page of the Preferences dialog).

26.3.1.5 How to Add a Custom Image to an Android Application

MAF provides default images to meet the requirement of images in different sizes and resolutions for the distinct display of application icons. Use the procedure to override the default Oracle images.

Enabling MAF application icons to display properly on Android-powered devices of different sizes and resolutions requires low-, medium-, and high-density versions of the same images. MAF provides default Oracle images that fulfill these display requirements. However, if the application requires custom icons, you can use the Application Images page, shown in Figure 26-10, to override default images by selecting PNG-formatted images for the application icon and for the splash screen. For the latter, you can add portrait and landscape images. If you do not add a custom image file, then the default Oracle icon is used instead. To create custom images, refer to the Iconography document, available from the Android Developers website (http://developer.android.com/design/style/iconography.html).

Figure 26-10 Setting Custom Images for an Android Application

Figure 26-10 shows selecting images for application icons and portrait orientation splash screen images that applications use for displaying on devices with low-, medium-, high- and extra-high density displays.

Before you begin

Obtain the images in the PNG, JPEG, or GIF file format that use the dimensions, density, and components that are appropriate to Android theme and that can also support multiple screen types. The default location for images in assembly directory\res\android. See Supporting Multiple Screens document, available from the Android Developers website (http://developer.android.com/guide/practices/screens_support.html).

To add custom images:

1. Click Run > Run Configurations to open the deployment configuration dialog.
2. Click Options to open the Advanced Android Options dialog, and then click the Application Images tab.

   Select the density of the image you want to change, then expand the appropriate node to select the image you want to change.

3. Click Browse to select the new image you want to use and click OK.

26.3.1.6 What Happens When OEPE Deploys Images for Android Applications

Upon deployment, OEPE copies image files to a drawable subdirectory, and renames icon images and splash screen images.

As shown in Table 26-1, each image file is copied to a subdirectory called drawable, named for the drawable object, described on the Android Developers website (http://developer.android.com/reference/android/graphics/drawable/Drawable.html). Each drawable directory matches the image density (ldpi, mdpi, hdpi, and xhdpi) and orientation (port, land). Within these directories, OEPE renames each icon image file as adfmf_icon.png and each splash screen image as adfmf_loading.png.

Note:

In order to view the contents of assembly project\.main.android, you must change the default view of the Project Explorer. See What Happens When You Create an MAF Application.

Table 26-1 Deployment File Locations for Seeded Application Images

Source File (...\res\android)	Temporary Deployment File (...\.main.android\build\release\res)
display-ldpi-icon.png	drawable-ldpi\adfmf_icon.png
display-mdpi-icon.png	drawable-mdpi\adfmf_icon.png
display-hdpi-icon.png	drawable-hdpi\adfmf_icon.png
display-xhdpi-icon.png	drawable-xhdpi\adfmf_icon.png
display-port-ldpi-splashscreen.png	drawable-port-ldpi\adfmf_loading.png
display-port-mdpi-splashscreen.png	drawable-port-mdpi\adfmf_loading.png
display-port-hdpi-splashscreen.png	drawable-port-hdpi\adfmf_loading.png
display-port-xhdpi-splashscreen.png	drawable-port-xhdpi\adfmf_loading.png
display-land-ldpi-splashscreen.png	drawable-land-ldpi\adfmf_loading.png
display-land-mdpi-splashscreen.png	drawable-land-mdpi\adfmf_loading.png
display-land-hdpi-splashscreen.png	drawable-land-hdpi\adfmf_loading.png
display-land-xhdpi-splashscreen.png	drawable-land-xhdpi\adfmf_loading.png

For custom images, OEPE copies the set of application icons from their specified location to the corresponding density and orientation subdirectory of the temporary deployment location.

26.3.2 How to Deploy an Android Application to an Android Emulator

Start an Android emulator, and deploy a MAF application to it. Use the procedure to deploy an application to an Android emulator.

You can deploy the mobile application directly to an Android emulator.

Before you begin

Deployment to an Android emulator requires the following:

• Configure the keystore password and key alias details in the Android Platform preference page (accessed by choosing Window > Preferences > Oracle > Mobile Application Framework > Android > Android Keystore).

  Note:

  You must install the Android 4.0.n platform (API 14 or later).

• Ensure that the Android Virtual Device instance configuration reflects the ARM system image.

• Start the Android emulator before you deploy an application.

  You can start the emulator using the Android Virtual Device Manager, as illustrated in Figure 26-11, or from the command line by first navigating to the tools directory (located in Android\android-sdk) and then starting the emulator by first entering emulator -avd followed by the emulator name (such as -avd AndroidEmulator1).

  Note:

  You can run only one Android emulator at a time.

  Figure 26-11 Starting an Emulator Using Android Virtual Device Manager

  

To deploy an application to an Android emulator:

1. Select either Run, then Run Configurations or Run, then Debug Configurations. Under the MAF Applications node select an Android deployment configuration.
2. Check that the target is the one you want to use, and click either Run or Debug.

   Occasionally the deployment process may hang. In this case, kill the adb server then restart it, and retry the deployment.

3. Review the deployment log in the console, as shown in Figure 26-12. The deployment log notes that the deployer starts the Android Debug Bridge server when it detects a running instance of an Android emulator.

   Figure 26-12 The Deployment Log

   

26.3.3 How to Deploy an Application Locally as an APK File

Configure the signing options for the Android platform, and deploy an application as an .apk file to a local file. Use the procedure to deploy an application for the Android platform to a local file.

You can deploy an application as an .apk file on the local filesystem.

Note:

You must configure the signing options in the Android Platform preference page (accessed by choosing Window > Preferences > Mobile Application Framework) as described in Defining the Android Signing Options.

To deploy an Android application to a local file:

1. Select Run, then Run Configurations to open the Run Configurations dialog. Under the MAF Applications node select an Android deployment configuration.
2. Under Target Configuration, select Generate APK Only and enter a location where the APK file will be generated.
3. click Run
4. Review the deployment log in the console, as shown in Figure 26-12. The deployment log notes the source of the application, and shows the destination.

   Figure 26-13 The Deployment Log

   

26.3.4 How to Deploy an Application to an Android-Powered Device

If the development computer that hosts OEPE is connected to an Android device, and signing credentials have been configured for the Android platform, you can deploy an application to an Android device. Use the procedure to deploy an application to an Android device.

You can deploy a mobile application directly to an Android-powered device that runs on a platform of 2.n (API Level 9) or later.

Before you begin

Connect the device to the development computer that hosts OEPE, as described in How to Set Up an Android-Powered Device.

Ensure that the debug signing credentials are configured in the Android Platform preference page, shown in Figure 26-4.

To deploy an application to an Android device:

1. Select Run, then Run Configurations to open the Run Configurations dialog. Under the MAF Applications node select an Android deployment configuration.

2. Check that the target is the one you want to use, and click Run.

3. Review the deployment log in the console, as shown in Figure 26-12. The deployment log notes that the deployer starts the Android Debug Bridge server when it detects a running instance of an Android emulator.

   Figure 26-14 The Deployment Log

   

1. Select either Run, then Run Configurations or Run, then Debug Configurations. Under the MAF Applications node select an Android deployment configuration.
2. Check that the target is the one you want to use, and click either Run or Debug.

26.3.5 How to Publish an Android Application

Create a Run Configuration, configure the signing options for the Android platform, and publish an application to an application marketplace. Use the procedure to deploy an application as a .apk file.

After you have tested and debugged the application, as described in Testing and Debugging MAF Applications, you can publish it to an application marketplace (such as Google Play) by following the instructions provided on the Android Developers website (http://developer.android.com/tools/publishing/publishing_overview.html).

Before you begin

Create a Run Configuration.

Note:

You must configure the signing options in the Android Platform preference page (accessed by selecting Window > Preferences > Mobile Application Framework) as described in Defining the Android Signing Options.

To deploy an application as an .apk file:

1. Select Run, then Run Configurations to create a run configuration. Under the MAF Applications node select an Android deployment configuration.
2. Check that the target is the one you want to use, and click Run.
3. Review the deployment log in the console.
4. Publish the application to an application marketplace.

26.3.6 What Happens in OEPE When You Create an .apk File

The content in the adfmsrc, the .adf folder, the maf-application.xml and maf-feature.xml files, the logging.properties file, and the JVM 1.4 files are deployed in an .apk file when an application is deployed.

Deploying an application results in the following being deployed in an .apk file.

• The content in the adfmsrc

• The content in the .adf folder

• maf-application.xml and maf-feature.xml files

• logging.properties file

• The JVM 1.4 files

Table 26-2 Contents of the .apk File

Content	Location Within the .apk File
The content in the .adf folder	The root folder of the Android application file ([apkRoot]\.adf)
The content in the adfmsrc folder	The deployment packages the content in the adfmsrc folder into the default JAR file, which is located in a folder called user ([apkRoot]\user). This JAR file is added to the .apk using the Android Asset Packaging Tool (AAPT) and has a default name of the form ANDROID_MOBILE_NATIVE_archiveN where N is the nth Android created profile (you can override this name when creating the profile). This JAR file contains the following: Any .class files generated from .java files that are added to the view controller project, as well as the adfmsrc content. The .java files are compiled using the JVM 1.4 JDK javac tool. Contains data binding and pagedef metadata files. This JAR file is not processed by the Dalvik virtual machine. Because the .class files run in the JDK, they do not need to be converted into the Dalvik bytecode format (.dex).
adfmf_application.xml and adfmf_feature.xml files	Located in a file called Configuration ([apkRoot]\Configuration).
logging.properties file	Located in the root of the application file.
JVM 1.4 files	The JVM files are packaged into two separate folders: The library file (\framework\build\java_res\libs\ ) in the template will be packaged into a lib folder in the APK - [apkRoot]\lib. The \framework\build\java_res\assets\storage file is packaged in the assets\storage directory in the APK - [apkRoot]\assets\storage.

26.3.7 Selecting the Most Recently Used Deployment Configurations

Use the short-cuts that OEPE creates upon an application deployment to redeploy the application reusing an earlier deployment action.

After you select a deployment action, OEPE creates a shortcuts on the Debug and Run buttons on the main toolbar, as shown in Figure 26-15. Click the down-arrow, and select the configuration that enables you to easily redeploy the application using that same deployment action.

Figure 26-15 Choosing a Recently Used Configuration

26.3.8 Viewing the Device/Emulator Log in the Console

In OEPE, the log output from the device or emulator is streamed inside the console, as shown in Figure 26-16. This is very useful for debugging. See How to Configure Logging Using the Properties File.

Figure 26-16 Viewing the Device or Emulator Log

26.4 Deploying an iOS Application

If you are a registered Apple developer, you can deploy a MAF application to the iOS device from an Apple computer. Use the deployment configuration dialog to deploy an application to an iOS simulator or to a device by means of iTunes

The deployment configuration dialog, shown in Figure 26-17, enables you to deploy an iOS application directly to an iOS simulator or to a device through iTunes. You can only deploy an iOS application from an Apple computer. Deployment to the iOS simulator does not require membership to either the iOS Developer Program or the iOS Developer Enterprise Program; registration as an Apple developer, which provides access to versions of Xcode that are not available through the App Store, will suffice. For more information on iOS developer programs, which are required for deployment to iOS-powered devices (and are described at How to Deploy an Application to an iOS-Powered Device, and How to Distribute an iOS Application to the App Store), see https://developer.apple.com/programs/.

Figure 26-17 The Deployment Configuration Dialog (for iOS Applications)

26.4.1 How to Create an iOS Deployment Configuration

Install Xcode on an Apple computer with an installed OEPE, and get a provisioning profile and certification from the iOS Provisioning Profile if the deployment is to an iOS device. Use the procedure to create a deployment configuration.

For iOS, use the Debug Configuration dialog to define the iOS application build configuration as well as the locations for the splash screen images and application icons.

Before you begin

Download Xcode (which includes the Xcode IDE, performance analysis tools, the iOS simulator, the Mac OS X, and the iOS SDKs) to the Apple computer that also runs OEPE.

Tip:

Refer to the Certification and Support Matrix on Oracle Technology Network (http://www.oracle.com/technetwork/developer-tools/maf/documentation/index.html) for the minimum supported version required to compile applications.

Because Xcode is used during deployment, you must install it on the Apple computer before you deploy the mobile application from OEPE.

Tip:

While the current version of Xcode is available through the App Store, you can download prior versions through the following site:

https://developer.apple.com/xcode/

Access to this site requires an Apple ID and registration as an Apple developer.

After you download Xcode, you must enter the location of its xcodebuild tool and, for deployment to iOS simulators, the location of the SDK of the iOS simulator, on the iOS Platform preference page. See How to Deploy an iOS Application to an iOS Simulator.

Note:

Run both iTunes and the iOS simulator at least once before entering their locations in the iOS Platform preference page.

To deploy a mobile application to an iOS-powered device (as opposed to deployment to an iOS simulator), you must obtain both a provisioning profile and a certification from the iOS Provisioning Profile as described in Setting the Device Signing Options.

To create a deployment configuration:

1. Select Run, and then Debug Configurations, as shown in Figure 26-18.

   Figure 26-18 Setting the iOS Options

   
2. Accept the default values, or define the following:

   • Assembly Project—Select from the list of those available.

   • Deployed Bundle Id—If needed, enter a Bundle Id to use for this application that identifies the domain name of the company. The deployed bundle Id must be unique for each application installed on an iOS device and must adhere to reverse-package style naming conventions (that is, com.<organization name>.<company name>). See the App Distribution Guide, which is available through the iOS Developer Library at http://developer.apple.com/library/ios/navigation/). For information on obtaining the Bundle Seed Id using the iOS Provisioning Portal, see Registering an Application ID. See also Setting Display Properties for a MAF Application.

     Note:

     The deployed bundle Id cannot contain spaces.

     Because each deployed bundle Id is unique, you can deploy multiple mobile applications to the same device. Two applications can even have the same name as long as their deployed bundle Ids are different. Mobile applications deployed to the same device are in their own respective sandboxes. They are unaware of each other and do not share data (they have only the Device scope in common).

   • Target—Select from the list of targets configured in the Preferences dialog, or click Target to add a new target.

   • Target Configuration

     • iOS Deploy Target—Select device or simulator.

     • iOS Simulator Version—When you select Simulator as the deploy target, select the version of the emulator to which you are deploying the application. To find the available target versions, select Hardware and then Version on an iPhone simulator. The minimum version is 6.0. The default setting is <Highest Available>. For more information, see the iOS Simulator User Guide, which is available through the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

       Note:

       Older versions of the iOS target version are usually available in the simulator for testing.

     • Select Mobile Provisioning Profile—

     • iOS Distribution Package (ipa)—If needed, enter the name for the .ipa file or the .app file. MAF creates an .ipa file when you select either the Deploy to distribution package or Deploy to iTunes for synchronization to device options in the Deployment Action dialog, shown in Figure 26-17. It creates an .app file when you select the Deploy application to simulator option. Otherwise, accept the default name. For more information, see How to Deploy an Application to an iOS-Powered Device and How to Distribute an iOS Application to the App Store.

       By default, MAF bases the name of the .ipa file (or .app file) on the application id attribute configured in the maf-application.xml file. For more information, see Setting Display Properties for a MAF Application.

     • Advanced Options—Click Options to open the Advanced Option dialog, where you can set various options, as shown in Figure 26-19.

       Figure 26-19 Setting the Minimum iOS Version

       

       Minimum iOS Version—Indicates the earliest version of iOS to which you can deploy the application. The default value is the current version. The version depends on the version of the installed SDK.

     • Target Family—Select the family of iOS products on which the application is intended to run. The default option is for both iPad and iPhone.

     • Advanced Build Options—Specify additional arguments that Xcode can use when it builds the MAF application.

     • Push Notification – Select Production if your deployed application is to use production Apple Push Notification service (APNs) servers or Development if it is to use development APNs servers. MAF ignores the value of Push Notification Environment if you do not select the PushPlugin plugin to enable push notifications, as described in Enabling Push Notifications.

     • Disable ATS—App Transport Security (ATS) is a security policy that restricts network requests from the application to use only approved secured transport protocols. MAF enables ATS by default. Select Disable Application Transport Security to deploy your MAF application without ATS enabled.

26.4.2 Setting the Device Signing Options

Set the location of the provisioning profile on the development computer and the name of the certificate. Use the procedure to set the device signing options.

The iOS Platform preference page for iOS includes fields for the location of the provisioning profile on the development computer and the name of the certificate. You must define these parameters if you deploy an application to an iOS device or as a MAF Application Archive.

Note:

Neither a certificate nor a provisioning profile are required if you deploy a mobile application to an iOS simulator.

To set the signing options:

1. Select Window, then Preferences, and then Mobile Application Framework.
2. Select iOS and then select iOS Mobile Provisions.
3. In the Mobile Provision Info section of the page, shown in Figure 26-20, enter the location of the provisioning profile in Mobile Provisioning File.
4. In theTeam field, enter the identifier of your team. MAF automatically populates this input field with a value that it extracts from the provisioning profile that you select in Step 3.
5. OEPE enters the Certificate.

   Figure 26-20 The Device Signing Section of the iOS Platform Preference Page

   

Note:

There are provisioning profiles used for both development and release versions of an application. While a provisioning profile used for the release version of an application can be installed on any device, a provisioning profile for a development version can only be installed on the devices whose IDs are embedded into the profile. See App Distribution Guide, which is available from the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

26.4.3 How to Restrict the Display to a Specific Device Orientation

MAF supports all device orientations for iPhone and iPad. Use the procedure to restrict the display of an application to a specific device orientation

By default, MAF supports all orientations for both iPhone and iPad. If, for example, an application must display only in portrait and in upside-down orientations on iPads, you can limit the application to rotate only to these orientations using the Device Orientation page, shown in Figure 26-21

Figure 26-21 Select a Device Orientation

To limit the display of an application to a specific device orientation

1. Select Device Orientations, as shown in Figure 26-21.
2. Clear all unneeded orientations from among those listed in Table 26-3. By default, MAF deploys to all of these device orientations. By default, all of these orientations are selected.

   Table 26-3 iPhone Device Orientations

   Icon	Description
   	iPad, portrait—The home button is at the bottom of the screen.
   	iPad, upside-down—The home button is at the top of the screen.
   	iPad, landscape left—The home button is at the left side of the screen.
   	iPad, landscape right—The home button is at the right side of the screen.
   	iPhone, portrait—The home button is at the bottom of the screen.
   	iPhone, upside-down—The home button is at the top of the screen.
   	iPhone, landscape left—The home button is at the left side of the screen.
   	iPhone, landscape right—The home button is at the right side of the screen.

3. Click OK.

26.4.4 What Happens When You Deselect Device Orientations

Deselecting a device orientation updates the source .plist file.

26.4.5 Using Images with iOS Applications

Applications deployed to an iOS device by means of iTunes, or deployed as an archive for download, use the default Oracle image. Rebrand an application by overriding the default Oracle image used for application icons and artwork with custom images, or use an image to differentiate between versions of an application.

By default, mobile applications deployed to an iOS device through iTunes, or deployed as an archive (.ipa file) for download, use the default Oracle image unless otherwise specified.

By selecting an iTunes artwork image as the icon for the deployed application, you override the default image. You can use an image to differentiate between versions of the application. Figure 26-22 illustrates the difference between the default image and a user-selected image, where Application4 is displayed with the default image and Application6 is displayed with a user-selected image (the Oracle icon, scaled to 512 x 512 pixels).

During deployment, MAF ensures that the icon displays in iTunes by adding the iTunes artwork image to the top-level of the .ipa file in a file called iTunesArtwork.

Figure 26-22 Custom and Default Application Icons

For more information on iOS application icon images, see Icon and Image Design in iOS Human Interface Guidelines. This document is available from the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

You can rebrand an application by overriding the default Oracle image used for application icons and artwork with custom images. There are three ways you can use your own custom images in an application:

• The simplest way is to override the default Oracle image as part of the Run/Debug Configuration, see Overriding the Default Oracle Images in the Configuration.

• You can overwrite the default file for each custom image with your own. see Replacing the Default Images..

• You can copy your custom icons to the same folder as the default icons and modify the properties file for the device profile for each image, see Add Custom Images.

Note:

All images must be in the PNG format.

For each application, there is an image folder which contains the image files and a properties file which maps predefined keys to a specific image in that folder.

• The images folder is application/res/ios.

• The properties file is in the same folder, ios-resources.properties.

The properties file configures how custom images are deployed, for example:

# iPad (76 x 76 px)
# Appears on home screen on iPad (later than iOS 6.1)
# deploys to Icon-76.png
oepe.adfmf.res.source.icon76=Icon-76.png
 
# iPad (152 x 152 px)
# Appears on home screen on iPad with retina display (later than iOS 6.1)
# deploys to [e-mail]
oepe.adfmf.res.source.icon76@2x=[e-mail]
 
# All devices  (40 x 40 px)
# Spotlight on all devices (later than iOS 6.1)
# deploys to Icon-40.png
oepe.adfmf.res.source.icon40=Icon-40.png

26.4.5.1 Overriding the Default Oracle Images in the Configuration

By defining the locations of custom images used for different situations and device resolutions on the Application Images page, you can override default images with custom images. Use the procedure to override the default images, and rebrand an application.

The Application Images page enables you to rebrand an application by overriding the default Oracle image used for application icons and artwork with custom images. The options in this page, shown in Figure 26-23, enable you to enter the locations of custom images used for different situations, and device resolutions.

Note:

When you change an icon it is changed for all the devices the icon is used for.

Figure 26-23 Overriding the Default Images

To override the default images:

1. Open the deployment configuration by selecting Run > Debug Configurations.
2. Click Options to open the Advanced iOS Options dialog.
3. Click the Application Images tab, and select whether you want to change the image for iPhone or iPod.
4. Select the image you want to change, and Browse to select the image file you want to use. This image file must exist within the current application.

   During deployment, OEPE copies the custom image file into the deployment configuration and renames it to match the name of the default image.

5. Click OK.

26.4.5.2 Replacing the Default Images

You can overwrite default images to rebrand an application. Use the procedure to replace default images with custom images.

If you are happy to overwrite the default images, you can overwrite them in the image directory with your own custom images.

To overwrite images:

1. Navigate to the folder containing the images for your application, application/res/ios.
2. Identify the images you want to replace and check the size of the image and where it is used in the properties file in the same folder, ios-resources.properties.
3. Replace the default images with your custom images.

26.4.5.3 Add Custom Images

To replace default images with custom images in an application, the custom images must be added to the folder with application images.

You can add your custom images to the folder containing the images for your application, and edit the properties file to modify each key/value pair to match the device profile for each image.

To add custom images:

1. Add the custom images to the folder containing the images for your application, application/res/ios.

   For example, if you have a custom 57x57 pixel image for iPhone called myicon.png, add it to this folder.

2. Open the properties file in the same folder, ios-resources.properties and edit it to add your custom icon.

   For example, to be able to use myicon.png, change the key as follows:

   oepe.adfmf.res.source.icon57@2x=myicon.png
   

26.4.6 How to Deploy an iOS Application to an iOS Simulator

The Deployment Actions dialog can be used to deploy an application to an iOS simulator. Use the procedure to deploy an application to an iOS simulator.

The Deployment Actions dialog enables you to deploy an iOS application directly to an iOS simulator.

Before you begin

To enable deployment to an iOS simulator, you must perform the following tasks:

To deploy an application to an iOS simulator:

1. Select Run, and then Run Configurations to open the Run Configurations dialog, as shown in Figure 26-24.

   Figure 26-24 Run Configurations Dialog

   
2. Accept the default values, or define the following:

   • Assembly Project—Select from the list of those available.

   • Deployed Bundle Id—If needed, enter a Bundle Id to use for this application that identifies the domain name of the company. The deployed bundle Id must be unique for each application installed on an iOS device and must adhere to reverse-package style naming conventions (that is, com.<organization name>.<company name>). See App Distribution Guide, which is available through the iOS Developer Library at http://developer.apple.com/library/ios/navigation/). For information on obtaining the Bundle Seed Id using the iOS Provisioning Portal, see Registering an Application ID. See also Setting Display Properties for a MAF Application.

     Note:

     The deployed bundle Id cannot contain spaces.

     Because each deployed bundle Id is unique, you can deploy multiple mobile applications to the same device. Two applications can even have the same name as long as their deployed bundle Ids are different. Mobile applications deployed to the same device are in their own respective sandboxes. They are unaware of each other and do not share data (they have only the Device scope in common).

   • Target—Select from the list of targets configured in the Preferences dialog, or click Target to add a new target.

   • Target Configuration

     • iOS Deploy Target—Select Simulator.

     • iOS Simulator Version—Select the version of the emulator to which you are deploying the application. To find the available target versions, select Hardware and then Version on an iPhone simulator. The minimum version is 6.0. The default setting is <Highest Available>. See iOS Simulator User Guide, which is available through the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

       Note:

       Older versions of the iOS target version are usually available in the simulator for testing.

     • Enable Quick Deploy—Select to have OEPE automatically redeploy an application to an iOS simulator after a build. See Using Quick Deploy.

     • Select Mobile Provisioning Profile—

     • iOS Distribution Package (ipa)—If needed, enter the name for the .app file. MAF creates an .app file when you select the Deploy application to simulator option. Otherwise, accept the default name.

       By default, MAF bases the name of the .ipa file on the application id attribute configured in the maf-application.xml file. See Setting Display Properties for a MAF Application.

     • Advanced Options—Click Options to open the Advanced Option dialog, where you can set various options.

       Minimum iOS Version—Indicates the earliest version of iOS to which you can deploy the application. The default value is the current version. The version depends on the version of the installed SDK.

26.4.6.1 Using Quick Deploy

OEPE automatically redeploys an application to an iOS simulator after a build. Use the procedure to set the minimum quick deploy delay so that a time lapse separates redeployments.

OEPE can automatically redeploy an application to an iOS simulator. It does this by keeping track of the changes that you make in the application and then redeploying after a build.

The updates occur when the application builds, and not when resources change. If you do not have automatic builds set, then you should select Save automatically before build in the General > Workspace page of the Preferences dialog so that all resources are committed before building and redeploying.

There is a delay of a few seconds before the application restarts so that the application is not redeployed on every build if builds are close together. The default is 6 seconds, but you can change this in OEPE preferences. If you find that the application is restarting too often, you can change the minimum time before quick deploy.

To change the minimum quick deploy delay:

1. Open the Preferences dialog from the Window menu (Eclipse menu on MacOS) and navigate to Oracle > Mobile Application Framework > Launch to open the Launch preferences page, as show in Figure 26-25.

   Figure 26-25 Quick Deploy Delay

   
2. Enter the number of seconds between 3 and 120 before an application should be redeployed when Quick Deploy has been set. The default is 6 seconds.

26.4.7 How to Deploy an Application to an iOS-Powered Device

After an initial, indirect deployment from the Applications folder in Apple iTunes, an application can be deployed to an iOS-powered device for debugging or testing using the Deploy to iTunes for Synchronization to device option.

The Deploy to iTunes for Synchronization to device option enables you to deploy a mobile application to an iOS-powered device for debugging and testing. Deployment to an iOS-powered device or to a distribution site requires membership to either the iOS Developer Program or the iOS Developer Enterprise Program. See https://developer.apple.com/programs/.

Before you begin

You cannot deploy an application directly from OEPE to a iOS device; an application must instead be deployed from the Applications folder in Apple iTunes. To accomplish this, you must perform the following tasks:

• Download Apple iTunes to your development computer and run it at least once to create the needed folders and directories.

• Set the location of the Automatically Add to iTunes folder (the location used for application deployment) in the iOS Platform preference page, shown in Figure 26-26.

  Tip:

  Although your user home directory (/User/<username>/Music/iTunes/iTunes Media/Automatically Add to iTunes.localized) is the default directory for the iTunes Media folder, you can change the location of this folder as follows:

  1. In iTunes, select Edit, Preferences, then Advanced.

  2. Click Change and then browse to the new location.

  3. Consolidate the library.

  4. Delete the original iTunes Media folder.

  For instructions, refer to Apple Support (http://support.apple.com).

  You must also update the location in the iOS Platform preference page.

• Set the location of the Xcode folder where the xcodebuild tool is invoked, such as /Developer/usr/bin in Figure 26-26.

  Figure 26-26 Setting the Locations for the iTunes Media Folder and the xcodebuild System

  

• Enter the name of the certificate and the location of the provisioning profile in the iOS Platform preference page. The OS Provisioning Portal generates the certificate and provisioning profile needed for deployment to iOS devices, or for publishing .ipa files to the App Store or to an internal download site.

  Note:

  The deployment will fail unless you set the iOS provisioning profile and certificate to deploy to a device or to an archive. MAF logs applications that fail to deploy under such circumstances. For more information, see What You May Need to Know About Deploying an Application to an iOS-Powered Device.

• In the iOS Options page of the deployment configuration, select Run as the build mode and then OK.

• See App Distribution Guide, which is available through the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

To deploy an application to an iOS-powered device:

1. Select Run > Debug Configurations, as shown in Figure 26-18.

   Figure 26-27 Setting the iOS Options

   

2. Accept the default values, or define the following:

   • Assembly Project—Select from the list of those available.

   • Deployed Bundle Id—If needed, enter a Bundle Id to use for this application that identifies the domain name of the company. The deployed bundle Id must be unique for each application installed on an iOS device and must adhere to reverse-package style naming conventions (that is, com.<organization name>.<company name>). See App Distribution Guide, which is available through the iOS Developer Library at http://developer.apple.com/library/ios/navigation/). For information on obtaining the Bundle Seed Id using the iOS Provisioning Portal, see Registering an Application ID. See also Setting Display Properties for a MAF Application.

     Note:

     The deployed bundle Id cannot contain spaces.

     Because each deployed bundle Id is unique, you can deploy multiple mobile applications to the same device. Two applications can even have the same name as long as their deployed bundle Ids are different. Mobile applications deployed to the same device are in their own respective sandboxes. They are unaware of each other and do not share data (they have only the Device scope in common).

   • Target—Select from the list of targets configured in the Preferences dialog, or click Target to add a new target.

   • Target Configuration

     • iOS Deploy Target—Select device or simulator.

     • iOS Simulator Version—When you select Simulator as the deploy target, select the version of the emulator to which you are deploying the application. To find the available target versions, select Hardware and then Version on an iPhone simulator. The minimum version is 6.0. The default setting is <Highest Available>. See iOS Simulator User Guide, which is available through the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

       Note:

       Older versions of the iOS target version are usually available in the simulator for testing.

     • Select Mobile Provisioning Profile—

     • iOS Distribution Package (ipa)—If needed, enter the name for the .ipa file or the .app file. MAF creates an .ipa file when you select either the Deploy to distribution package or Deploy to iTunes for synchronization to device options in the Deployment Action dialog, shown in Figure 26-17. It creates an .app file when you select the Deploy application to simulator option. Otherwise, accept the default name. See How to Deploy an Application to an iOS-Powered Device and How to Distribute an iOS Application to the App Store.

       By default, MAF bases the name of the .ipa file (or .app file) on the application id attribute configured in the maf-application.xml file. See Setting Display Properties for a MAF Application.

     • Advanced Options—Click Options to open the Advanced Option dialog, where you can set various options, as shown in Figure 26-19.

       Figure 26-28 Setting the Minimum iOS Version

       

       Minimum iOS Version—Indicates the earliest version of iOS to which you can deploy the application. The default value is the current version. The version depends on the version of the installed SDK.

26.4.8 What Happens When You Deploy an Application to an iOS Device

The application appears in the iTunes Apps Folder, similar to the one illustrated in Figure 26-22 after a successful deployment.

26.4.9 What You May Need to Know About Deploying an Application to an iOS-Powered Device

A provisioning profile must be created using the iOS Provisioning Portal before an application can be deployed to an iOS-powered device.

You cannot deploy an iOS application (that is, an .ipa file) to an iOS-powered device or publish it to either the App Store or to an internal hosted download site without first creating a provisioning profile using the iOS Provisioning Portal, which is accessible only to members of the iOS Developer Program. You enter the location of the provisioning profile and the name of the certificate in the Options page as described in Setting the Device Signing Options.

As noted in the App Distribution Guide (which is available through the iOS Developer Library at http://developer.apple.com/library/ios/navigation/), a provisioning profile associates development certificates, devices, and an application ID. The iOS Provisioning Portal enables you to create these entities as well as the provisioning profile.

Tip:

After you download the provisioning profile, double-click this file to add it to your Library/MobileDevice/Provisioning Profile directory.

Figure 26-29 The iOS Provisioning Portal

26.4.9.1 Creating iOS Development Certificates

Download and install an iOS Development Certificate so that you can sign the applications for deployment. Use the Certificates page in the iOS Provisioning Portal to log the request for a certificate.

A certificate is an electronic document that combines information about a developer's identity with a public key and private key. After you download a certificate, you essentially install your identity into the development computer, as the iOS Development Certificate identifies you as an iOS developer and enables the signing of the application for deployment. In the iOS operating environment, all certificates are managed by the Keychain.

Using the Certificates page in the iOS Provisioning Portal, you log a CSR (Certificate Signing Request). The iOS Provisioning Portal issues the iOS Development Certificate after you complete the CSR.

26.4.9.2 Registering an Apple Device for Testing and Debugging

Add the iOS device for application deployment to the Current Available Devices list on the Devices page of the iOS Provisioning Portal so that you can deploy applications to the device.

After you install a certificate on your development computer, review the Current Available Devices tab (located in the Devices page of the iOS Provisioning Portal) to identify the Apple devices used by you (or your company) for testing or debugging. The application cannot deploy unless the device is included in this list, which identifies each device by its serial number-like Unique Device Identifier (UDID).

26.4.9.3 Registering an Application ID

An application ID does not share files or the Keychain with any other application, and uniquely identifies an application on a device.

An application ID is a unique identifier for an application on a device. An application ID is comprised of the administrator-created reverse domain name called a Bundle Identifier in the format described in Setting Display Properties for a MAF Application prefixed by a ten-character alpha-numeric string called a bundle seed, which is generated by Apple. Figure 26-30 illustrates an application ID that is unique, one that does not share files or the Keychain with any other applications.

Figure 26-30 An Explicit Application ID

Using a wildcard character (*) for the application name, such as 8E549T7128.com.oracle.*, enables a suite of applications to share an application ID. For example, if the administrator names com.oracle.MAF.* on the iOS Provisioning Portal, it enables you to specify different applications (com.oracle.MAF.application1 and com.oracle.MAF.application2).

Note:

For applications that receive push notifications, the application ID must be a full, unique ID, not a wildcard character; applications identified using wildcards cannot receive push notifications. See Provisioning and Development in Local and Push Notification Programming Guide, available from the iOS Developer Library (http://developer.apple.com/library/ios/navigation/)

When applications share the same prefix, such as 8E549T7128, they can share files or Keychains.

Note:

The Bundle Id must match the application ID set in the Options page of the deployment configuration.

26.4.10 How to Distribute an iOS Application to the App Store

If predeployment requirements are met, the.ipa file of an application can be submitted to iTunes Connect, and then published to the App Store.

After you test and debug an application on an iOS device, you can distribute the application to a wider audience through the App Store or an internal download site. To publish an application to the App Store, you must submit the .ipa file to iTunes Connect, which enables you to add .ipa files to iTunes, as well as update applications and create test users.

Before you begin

Before you distribute the application, you must perform the following tasks:

• In the iOS Platform preference page, shown in Figure 26-26, enter the location of the Automatically Add to iTunes directory.

  Tip:

  Run iTunes at least once before entering this location. See also How to Deploy an Application to an iOS-Powered Device.

• Test the application on an actual iOS device. See How to Deploy an Application to an iOS-Powered Device.

• Obtain a distribution certificate through the iOS Provisioning Portal.

  Note:

  Only the Team Agent can create a distribution certificate.

• Obtain an iTunes Connect account for distributing the .ipa file to iTunes. See Prepare App Submission in the App Store Resource Center in the iOS Development Center. Specifically, review the App Store Review Guidelines to ensure acceptance by the App Review Team.

• You may want to review both the and iTunes Connect Developer Guide. These guides are both available through the iOS Developer Library (http://developer.apple.com/library/ios/navigation/).

• In the iOS Options page of the deployment configuration, select Release as the build mode and then click OK.

To distribute an iOS application to the App Store:

1. Select Run > Run Configurations, and then select an iOS deployment configuration.
2. Select Deploy to Distribution Package.
3. Review the Summary page, which displays the following values. Click Finish.

   • Deployed Bundle Id—The unique name that includes a Java language-like package name (com.<organization name>.<application name>) prefixed with the Bundle Seed that is generated from the iOS Provisioning Portal.

   • File—The file name of the final image deployed to an iOS target.

   • Certificate—The author of the application. If this value has not been configured in the iOS Platform preference page of the deployment configuration, then the Summary page displays <Not Specified>.

   • Provisioning Profile—The name of the provisioning profile that associates one or more development certificates and devices with an application ID. If this value is not configured in the iOS Platform preference page, then the Summary page displays <Not Specified>.

   Note:

   The Certificate and Provisioning Profile values cannot be noted as <Not Specified>; you must specify these values in the Options page to enable the .ipa file to be accepted by iTunes.

4. Log in to iTunes Connect.
5. Submit the .ipa file to iTunes Connect for consideration using the Manage Your Applications module and the Application Loader described in Adding New Apps and Using Application Loader in iTunes Connect Developer Guide.
6. After the application has been approved, see Creating Test Users in iTunes Connect Developer Guide for information on using the Manage Users module. For testing multi-language applications, create a test user account for the regions for which the application is localized.
7. See Editing and Updating App Information in iTunes Connect Developer Guide for information on updating the binary using the Managing Your Application module.

26.5 Deploying a MAF Application to the Universal Windows Platform

MAF applications can either be deployed in the release or the debug mode to the local development computer or to an installation package.

MAF applications can be deployed to the local machine where you develop the application or to an installation package that you use to install the application on a supported UWP device.

MAF provides two build modes for an application that you deploy to the UWP. Use debug mode to test and debug your application as you go through the development cycle. Use release mode to deploy an application that is release ready.

Figure 26-31 Deployment Configuration Dialog for UWP Applications

26.5.1 How to Create a Deployment Configuration for Universal Windows Platform

Define the UWP application build configuration, and specify the locations for application images. Complete the setup and configuration tasks, and then use the procedures to set the MAF preferences for the UWP platform SDKs and to create the deployment configuration.

For UWP, use the Debug Configuration dialog to define the UWP application build configuration as well as the locations for the splash screen images and application icons.

Release ready applications cannot be published to the Windows Store. Select another mechanism to distribute your application. MAF provides a PowerShell script in the installation package that, when executed, installs the application on the UWP device.

Perform the following setup and configuration tasks before you attempt to deploy an application to the UWP:

1. Verify that your development machine meets the requirements to deploy a MAF application to the UWP. Among these requirements are that your machine be a UWP device. That is, it runs the Windows 10 operating system. You must enable Developer mode on this machine.

   See the What You Need to Develop an Application for the Universal Windows Platform section in Installing Oracle Enterprise Pack.

2. Install the Visual Studio software from Microsoft. This software contains the Windows SDK that enables deployment to the UWP.

   See the Setting Up Development Tools for the Universal Windows Platform section in Installing Installing Oracle Enterprise Pack.

3. Create a certificate (a personal information exchange file) to digitally sign the application you want to deploy.

   See How to Create a PFX File for MAF Applications in Installing Oracle Enterprise Pack.

4. Enter the following values in the Windows page of the Preferences dialog shown in Figure 26-32:

   • The location of the Windows SDK that is installed with the Visual Studio software from Microsoft.

   • (On the Windows Certificate page) The location and password (if required) for the certificate that you use to sign the application. Do this in both the Debug and Release tabs if you intend to deploy your MAF application in both modes.

   You access the Preferences dialog from the Window menu (Eclipse menu on MacOS), as shown in Figure 26-32.

Before you deploy your application, note the following issues that can prevent deployment:

• Microsoft Windows imposes a maximum length for the path to directories and files. MAF application deployment fails if the path for a MAF application exceeds the maximum path length. To work around this issue, place the MAF application in a location where the directory path length is less than the maximum length mandated by Windows. For information about the maximum path length limitation, see Microsoft documentation.

• Ensure no other process uses the data folder of the MAF application before you deploy the MAF application using the Deploy application to local machine option. The application data folder is typically located at C:\Users\[userName]\AppData\Local\Packages\[appBundleId]_[id]. An example of a scenario where another process uses this folder is if you have a file in the folder open with an application, such as Notepad. If you cannot determine what application process is using the directory/file(s), reboot your machine to resolve the issue.

• When an application, which uses the Contacts plugin, is deployed to the UWP, ensure that the Contacts plugin is listed first in the list of plugins in the maf-plugins.xml file.

For information about how to debug an application that you deploy in debug mode, see How to Debug Java Code on the Universal Windows Platform.

To set the MAF preferences for the UWP platform SDKs:

1. Open the Preferences dialog from the Window menu (Eclipse menu on MacOS).

2. Navigate to Oracle > Mobile Application Framework > Windows to open the Windows preferences page, as show in Figure 26-32.

   Figure 26-32 Setting UWP Preferences

   

3. Click Add to open the Select SDK dialog, and navigate to the location of the UWP SDK. Click OK.

To create the configuration:

1. Select Run > Run Configurations to open the Configurations dialog.
2. In the Configurations dialog, shown in Figure 26-31, enter a name for the configuration.
3. Select the Assembly Project from the list of those available.
4. If you want to change the application ID, enter a new one in Deployed Bundle Id.
5. Select the target, which is combination of the platform version and the MAF runtime version.
6. Build Package Only

   • Leave unselected if you want to deploy to the local machine.

   • Select if you want to build a package to deploy to other machines or tablets.

26.5.2 Defining the Windows Platform Signing Options

Deployment to the Windows platforms requires the signing of the application. Use the procedure to specify the location of the .pfx file that is needed to sign the application.

An application must be signed before it can be deployed to a Windows device and you do this by providing the location of a Windows Personal Information Exchange (.pfx) file.

See How to Create a PFX File for MAF Applications in Installing Oracle Enterprise Pack.

To specify the location of the .pfx file:

1. Open the Preferences dialog from the Window menu (Eclipse menu on MacOS) and navigate to Oracle > Mobile Application Framework > Windows > Windows Certificate.
2. Enter the certificate location and, if necessary, a password.

26.5.3 How to Deploy a MAF Application to the Universal Windows Platform

Deploy a MAF application to UWP in the Run or Debug mode using a MAF for Windows deployment configuration.

Deploy the application using a MAF for Windows deployment configuration that deploys the application to the UWP.

To deploy a MAF application to the UWP:

1. (On the Windows Certificate page) The location and password (if required) for the certificate that you use to sign the application. Do this in both the Debug and Release tabs if you intend to deploy your MAF application in both modes.
2. Check that the target is the one you want to use, and click either Run or Debug.
3. Review the deployment log in the console.

26.5.4 What Happens When You Deploy a MAF Application to the Universal Windows Platform

An application that has been deployed appears in the installed applications list on the Apps & features page on the Windows 10 computer. You can uninstall an application from the list.

MAF deploys the application to the machine that you are using and installs the application there. In the foreground of Figure 26-33 is an instance of the WorkBetter sample application that has been deployed to a local machine in release mode. In the background of Figure 26-33, you can view the WorkBetter sample application listed among the installed applications on the Apps & features page of the Windows 10 computer.

A red icon appears in the upper-left of a MAF application screen that you deploy in debug mode to indicate that the application is in debug mode. As with the application deployed in release mode, you can view and uninstall this application in the Apps & features page of the Windows 10 computer.

Figure 26-33 MAF Application Deployed in Release Mode on Windows Local Machine

26.5.5 How to Deploy an Application Locally as a Package

An application can be deployed to the local computer, and it can also be locally deployed as a package. Use the procedure to deploy the application as a package.

The default deployment launch configuration setting will always deploy application to the local machine. But there is also a way to deploy to other UWP compatible machines and tablets. For this you must change launch configuration to build a package, as described in What Happens When You Deploy Locally as a Package.

To deploy as a package:

1. Select either Run, then Run Configurations or Run, then Debug Configurations. Under the MAF Applications node, select a UWP deployment configuration.
2. Select Build Package Only and enter a location for the generated package.

26.5.6 What Happens When You Deploy Locally as a Package

The application package is ready for distribution to users who can install the application using a PowerShell script.

The package is generated to the location in the deployment configuration. The directory contains another directory (MafTemplate_*_Test). Distribute the contents of this latter directory to the users with supported UWP devices who want to install your MAF application. The directory includes a PowerShell script (Add-AppDevPackage.ps1) that end users execute to install the application. In addition to the script, the directory contains the application package, dependent packages, and the certificate that signed the application. The following example lists the contents:

Add-AppDevPackage.ps1
Add-AppDevPackage.resources
Dependencies
MafTemplate_1.0.0.0_x64.appx
MafTemplate_1.0.0.0_x64.appxsym
MafTemplate_1.0.0.0_x64.cer

The name of the MafTemplate_*_Test directory and files depends on the Version number and Build mode that you specify in the deployment configuration.

For example, if you specify 2 as the Version number and select the Debug build mode, the directory name is MafTemplate_2.0.0.0_x64_Debug_Test. A version number of 3 and the Release build mode produces a MafTemplate_3.0.0.0_x64_Test directory.

26.6 Deploying Feature Archive Files (FARs)

Application features are bundled into an archive known as a Feature Archive for re-use by MAF view controller projects.

To enable re-use by MAF view controller projects, application features— typically, those implemented as MAF AMX or Local HTML— are bundled into an archive known as a Feature Archive (FAR). A FAR is a JAR file that contains the application feature artifacts that can be consumed by mobile applications. A FAR may contain Java classes, though these classes must be compiled. The example below illustrates the contents of a FAR, which includes a single maf-feature.xml file and a connections.xml file.

connections.xml (or some form of connection metadata)
 
  META-INF
     jar-connections.xml
     jar-adf-config.xml
     adfm.xml
     maf-feature.xml
     MANIFEST.MF
     task-flow-registry.xml
 
  oracle
    application1
      mobile
        DataControls.dcx
         DataBindings.cpx
         pageDefs
           view1PageDefs
 
  model
     Class1.class
 
  public_html
     adfc-mobile-config.xml
       index.html
       navbar-icon.html
       springboard-icon.html
     view1.amx
     task-flow-definition.xml 

Working with Feature Archive files involves the following tasks:

1. Creating a Feature Archive file—You create a Feature Archive by exporting the view project as a FAR.

2. Using the Feature Archive file when creating a mobile application—This includes registering a FAR with the application, and then registering the features in the FAR with the application.

3. Deploying a mobile application that includes features from FARs—This includes unpacking the FAR to a uniquely named folder within the deployment template.

   Note:

   MAF generates FARs during the deployment process. You only need to deploy a view project if you use the FAR in another application.

26.6.1 How to Create a Mobile Feature Archive File

Create the connections required for application reuse. Use the procedure to package mobile features as a Feature Archive File.

Use the OEPE Export wizard to create the .far file.

Before you begin

Create the appropriate connections for the application. Because FARs may be used in different MAF applications with different connection requirements, select a connection name that represents the connection source or the actual standardized connection name.

How to package mobile features as a Feature Archive File:

1. Click File then select Export.
2. In the Export wizard, expand Oracle, then Mobile Application Framework, and select Mobile Feature Archive (FAR), as shown in Figure 26-34.

   Figure 26-34 Creating a Mobile Feature Archive File

   
3. Click Next, and choose the view project containing the features you want to archive, and enter a name for the archive file, as shown in Figure 26-35.

   Note:

   Name the profile appropriately. Otherwise, you may encounter problems if you upload more than one application feature with the same archive name.

   Figure 26-35 Entering a Name and Path for the Mobile Feature Archive File

   
4. Click Finish. The Summary page, shown in Figure 26-36, displays the full path of where the Feature Archive file's JAR path is deployed.

26.6.2 How to Deploy the Feature Archive

MAF provides the Deploy to feature archive JAR file option so that you can deploy a FAR as a JAR file. Use the procedure to deploy the Feature Archive deployment profile.

The Deployment Actions dialog enables you to deploy the FAR as a JAR file. This dialog includes only one deployment option, Deploy to feature archive JAR file.

How to deploy the Feature Archive deployment profile:

1. Right-click the view project and then select the Feature Archive deployment profile.
2. Click Finish. The Summary page, shown in Figure 26-36, displays the full path of where the JAR path of the Feature Archive file is deployed.

   Figure 26-36 File Export Summary Page

   

26.6.3 What Happens When You Create a Feature Archive File

FARs that are registered in the maf-application.xml file of an application are available for reuse.

To use a FAR from an external application, you need to register the FAR in the maf-application.xml file of the application. Figure 26-37 shows Feature Archives that can be made available to a mobile application through a file system connection.

Figure 26-37 Deployed Feature Archive JARs in the MAF Application Editor

26.7 Creating a Mobile Application Archive File

An application, if packaged as a Mobile Application Archive file, can be used to create a new application.

The MAF Application Archive (.maa) file format enables you to provide third-parties with an unsigned mobile application. By deriving a mobile application from an imported .maa file, you enable various customizations, which include:

• Giving an application a unique application ID (to enable push notifications, for example).

• Signing an application with a company-specific credential or certificate.

• Replacing the resources with customized splash screens and application icons.

You can create a new mobile application from a n existing mobile application by first packaging the original mobile application as a Mobile Application Archive (.maa) file and then by deriving a new mobile application from this file. A .maa file can be used by third parties, as described in Creating Unsigned Deployment Packages.

A .maa file preserves the structure of the mobile application. Table 26-4 describes the contents of this file.

Table 26-4 Contents of a Mobile Application Archive File

Directory	Description
adf	Contains the META-INF directory, which contains the metadata files, including: The adf-config.xml file The maf-application.xml file The maf-config.xml file Other applicable application-level files, such as the connections.xmlfile
Projects	Contains a JAR file for each project in the workspace. For example, a ViewController.jar file and a ApplicationController.jar file are located in this directory when you deploy a default mobile application to an .maa file. The Projects directory of the .maa file does not include the .java files from the original project. Instead, the .java files are compiled and the resulting .class files are placed in a separate JAR file that is contained in the project JAR file (such as ApplicationController.JAR/classlib/mobileApplicationArchive.jar). The .maa file created in OEPE can be imported only in OEPE. It cannot be imported into OEPE.
ExternalLibs	Contains the application-level libraries (including FARs) that are external to the original mobile application.
META-INF	Includes the maf.properties and logging.properties files.
resources	Includes the following directories: android—Contains Android-specific image files for application icons and splash screens. ios—Contains iOS-specific image files for application icons and splash screens. security—Includes the cacerts file (the keystore file).

In addition to the artifacts listed in Table 26-4, the .maa file includes any folder containing FARs or JAR files that are internal to the original mobile application. See also What Happens When You Import a MAF Application Archive File.

Note:

Importing an .maa file into an existing application overwrites the workspace and project container files (the.jws and .jpr files, respectively). As a result, all prior changes to MAF AMX pages and configuration files, such as maf-application.xml, maf-config.xml, connections.xml, and adf-config.xml, will not be retained.

26.7.1 How to Create a Mobile Application Archive File

Package an application in the MAF Application Archive file format to provide it as an unsigned application to third-parties. Use the procedure to package a mobile application as a MAF Application Archive file.

The MAF Application Archive (.maa) file format enables you to provide third-parties with an unsigned mobile application. By deriving a mobile application from an imported .maa file, you enable various customizations, which include:

• Giving an application a unique application ID (to enable push notifications, for example).

• Signing an application with a company-specific credential or certificate.

• Replacing the resources with customized splash screens and application icons.

You can create a new mobile application from a n existing mobile application by first packaging the original mobile application as a Mobile Application Archive (.maa) file and then by deriving a new mobile application from this file. A .maa file can be used by third parties, as described in Creating Unsigned Deployment Packages.

A .maa file preserves the structure of the mobile application. Table 26-4 describes the contents of this file.

Table 26-5 Contents of a Mobile Application Archive File

Directory	Description
adf	Contains the META-INF directory, which contains the metadata files, including: The adf-config.xml file The maf-application.xml file The maf-config.xml file Other applicable application-level files, such as the connections.xml file
Projects	Contains a JAR file for each project in the workspace. For example, a ViewController.jar file and a ApplicationController.jar file are located in this directory when you deploy a default mobile application to a .maa file. The Projects directory of the .maa file does not include the .java files from the original project. Instead, the .java files are compiled and the resulting .class files are placed in a separate JAR file that is contained in the project JAR file (such as ApplicationController.JAR/classlib/mobileApplicationArchive.jar). The .maa file created in OEPE can be imported only in OEPE. It cannot be imported into JDeveloper.
ExternalLibs	Contains the application-level libraries (including FARs) that are external to the original mobile application.
META-INF	Includes the maf.properties and logging.properties files.
resources	Includes the following directories: android—Contains Android-specific image files for application icons and splash screens. ios—Contains iOS-specific image files for application icons and splash screens. windows—Contains iOS-specific image files for application icons and splash screens. security—Includes the cacerts file (the keystore file).

In addition to the artifacts listed in Table 26-4, the .maa file includes any folder containing FARs or JAR files that are internal to the original mobile application. See also What Happens When You Import a MAF Application Archive File.

To package a mobile application as a MAF Application Archive file:

1. Click File then select Export.
2. In the Export wizard, expand Oracle, then Mobile Application Framework, and select Mobile Application Archive (MAA), as shown in Figure 26-38.

   Figure 26-38 Creating a Mobile Application Archive File

   
3. Click Next, and select the name of the application you want to archive and enter a name for the Mobile Application Archive, as shown in Figure 26-39.

   Figure 26-39 Entering a Name and Path for the Mobile Application Archive File

   
4. Click Finish

26.8 Creating Unsigned Deployment Packages

You can create an unsigned mobile application from a MAF Application Archive file.

The MAF Application Archive (.maa) file format enables you to provide third-parties with an unsigned mobile application. By deriving a mobile application from an imported .maa file, you enable various customizations, which include:

• Giving an application a unique application ID (to enable push notifications, for example).

• Signing an application with a company-specific credential or certificate.

• Replacing the resources with customized splash screens and application icons.

Note:

You cannot import an .maa file into a workspace that already contains one or more of the same projects. Instead, you must import the .maa file into a different workspace.

26.8.1 How to Create an Unsigned Application

You can create an unsigned application from an imported Mobile Application Archive file. Use the procedure to create an unsigned application.

You create an unsigned application by importing an .maa file into a new mobile application.

To create an unsigned application:

1. Select File then select Import.
2. In the Import wizard, expand Oracle and select Mobile Application Archive (MAA). Click Next.
3. In the Import Mobile Application Archive (MAA) page, click Browse and navigate to the MAA file. Click Next.
4. In the Configure Deployment Targets page, select the targets you will want to deploy to, and click Finish.

26.8.2 What Happens When You Import a MAF Application Archive File

When you import a .maa file, MAF creates projects for the assembly, the application, and the view projects, and unpacks files from the imported file.

MAF performs the following after you import an .maa file:

1. Creates a project for each of the assembly project, the application project and the view projects.

2. Unpacks files from the .maa file.

26.9 Deploying with Oracle Mobile Security Suite

For enterprise-level security, MAF applications, when deployed, may be containerized for data leakage prevention and encryption using Oracle Mobile Security Suite. Use the procedure to containerize an application using Oracle Mobile Security Suite.

Oracle Mobile Security Suite (OMSS) provides enterprise-level security for mobile applications. It offers data leakage prevention and encryption of application data and database content through containerization at deployment time. For more information about containerizing your MAF application with OMSS, see Containerizing a MAF Application for Enterprise Distribution.

You can containerize MAF applications that you deploy to the iOS and Android platforms with OMSS. MAF applications that you deploy to the Universal Windows Platform cannot be containerized with OMSS.

Before you begin

You must have the OMSS containerization tool installed. This tool is a command-line utility with the file name c14n. You can download OMSS and read instructions on installation on the Oracle Technology Network:

http://www.oracle.com/technetwork/middleware/id-mgmt/overview/default-2099033.html

Note:

For iOS, you must also have selected the name of the provisioning profile in the iOS Platform preferences page as described in Setting the Device Signing Options.

Containerization is not supported for Android or Windows.

OEPE will not allow you to deploy a mobile app containerized with OMSS to an emulator with default names.

1. Select Run > Run Configurations.
2. In the Target Configuration pane, select MAF Application and either create a new run configuration or select an existing run configuration.
3. At the bottom of the Main tab, in the Containerization pane, select Enable Mobile Security Access Server and click Containerize Tools Location. This displays the Containerize dialog from the Preferences menu (see Figure 26-40).

   Figure 26-40 Specifying the location of the Containerization tool

   
4. Click the Browse icon and browse to the location of the Oracle Mobile Security App Containerization tool on your local file system.
5. Click OK to select the containerization tool.
6. From the Run Configurations dialog, select Run.

   Note:

   For iOS, containerization is supported for iTunes deployment only. Deployment to a distribution package or simulator will not create a containerized .ipa file.

   A platform-specific file for Android) secured by Oracle Mobile Security Suite will be created:

   • .ipa for iOS.

   • .apk for Android. OMSS may create an intermediate .h header file which is compiled into the app.

   After you add the containerized application to your device, it will display a lock icon, as shown in Figure 26-41.

Figure 26-41 Mobile Application Displaying the Lock Icon for Containerization

26.9.1 What Happens When You Containerize Your App with OMSS

A MAF application that is containerized with Oracle Mobile Security Suite can be uploaded to the OMSS Mobile App Catalog. Policies can be applied to the application to manage its functionality.

When you deploy a MAF application containerized with Oracle Mobile Security Suite (OMSS), you can then upload it to the OMSS Mobile App Catalog, which displays a list of currently available apps. Before publishing the application to users, the OMSS administrator applies various policies to the app to manage its functionality. By applying specific policies on the OMSS server side, the OMSS administrator can manage the security and sharing requirements for applications containerized with the Oracle Mobile Security App Containerization Tool. Data in transit and data stored locally inside containerized apps on the mobile device is encrypted. Encrypted data storage includes application data, including files, databases, application cache, and user preferences.

After applying OMSS data leakage protection and encryption, you can then make the app available to users from a download site.

Note:

iOS MAF apps that are containerized with OMSS can only be distributed to users through an internal download site or enterprise app store. Containerized iOS MAF apps cannot be uploaded to the Apple App store. This restriction is not applicable to Android MAF apps that are containerized with OMSS. These apps can be distributed through an internal download site, enterprise app store, or Google Play.

For details about how system administrators use the OMSS Mobile App Catalog to manage the MAF application provisioned to devices and workspaces, see Managing Devices and Workspaces in Administering Oracle Mobile Security Suite.

The following OMSS data leakage protection policies restrict how and if users can share data within an app:

• Email allowed can restrict the ability to send email from an app.

• Instant Message allowed can restrict the ability to send Instant Message from an app.

• Video chat allowed restricts the ability to share information via services such as FaceTime.

• Social Share allowed restricts the ability to share information via services such as Facebook or Twitter.

• Print allowed restricts the ability of the user to print.

• Restrict file sharing restricts the ability of the user to share files outside the secure enterprise workspace.

• Restrict copy/paste allows copy/paste inside the secure container, containerized apps or between containerized apps, but not to apps outside the secure enterprise workspace.

• Redirects to container allowed prevents any app outside the Mobile Security Container workspace from redirecting a URL into the container.

• Save to media gallery allowed prevents images, videos and audio files from being saved to media gallery and photo stores.

• Save to local contacts allowed prevents contacts inside secure enterprise workspace apps from being saved down to native device contacts app.

• Redirects from container allowed prevents any vApp from the Mobile Security Container workspace or containerized app from redirecting a URL outside the Mobile Security Container workspace or containerized app.