Back to top

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

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.

Is this page helpful?