Back to top
Home / Knox SDK / Features / MDM Providers / Workspaces / Workspace changes in 3.x /

Changes overview

This section covers the general changes made to the Knox Platform for Enterprise as a result of the Knox 3.0 container architecture updates.

Badging

Upon the Knox ELM / KLM license activation, the workspace and app badge changes from a briefcase to a shield to indicate that the Knox ELM / KLM license has been activated.

knox-badge-change.png

Applicable to profile only.

Password Enforcement

The Knox Platform for Enterprise framework will not enforce password by default. IT admins can leverage either Android APIs or Knox APIs to apply password policy based on their enterprise requirements.

Android API

See DPM setPasswordQuality()

Knox API

See Knox PasswordPolicy class

Applicable to profile only.

Default Policies

The Knox Platform for Enterprise framework does not enforce stricter defaults for either the device or the configuration profile. The following features are enabled by default:

  • USB Debugging
  • Screen Capture
  • Bluetooth
  • NFC
  • Copy/Paste from profile to device

An IT admin can call Android or Knox APIs to lock down the device or the configuration profile.

Default Apps

Android enables the following apps by default for the Android Work profile:

  • Contacts
  • My Files
  • PlayStore

Knox will not enable additional apps by default for profile.

Work Settings

Work settings on Android N are part of device settings. On Android O work settings are available to the user as a separate app inside the profile.

Applicable to profile only.

Screen Capture

Prior Knox Platform for Enterprise Knox license activation, profile screen shots are stored on the device side. After Knox Platform for Enterprise License activations, profile screen shots are stored inside the profile.

Keyboard and Input Methods

The Knox framework starting from Knox 3.2.1 separates personal and profile keyboards to ensure that important work data is not compromised. In an Android Enterprise Work Profile, the same IME is used for both the personal and profile side. Due to this merged use of IME, work data could potentially leak through the IME. To mitigate this threat, upgrade to Knox Platform for Enterprise (KPE).

In previous versions of Knox, IT admins were required to add third-party IMEs to an allowlist for added security. Now that personal and Workspace IMEs are kept separate, users are able to use third party keyboards without prior explicit allowance from IT admins.

As KPE is a superset of Android Enterprise, IT admins can continue to leverage the Android DPM API setPermittedInputMethods and the applied policy affects both IMEs on the Knox Platform.

The separation of IMEs will take effect after FOTA of Knox 3.2.1 or the creation of a new KPE Workspace. End users will not lose a previous IME if it has already been set.

One IME is used for the entire device. Both the device and profile will have the same keyboard. As a result, work data could potentially leak to the personal side using an untrusted IME. To mitigate the risk of data leakage, a system IME is set as the default keyboard and the end user is blocked from using 3rd party IME without an IT admin granting permission through adding it to the allowlist.

The singular IME design is only implemented for the Knox Platform for Enterprise profiles built on top of Android Enterprise. Existing Knox Workspace CL/B2B and COM modes will continue to have separate IMEs.

Approved Installers

By default, Google Play is the only approved installer. IT admin can allow other apps as installers as well.

Biometric Authentication

Management of biometric authentication (fingerprint and iris) will be separate for profile. End user will register biometrics separately for profile. End user will manage (add/remove/update) profile specific biometric data using work settings.

Contacts and Calendar

Knox Workspace and Android contacts are now harmonized. The device user is able to search work contacts from personal side. The device user is also able to import/export work contacts and calendar.

The IT admin can enable/disable contact search and import/export of work contacts and calendar.

Applicable to profile only.

The following APIs for managing contacts and calendar

DPM API

Capability

setCrossProfileContactsSearchDisabled()

getCrossProfileContactsSearchDisabled()

To enable or disable access to work contacts.

setCrossProfileCallerIdDisabled()

getCrossProfileCallerIdDisabled()

Allow Caller-ID information to be shown in personal call logs for incoming calls from work contacts.

setBluetoothContactSharingDisabled() getBluetoothContactSharingDisabled()

To enable or disable displaying of work contacts alongside personal contacts to devices over Bluetooth. Ex. Car.

Knox API

Capability

Package: com.sec.enterprise.knox.container

Class: RCPPolicy

Method: setAllowChangeDataSyncPolicy()

To enable or disable user option in Knox setting to share work contacts and personal contacts.

Number of allowed containers

Only one B2B container and one personal container can be created on the device. Devices can have only one Workspace and only one Secure Folder. Two Workspaces are not allowed.

See Secure Folder for more details.

API Conflict

As Device Owner and Profile Owner can call both Knox and Android APIs on the same solution there are certain APIs that will conflict.

Exact Match APIs

For APIs that are exactly the same Knox will eventually deprecate the API in Knox SDK, recommendation is to use Android APIs.

Partial Match or Superset

For APIs that are match partially or are superset of the other the recommendation is to NOT mix and match and either call Knox or Android.

API moved to User Scope

As part of harmonization, certain APIs that are container scope (can only be called on the container) are moved to user scope. These APIs can be called by the primary user (Device Owner) or the secondary user (Profile Owner). The APIs are only applicable to the user that calls them.

For example, lock() and enforceMultifactorAuthentication() that were previously only container scope are now user scope. Thus, Device Owner can also lock the device or enforce multi-factor authentication for the entire device.

On this page

Is this page helpful?