wu guo
Jul 03, 2018
2:15 pm

knox 2.6 ELM: Invalid license and java.lang.SecurityException: Admin does not have android.permission.sec.MDM_APP_MGMT

I am doing backwards-compatibility according to the official example


samsung SM-N9200   knox 2.6 

KLM activated successfully

 ELM: Invalid license 

error   java.lang.SecurityException: Admin  does not have android.permission.sec.MDM_APP_MGMT    

but I have this permission in my AndroidManifest.xml.

​what should I do?

Jenna Slomowitz
Jul 03, 2018
5:13 pm


Can you please confirm that you are using an SKL key, it should start with KLM-06. The ELM key that you are using also needs to be a backwards compatibility key.

Best regards,



Yes,I have them.
KLM activated successfully 
ELM: Invalid license

It can work on Android 7.0,7.1,8.0 , because it  just need KLM key.

But the ELM key will fail validation.

Toast shows ELM: Invalid license.

Error :  

 java.lang.SecurityException: Admin  does not have android.permission.sec.MDM_APP_MGMT.

But I have this permission in my AndroidManifest.xml.

Do you have any good suggestions, thank you!

wu guoJul 04, 2018 at 6:41 am
wu guo
Jul 04, 2018
7:19 am

Protect intents converted in SupportLib

//Define the new permission in application’s manifest.
android:name="com.example.supportlibclient.SUPPORT_PERMISSION" android:label="Support permission" android:protectionLevel="signature" />

//Declare permission usage.
<uses-permission android:name="com.example.supportlibclient.SUPPORT_PERMISSION" />

android:name="com.example.supportlibclient.PreventStartReceiver" android:permission="com.example.supportlibclient.SUPPORT_PERMISSION" &gt;

//static receivers
<action android:name="com.samsung.android.knox.intent.action.

//Dynamic receivers
IntentFilter filter = new IntentFilter(); filter.addAction(ApplicationPolicy.ACTION_PREVENT_APPLICATION_START); registerReceiver(mPreventStartPackageReceiver, filter,
"com.example.supportlibclient.SUPPORT_PERMISSION", null);

Does com.example.supportlibclient need to be replaced with its own app package name?

Jenna Slomowitz
Jul 04, 2018
10:26 pm


No you do not need to replace it with the package name. Could you please take a log of your device in order to get more information about the issue.

1. Reproduce the issue.

2. Open the phone app and dial *#9900#

3. Run Dumpstate/logcat

4.Copy to sdcard

5. Upload to https://www.file.io/ and send the link.

Best regards,


Javi García
Jun 09, 2019
8:13 pm


We also had this similar problem with different "java.lang.SecurityException: Admin  does not have *****" and we spent few days to solve them totally.

This was really painful and a lot of time spent on it. I think main reason is because migration documentation is not detailed enough and it lacks a lot of information. This is specially bad in the case of backwards compatibility with devices with Knox API < 22. The information is really confusing with the licence handling process, specially in real life implementation where we have Samsung devices with different OS versions. So at the end we have to deal with many unexpected errors that could have been easier to solve if the migration information and samples would have been much more precise.

If it may be of some help for someone that is still having similar problem, here you have some important details to be considered if you have to migrate to knew Knox SDK 3.x but your deployed devices still have the old Knox API < 22:

1) don't use Android API build version to decide if Samsung device with Knox should implement the compatible backwards licence : it was our first (basic) error and this gave us a lot of confusion because, as it can be seen in the compatible table (https://seap.samsung.com/sdk/knox-version-mapping), backwards licence must only be used when Knox API < 22 and this means that some Nougat devices have to implement it meanwhile other Nougat devices can use new KPE (as you can see in the table, Samsung experts decided to implement new KPE licence in the middle of the Nougat development instead of waiting to new Oreo first version, so we were really confused when some of our Nougat devices were having so many problems with licence activation)

2) at least in the Development phase, those old devices need to validate first the new KPE licence in order to grant correctly all the permissions : at least in all our testing within our deployment specific scenario, we checked that it was really needed to validate the new KPE licence first and not the backwards compatible one (honestly, we don't know if this is normal or not because in the official information it is indicated to use both BUT if you read more carefully, it is also indicated "in development, it is optional" https://seap.samsung.com/license-keys/about-licenses)

3) use "EnterpriseLicenseManager.ACTION_LICENSE_STATUS" in the Action of the IntentFilter used for the licence receiver that allows to validate the new KPE licence : in the compatible sample, it is the only one to be used, but as in our deployment we have all kind of devices, we made the terrible mistake to use the "KnoxEnterpriseLicenseManager.ACTION_LICENSE_STATUS" to validate the KPE licence in old Knox API < 22 devices, and it did not work until we used "EnterpriseLicenseManager.ACTION_LICENSE_STATUS" for the new KPE licence activation

4) related with previous point, there is no way to receive "EnterpriseLicenseManager.LICENSE_RESULT_TYPE_ACTIVATION" when we check the result type for the KPE validation (neither the EnterpriseLicenseManager.LICENSE_RESULT_TYPE_DEACTIVATION that in fact does NOT exist), so the only type result to check is the EnterpriseLicenseManager.LICENSE_RESULT_TYPE_VALIDATION one

As said before, all those last small details were the reason behind our SecurityException "Admin does not have permission" cases. And for sure, this could have been avoided if the availble migration documentation would be a little more detailed with better explained samples.

Best regards.