Create More Secure Android Applications! Learn the Simple Way to Integrate Samsung Knox SDK

Secure Container: Used to separate and protect enterprise data and applications from unauthorized access.
VPN: Used to establish a secure VPN connection to protect network traffic and data.
Encryption: Used to encrypt data to ensure its security during transmission.
Policy Management: Used to manage device settings and policies, such as password rules, device locking, data wiping, etc.
Authentication: Used to implement strong authentication features, including biometric and smart card authentication.
Security Updates: Used to securely update applications and operating systems to enhance overall security.

This article mainly explains
some basic concepts when integrating the Samsung Knox SDK
and shares the pitfalls encountered with you

• Currently supported Samsung phones and versions: Reference
  • When Knox is not supported, the official suggestions and methods: Reference
  • Various Knox services: Reference
• Download and install Knox SDK
  • According to the official website Install the SDK, import the relevant SDK into the project
  • When importing, you may encounter which version to use, refer to the mapping table
  • Obtain a license key
    • If developing a version before Knox 2.7, the generated license key can be “optionally” backward compatible
    • License keys are divided into Development Key and Commercial Key, which can be configured according to testing or release
    • Associated APK: Only the associated APK can use the generated license key (There is an optional option in the backend that can be checked or unchecked)
    • After testing, Development Key can only have one under the same account -> License key rules and restrictions
  • Activating the license key during development varies with different Knox versions: Refer here

  • Official examples related to Knox development are provided: Reference

  • Knox license
    • List of available license permissions
    • Three more readable versions of the license
    • After backend testing, the SDK license key is further divided into:
      • KPE Development: For testing environments, key lifespan 0.5 years
      • KPE Standard: Allows access to Standard permissions, 10,000,000 seats, key lifespan 2 years
      • KPE Premium: Allows access to Standard, Premium, and Custom permissions, 10,000,000 seats, key lifespan 2 years
      • KPE DualDAR: Allows access to Standard, Premium, Custom, and DualDAR permissions, negotiated with agents for annual or permanent subscription
    • Development permission declaration:
      • Knox 3.0 provides the declaration of partial permissions, which can be declared in AndroidManifest.xml. If not declared, all Knox permissions are enabled by default. If declared, only the declared permissions are allowed. Reference
  • Current preliminary comparison with native AirDroid Biz using DevicePolicyManager (only comparing similar APIs for now, can discuss which ones to use, then test actual behavior)
    • All permissions can be viewed here
    • Actual comparison of commonly used DevicePolicyManager and Knox provided functionalities for reference
  • Reference Links
    • Samsung Knox Developer Official Website
    • Developer Documentation Official Website
    • Knox SDK Introduction
    • Knox API Documentation

• Samsung Knox provides both web-based and device-based methods for use. Its current architecture:
  
  

• Android 6.0.1 Samsung S6, testing Knox 3.8
  • Downloaded Knox 3.8 version from Samsung developer backend, usage method knox3.7.1 higher, encountered exception when parsing URI

  • Switched to knox2.7 lower and encountered java.lang.RuntimeException: Stub!
    -> Solution: Add supportlib.jar and include in gradle dependencies
    When using the Add as library feature in IDE, note the following: Here, the original knox sdk and supportlib jar files need to be changed as follows, otherwise runtime errors will occur

  • After the above steps, when activating the license key, admin permissions need to be enabled, otherwise internal error will be returned
    

  • There is a pitfall here: when activating the license, a Broadcast receiver needs to be used to receive the return result
    • However, the current official documentation shows that the broadcast action for activating the Knox license is But in the old Knox API level 19 (Knox 2.6), Knox does not send the above Action, instead it sends the following
    • It is noted here that the official documentation states namespace changes when upgrading from 2.x to 3.x (starting from Knox API 30)
• So here is a method provided: Reference
  • Just add supportlib.jar and include the relevant receivers from the link above into Manifest.xml

• Android 12 Samsung A52s, tested Knox 3.8

  • Using both knox3.7.1 higher and knox2.7 lower methods can activate the license key
• Other behaviors
  • Currently, the developer backend allows downloading Knox SDK 3.3 ~ 3.8,
    The above test cases all use Knox 3.8 and can compile,
    but some behaviors may only support their corresponding versions.
    Later, Knox 3.3 was tested on Android 12,
    and using knox3.7.1 higher to activate it will crash,
    Similarly, using knox3.7.1 higher to activate on Android 6.0.1 Knox 3.8 will also crash.
    

• Vpn Development
  • According to the development documents, two Vpn solutions are provided:

    1. Similar to the previously researched native Android Vpn Service Knox extends related functions on this basis: Reference

    2. The other is GenericVpnPolicy API
       createVpnProfile, which mentions providing the corresponding JSON format to set its vpn profile.
       Different JSON formats correspond to different modes.
       Refer to: vpn JSON format -> Currently, the Knox documents have similar requirements as before:
       ipsec Hybrid RSA, PSK, xauth RSA, IKE2 PSK, IKE2 RSA… etc.
       Additionally, the document states Knox api level 35 Deprecated -> Corresponding to Android 12

• LockScreen Password
  • Biometric unlock, set up fingerprint unlock or face unlock: Click here

Actually, to activate Knox, you just need to follow the method in the official documents.
Here I provide my planned thought process for everyone, as follows:

• Currently, it is packaged as a dagger2 module.
  • The structure is as shown in the picture:
    
    • ExampleKnoxActivity is used for demo purposes and will contain some examples of other class implementations.
    • Later, you only need to inject KnoxManager and initialize KnoxModule to use it.

    
    

    
    

    • KnoxLicense stores some constants and key values that can be changed. In the future, if you don’t want to upload the key, it can be adjusted.
    • To use it, you only need to understand KnoxManager.
    • Mainly added functions for registering/unbinding Knox broadcasts, activating/deactivating licenses, etc. Subsequent related functions will mainly be added from KnoxManager.
    • Among them, KnoxLicenseReceiver is because the official Knox 3.7 and below only provide a Broadcast method to receive activation success or failure.
      Here, it is well packaged using Kotlin features.
      The actual method in knoxManager is used to register and return the result.
      

Theoretically, you can also use Koin for DI, and personally, I prefer Koin. I'll write an article about DI with Koin when I have time.

• Add Knox permission
  • Add permission declaration to the manifest

  • Knox API 30 is the watershed between old and new package names.
    In this test, Knox API 19 could not use the new permission request such as:
    com.samsung.android.knox.permission.KNOX_APP_MGMT
    Using com.example.supportlibclient.SUPPORT_PERMISSION was successful.
    

  • Runtime permission
    
• Other related
  Some API manipulations require parsing the corresponding URI. Here is a shared example.