If an app does not have a "default" activity defined,  the solution is to specify the activity directly with "start activity bunlde_ID/activity_name".  So, maybe you could try

  start  activity  com.samsung.android.dialer/.DialtactsActivity

or

  start   com.samsung.android.dialer

or

  start    com.android.contacts

on whatever phone model you are testing.

Hi Ben Smith,

Thanks for the interesting post!

I clearly understand your situation with regards to Phone app. As you said, you can have all the bundle ids of Dialer in a single lockdown profile and the right one gets installed on the device. But the invalid bundle ids will have a dummy icon created on the lockdown page in addition to the Phone app. This may create chaos to the user and there is a chance of app crashing. So, I would suggest you to have multiple lockdown profiles created with correct bundle ids with respect to the the Manufacturer models for easy user access.

With regards to Settings option on lockdown, are you experiencing this on Android enterprise devices or any android device?

Regards,

For the lockdown menu requiring an item running different app for different devices using the same html , there are at least three different approaches, each with its pros and cons depending mainly on  level of device variations, how and how often changes are to be made, how the app get relaunched or handel multiple instances, etc.  Thus, there is no approach that is best for all use cases.  The three approaches are:

1.  Include "start" statement for all possible app bundle-ID in a script file that is referenced as a lockdown menu item if the apps are mutually exclusive (i.e. only one is present on each device) among the group of devices.  

2. Use custom attribute when defining kiosk item in  lockdown payload or directly in the html file.  Then set appropriate value for the custom attribute for different device group(s) or different device(s).

3. Use conditional javascript statements together with various MobiControl macros to handle the variation.

Personnaly i would use Device-Name Groups at the lowest level i.e.

Site 1 -> BYOD -> Samsung Oreo

Site 1 -> BYOD -> Samsung Nougat

etc.

I think if you manage the devices like this you can create lockdowns individually for each device category and have them all in one place, which makes it easier to be trouble shooted if they have issues too.

To have the least amount of manual doing, you can create enrollment rules for each of the device types then.

Hi DDMOD,

I clearly understand your situation with regards to Phone app. As you said, you can have all the bundle ids of Dialer in a single lockdown profile and the right one gets installed on the device. But the invalid bundle ids will have a dummy icon created on the lockdown page in addition to the Phone app. This may create chaos to the user and there is a chance of app crashing. So, I would suggest you to have multiple lockdown profiles created with correct bundle ids with respect to the the Manufacturer models for easy user access.

How would I automate this for different devices via the TEM relocation rule? I don't recall seeing any properties that we could specify that it would relocate if detected, it seems to be just if the data breaches a limit it will move a device from one folder to another. We currently throw all devices and various OS in a single folder for our field reps.

We currently have various folders for different types of users, managers, service, auditors, etc. Once they breach 2GB of data they get thrown in a "lockdown folder". They all have various Samsung devices and OS versions.

With regards to Settings option on lockdown, are you experiencing this on Android enterprise devices or any android device?

We currently have experienced this issue on Android Classic devices only, I have not tested AE yet.

Hi Raymond,

1.  Include "start" statement for all possible app bundle-ID in a script file that is referenced as a lockdown menu item if the apps are mutually exclusive (i.e. only one is present on each device) among the group of devices.  

Would you happen to have more information on how to perform the first possible solution? I think this could work possible for us.

Ben,

We had the same issue with our Samsung phones, so we started using a 3rd party dialer on all our phones which is a mix of Samsung and Kyocera. We have recently moved to Android Enterprise and now we can use the same lockdown on all our phones since they all use the same Mobi Agent rather than OEM specific. There are some good 3rd party dialers out there that are ad-free and compatible with newer and older android versions. It's worked well for us. 

Just use script:// rather than launch://  in the kiosk item to point to a script file (with filename "dialer.cmd" say), and use a custom "dialer" icon you upload to the server rather than the icon embedded within the dialler's apk for the html macro entry  <MCDispImg#> rather than MCExeIcon#> in your html template.

In the script file "dial.cmd", just add one line of "start  App_Bundle_ID"  for each of the diallers to be supported, e,g.

   start  com.abc.dialler1

   start  net.def.dial2

   ...

As it is assumed that each devic only has one of the diallers defined in the script installed, the right dialler will always be run.

This approach may not work if the app UI does not support seamless transition when repeated flipping between the dialler and the kiosk menu when "start" is used.   In such case, a simple alternative is to  consider using a common third-party dialler app for all different device brands/models.

Hi Raymond,

I feel like this is the best solution so far, but for some reason I am getting error messages with running the script. I'm not sure what step I missed.

020-05-11 22:30:10.816|main|D|AP|[net.soti.mobicontrol.lockdown.kiosk.r.a:43] user clicked script:///storage/emulated/0/SOTI_scripts/dialer.cmd|
2020-05-11 22:30:10.816|main|D|AP|[net.soti.mobicontrol.lockdown.kiosk.r.a:47] launching with ag|
2020-05-11 22:30:10.816|main|D|AP|executing the script, file:/storage/emulated/0/SOTI_scripts/dialer.cmd|
2020-05-11 22:30:10.818|main|D|AP|the script file encoding is UTF-8, loading the script...|
2020-05-11 22:30:10.819|main|D|AP|script is loaded, executing..|
2020-05-11 22:30:10.820|script-executor|D|AP|[LegacyScriptExecutor][execute]script command: start - begin|
2020-05-11 22:30:10.824|script-executor|D|AP|Package [com.samsung.android.contacts/com.android.dialer.DialtactsActivity] does not have default activity. Start failed|
2020-05-11 22:30:10.824|script-executor|D|AP|[LegacyScriptExecutor][execute]script command: start [com.samsung.android.contacts/com.android.dialer.DialtactsActivity], result: ScriptResult{description='FAILED', resultType=FAILED}|
2020-05-11 22:30:10.824|script-executor|D|AP|[LegacyScriptExecutor][execute]script command: start - begin|
2020-05-11 22:30:10.824|script-executor|D|AP|Package [com.samsung.android.dialer/.DialtactsActivity] does not have default activity. Start failed|
2020-05-11 22:30:10.825|script-executor|D|AP|[LegacyScriptExecutor][execute]script command: start [com.samsung.android.dialer/.DialtactsActivity], result: ScriptResult{description='FAILED', resultType=FAILED}|

Edit: So it looks like it was a wrong file name for one of the dialers, however, I am not able to get Samsung Android 8 devices to work, identify_activity shows that com.samsung.android.contacts/com.android.dialer.DialtactsActivity is the correct name.

Android 9 devices seem to use "com.samsung.android.dialer" as best I can tell, and they work when clicked on.

It looks like one of the names was incorrect, however, I have fixed this for Android 9+ devices, but the below 8 devices do NOT work. It appears that "com.samsung.android.dialer" is correct for 9+ devices, but "com.samsung.android.contacts/com.android.dialer.DialtactsActivity" does not work, even though the identify_activity shows this to be correct.

That worked! Thank you, Raymond!

That fixes that issue, I still have the issue with unable to modify settings on the lockscreen, not sure if that is intentional or not. I could of sworn we could do it in the past but could prohibit it by checking the box in the setup to prevent it.