Creating Shared Device Apps With The Wizard

Prerequisites

You require an SAP Business Technology Platform account with administrator privileges to create or edit configuration settings on the SAP Business Technology Platform. If your account does not have administrator privileges, the Wizard controls requiring full permissions are unavailable. See the Wizard screen topics for more information about account restrictions.

Procedure

Launch the Wizard and follow the prompts to create a shared device(multiple users) app configured with connections to the SAP Business Technology Platform

1. From the Android Studio Welcome screen, select New SAP BTP Android App.

   You can also start the Wizard by opening Android Studio and selecting File > New > New SAP BTP Android App .

2. Follow the steps in the Wizard, as described below (note that steps i through iv are documented in Creating Apps with the Wizard):

   1. Maintaining mobile services connection.
   2. Creating or reusing mobile services application configurations.
   3. Adding OData services.
   4. Specifying Android project properties.
   5. Adding shared devices features.

Adding Shared Device Features

Use this page to configure shared devices (also called "Multiple Users Mode").

When you select the Enable Multiple Users checkbox for code generation, the Wizard retrieves the multiple user flag from the server to generate the client app with multiple user mode enabled. Go to the SAP mobile service cockpit and select your app from the app list. Click Client Settings in the assigned features list:

Scroll down to the bottom of the page and verify that the shared device checkbox has been checked.

For an offline app, you can choose from two options to handle conflict in Multi User Mode: Discard Pending Transactions, or Discard Pending Transactions After Upload.

For details on passing settings into OfflineODataParameters to handle the conflict during open(), see User Switch Conflict Handling.

Offline Conflict Handling in Multi-User Mode

When multiple users share the same device, offline data conflicts can occur if a new user logs in before the previous user's pending transactions are resolved. The SDK allows you to configure how to handle these conflicts.

Configuring Offline Conflict Handling

1. Go to the mobile services cockpit, choose your app from the list, and navigate to the Client Settings section within Settings.
2. Verify that the Allow Upload of Pending Changes from Previous User (Enable Multiple User Mode) flag is enabled. This setting is required for offline conflict handling to function. Enable the Offline Conflict Handling in Multi User Mode checkbox.

Once offline conflict handling is enabled, two optional conflict resolution modes are available. Only the first is enabled by default:

• Discard Pending Transactions — When a new user logs in, pending changes from the previously logged-in user are removed from the local request queue. This action is logged, and the current user receives a notification after successful deletion before continuing with the application. Note that this results in permanent data loss for any pending transactions from the previous user.

• Discard Pending Transactions After Upload — When a new user logs in, the previous user's offline request queue database is uploaded to mobile services cockpit for inspection. After the upload completes, the device discards pending transactions from the previous user. The new user's application access is blocked until the upload finishes.

!!! note "Note"

  This option can only be enabled when **Offline Store Upload** is enabled.

Configuring Offline Store Upload

1. Navigate to the Offline Access section within Settings.
2. Enable the Enable Offline Store Upload checkbox in the Offline Store Upload Policy group. You can configure the Delete Offline Store After and Maximum Offline Store Size parameters for the Offline Store to suit your preferences, or retain the initial default values.

Behavior by Configuration

offlineConflictHandlingEnabled	offlineConflictHandlingMode	Result
Unchecked / absent	—	offlineConflictHandlingEnabled = false, offlineConflictHandlingMode = nil — conflict handling skipped
Checked	Discard Pending Transactions	The request queue of the previously logged-in user is deleted locally. The user is notified, and the application proceeds.
Checked	Discard Pending Transactions After Upload	When a new user logs in, the previous user's offline request queue database is uploaded to mobile services cockpit for inspection. Pending changes on the device are discarded after the upload is complete. The application is blocked until the upload is successfully completed. The user is notified.

Accessing the Settings in Your App

After completing a successful onboarding or restore flow, you can access the offline conflict-handling configuration via the SharedDeviceSettings object. Your application can handle it accordingly.

// Suspend until shared device settings are retrieved
suspendCoroutine { continuation ->
    sharedDeviceSettings.retrieveSharedDeviceSettings(object :
        ServiceListener<SharedDeviceSettings> {
        override fun onServiceDone(result: ServiceResult<SharedDeviceSettings>) {
            when (result) {
                is ServiceResult.SUCCESS<SharedDeviceSettings> -> {
                    val sharedDeviceServices: SharedDeviceSettings? = result.data
                    if (sharedDeviceServices?.allowUploadPreviousUserPendingChange == true) {
                        isForceUploadOnUserSwitch = true
                        if (sharedDeviceServices.offlineConflictHandlingEnabled) {
                            sharedDeviceServices.offlineConflictHandlingMode?.let {
                                if (it.equals("discard", true)) {
                                    userSwitchConflictHandlingMode = UserSwitchConflictHandlingMode.DISCARD_PENDING_TRANSACTIONS
                                    // handle discard
                                } else if (it.equals("upload", true)) {
                                    userSwitchConflictHandlingMode = UserSwitchConflictHandlingMode.DISCARD_PENDING_TRANSACTIONS_AFTER_UPLOAD
                                    // handle upload to request queue
                                }
                            }
                        }
                    }
                }
                is ServiceResult.FAILURE<SharedDeviceSettings> -> {
                    // handle failure when retrieving the SharedDeviceSettings
                }
            }
            continuation.resume(Unit)
        }
    })
}

Note

The application can read the value configured in mobile services cockpit through sharedDeviceServices.offlineConflictHandlingMode.

Generated App

The generated app provides complete create-read-update-delete (CRUD) access to the OData service data behind the selected app of the SAP Business Technology Platform server. It includes the Fiori logon screens for onboarding to the server as well as the OData and Foundation libraries that are used to consume the service.

The generated client code may look like:

JAVA

FlowContext flowContext = new FlowContextBuilder()
        .setApplication(appConfig)
        .setMultipleUserMode(true)
        .setFlowStateListener(new WizardFlowStateListener(
                (SAPWizardApplication) context.getApplication()))
        .build();

KOTLIN

val flowContext =
        FlowContextBuilder()
            .setApplication(appConfig)
            .setMultipleUserMode(true)
            .setFlowStateListener(WizardFlowStateListener(activity.application as SAPWizardApplication))
            .build()

Onboarding Flow

On the first start of the app, the following Welcome screen is displayed:

Tapping the Get Started button triggers the logon flow.

The generated app supports Basic authentication, OAuth2, SAML, or no authentication. The code is generated according to the authentication type of the consumed app, which was set on the server. If the authentication type is Basic, then an Authentication dialog is displayed.

After providing the correct credentials, the app receives the client-side configuration policy from the server containing the required passcode policy. If the app requires passcode protection, then a Create Passcode screen is displayed. This screen also contains information about passcode complexity. After a correct passcode is entered, a verification screen is displayed.

After a passcode is created, the logon flow is complete. The app displays the entity set list that is accessible on the server.

Re-run (quit first) the app and notice that the onboarding process is the same as for single-user mode, except that no biometric authentication screen is shown. After onboarding, put the app in background until the unlock screen appears. In multi-user mode, there is a SWITCH OR ADD USER button at the bottom of the screen.

When the user clicks the button, the user list is displayed. The user can either select an existing user from the list or click the ADD USER icon at the top right of the screen. This will start the onboarding process for the new user.

---

Last update: August 21, 2026