What you propose is really very interesting!  It seems to create more confusions rather than simplifying or speeding up management.  

If all your device groups share a good enough html template, then adding a "launch:" kiosk item would probably take at most 1 or 2 minutes per device group.  I just doubt how much time you can save if something you propose gets  implemented. 

Another approach is to hard code the "launch:"  kiosk entry  associated with your new app in the shared html template, which possibly only takes 2-3 minutes to complete once and the change will be effective for all the device groups using the template.

That is the approach I would take. Embed the Launch call in the HTML template itself so that you can add a new common app to the Kiosk and have the shared HTML template across all of your different Kiosk Profiles automatically updated. 

I discussed something approaching with our pre sales Soti rep, I hope he got it through to the right people.

In a similar case with a big retail company, several hundreds of shops, with around 5 work apps, but each and every shop has its specifics, and they change over time, so to meet that goal for 5 apps we have to use more than 10 different kiosk profiles, with 3 different templates because of mcexeicon/mcdispimg.

Incredibly annoying and time consuming. And as the apps ecosystem is growing, we will have more and more troubles.

I asked for a baseline kiosk like it is now, but with an addition, called probably Kiosk Addon, that will MERGE both kiosks.

Hopefully this will get through, otherwise we will be overwhelmed shortly.

In fact, since many years ago, variation in mcexeicon/mcdispimg for different kiosk items of multiple kiosks can easily be handled with a single smart unified html template using javascript.  However, successfully using and maintaining such html template requires an MobiControl administrator to acquire some basic skills in html/CSS/javascript.

Okay, that should be a start. I don't have the skills, but we have web designers in the marketing department, I will get in touch with them to see if they can help.

Quite some interest, thanks everyone!

To clarify: I have >10 device groups, with a multitude of apps, spread across these groups.
Each group has its own kiosk configuration, eg:

Group A
    App 1
    App 2
    App 3
Group B
    App 3
    App 4
    App 5
Group ...
    App ...
    ...
    App ...
Group X
    App 2
    App 17
    App 32

It would be nice to define one kiosk mode (or 'app whitelist') on the root level, 
that contains all apps that are allowed to be used, if they are installed:

App 1
App 2
...
App 31
App 32

This way, if a new 'allowed app' is added somewhere, only the root kiosk list must be updated.

Key element: apps that are not installed should not show up in the kiosk menu of the user...
Maybe this is already possible using some HTML wizardry, and if so, please feel free to share some further thoughts on this.
(eg: hide the label when the app icon is not shown?)

The kiosk mode in MobiControl is the most versatile and flexible kiosk implementation available in the market.  Its adoption of STANDARD html/CSS/javascript virtually supports any visual layout and effect imaginable, and ensure the layout can be rendered correctly on as many Android devices as possible.   The  Kiosk items are not limited to be just apps, but can  be html/htmls URL's, ftp sites. files (of any type with corresponding viewer registered on a device), actions, phone numbers to dial, scripts, etc.   The device group hierarchy inheritance and profile mechanisms together provide the best possible reuse mechanism among all MDM software worldwide.   

Some proposals seen in this thread seem to be impractical and not well thought through, possibly because the very close linkage of the kiosk item definitions and corresponding template files required to make the kiosk layout functional is not understood by laymen or non-programmers.  E.g.

- App whitelist and apps defined in Kiosk are not exactly equivalent, as the order of the item in a whitelist is not important, but the order of the item in a kiosk is important.  Shouldn't an administrator configure somewhere to tell MobiControl server that a common app "App 3" in a root node kiosk/whitelist  be the third item in kiosk A, the first item in kiosk B, etc..  Aren't these annoying overhead that needs to be managed from time to time.  Even worse, one has to go up and down different device group levels to check mismatch or verify correctness.

- If some kind of apps defined in a device node can be inherited to the nodes below (which can be at most 20-level down in MobiControl), will it save time to go up different level(s) to check if there is any mistake and whether the resulting kiosk definitions match in type and order with items in the kiosk template of the corresponding device group.  It will likely be nightmare especially for the laymen and non-programmers, who are not trained to think, design and implement object-oriented concepts (e.g. inheritance, exceptions, etc.) systematically and accurately.

The so-called "problem" mentioned in this thread can easily be solved by

1. smartly cloning of existing Kiosk profile to new ones with subsequent minor modifications to save time editing things from scratch

2. using of good html/CSS/javascript template to maximize re-use in multiple kiosk definitions

3. good and systematic planning of device group hierarchy  and profile filter criteria to maximize kiosk definitions reuse.

I'm aware of all this, but...

I'm at the same time asking soti about what can be done, the right idea could do wonders, who knows.

If you look at my case :

- 5 apps used, at the moment

- each shop can have any combination of the 5 apps, only one being used by all of them

- some of the apps are actual apps, or soti surf links, or even a specific app using chrome

Each time one app is published to a specific shop, I have to push the corresponding kiosk, and uncheck the old one.

No matter how hard I think of it, I can't find an idea with the actual way the kiosk works, to set this up more effectively.

I'm not even talking about the human error factor, when a new app is pushed on 150 different folder, when you need to check 150 boxes, and uncheck 150 others. Some shops will end up without a kiosk (and yes, this happened)

I've already summarized the three major directions to expore, namely

1. smartly cloning of existing Kiosk profile to new ones with subsequent minor modifications to save time editing things from scratch

2. using of good html/CSS/javascript template to maximize re-use in multiple kiosk definitions

3. good and systematic planning of device group hierarchy  and profile filter criteria to maximize kiosk definitions reuse.

So for now, you can at least put the single common app directly into an html template which can handle at most 5 generic items (app, Soti Surf link, etc.). 

Under normal circumstances, there should be some pattern or logic that allow reuse if the 150 shops are under one company.  I don't know why your company is so special that your top management decides not to impose any restrictions and give the freedom for any app combinations.

However, if each of your 150 shops really has a different application combination and kiosk arrangement order from those of any other, then there is completely no pattern for re-use.  You will then need 150 profiles, and all you can do is to manage them independently as before (and possibly ask for a pay raise).

Hi Raymond,

although it's nice to have a discussion on this, and it seems to attract other people with similar questions as well, statements such as 'It seems to create more confusions rather than simplifying or speeding up management' and 'Some proposals seen in this thread seem to be impractical and not well thought through' make a constructive discussion on an idea rather difficult.

The discussion indeed includes multiple use cases, each requiring another approach.

In our case, we don't really care about the order of the apps in the kiosk mode;
we just want to avoid "smartly cloning of existing Kiosk profile to new ones with subsequent minor modifications",
by simply having one 'whitelist' of apps that may appear in the kiosk mode...

But indeed you are right: not only apps can be added to a kiosk mode, but also hyperlinks etc.
So, a kiosk mode on a specific device group level still remains required to manage this...

For now, we'll manage... time will tell.

br, Steven

Hi Steven,

For your case in which order of the apps doesn't matter,  you can also reduce management overheads by including the common apps directly in a shared html template which is to be used by all different kiosks.   All your kiosk starts with these common apps items, followed by customized set of extra items defined by individual kiosk profile for each device group of interest. 

Also, the shared html template file likely need some special customization (conditional, javascript, special macros, etc.)  so that it can serve different kiosk profile with varying number of extra items or item types.

Ok, to finalize from my side:

if only apps were involved, I would have a solution, since I managed to create a kiosk template that accomplishes the desired effect, using following html:

<li id="item0">
    <a href ="<MCLink0>">
        <img src="<MCExeIcon0>" onerror="item0.style.display='none'" />
        <div class="txt">MCDISP0</div>
    </a>
</li>

The 'onerror' feature is key element in this case.

BTW: how many kiosk items can one define? (in other wordts: how many MCLink.../MCExeIcon.../MSDISP... can you configure?)

The biggest Kiosk I've previously tried has about 50.   I don't think any practical Kiosk can hit the implementation limit, which I guess should be in the hundreds/thousands range at least. 

When I talked about inline common app kiosk items in shared html template for multiple kiosks in previous posts, I meant replacing macros such as <MCLink#>, <MCDISP#>  etc. with the actual data that are normally defined for each item in the Kiosk profile. I often put a tilde ~ in each of the shared kiosk item as a dummy placeholder to ensure the kiosk profile can be saved after editing.

Here's how I'd solve this issue:

• Create a single "base" Kiosk profile with a customized HTML template that leverages CSS and JavaScript.
• For every Device Group that depends on a set of applications, we can create a simple "App List" text file that contains a list of our applications in the order we expect them to be. Every line will be an entry for our Kiosk boxes, either in the form of "com.company.package" or the full action, e.g. "launch://com.company.package". This App List file can be synchronized through MobiControl when a change is detected. Perhaps Custom Data/Definitions can be used here, but I'm not sure if the device can benefit from it. Separate Profiles can be used here for every Device Group.
• On the Device itself, the Kiosk's template will execute JavaScript that reads our "App List" file from the device's storage, in our desired order, to populate the launch "boxes" programmatically.

Here is a crude but working example of my idea, free to use and redistribute. Tested on Android 6.0.1 with MobiControl agent 1.3.6.0.1662.

Overview on how to use it:

• Add the HTML template to your Lockdown Profile. You don't need to add the applications/actions through the Lockdown profile since they'll be managed through applist.txt. However, you need to add one entry or else MobiControl won't let you save the configuration (can be anything).
• Modify the applist.txt file to your liking. There are three columns separated with the "|" character.: the first column is the title, the second is the URL, and the last column is an optional image path for the icon.
• Copy the applist.txt and related (optional) icons/images to the device (e.g. /sdcard/) using any method you prefer.
• Enable the Profile and enjoy.

Forgot to add: you can customize the number of columns by modifying the "maxCols" variable and update the path to the applist.txt at the very bottom.

Wow that's really nice, thank you.

I'll try to work with that, and possibly custom attributes and see where it goes.

Hi Saro,

Thats awesome. Nice Work!

One Question: How should I handle the Icon of native Apps like Chrome?

in your applist.txt I see this: |data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAAABCAYAAABubagXAAAAEElEQVR42mNk+P+/nmEEAwB6pgJ/X9KuVAAAAABJRU5ErkJggg== but where did you got this ID from?

I just want to Display the Chrome Icon e.g. Here's my current applist.txt

Chrome|Launch://com.android.chrome|

Many Thanks!

Another approach is to use custom attributes, and conditions in the template with javascript.

You still populate all of the apps in the profile like normal, but the display of the line itself (that shows the entry on screen) will be based on the state of a custom attribute you defined.

I'm testing something like that atm and it works pretty well.

Maybe I have to explain what I want do ;-)

We want to create one Kiosk-Template for our Zebra Devices so that the Employees can choose their Role within the Kiosk-Site like Sales, POS, Transports and so on. You just pick up a Device in the morning and click on your Role in the Kiosk-Mode. After that the specific "Applist.txt" should be loaded and the Device only displays the desired Apps for the Role.

Anyway, I only want to know how to display the App own Logo ;-)

One Question: How should I handle the Icon of native Apps like Chrome?

in your applist.txt I see this: |data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAAABCAYAAABubagXAAAAEElEQVR42mNk+P+/nmEEAwB6pgJ/X9KuVAAAAABJRU5ErkJggg== but where did you got this ID from?

I just want to Display the Chrome Icon

Apologies for the late reply; I took 2 weeks off recently and didn't have a chance to check the forums upon my return to work. :)

There are many ways to load an image when it comes to HTML, and the most common way is accessing a file from a URL. In my example applist.txt, I showed how to load images from the SD card and via a Base64 encoded string.

To achieve your goal, some manual intervention is required. You can do one of the following:

• Generate the app icon images yourself (such as creating or reusing a JPEG/GIF/PNG file) and copy the images to the SD card storage using MobiControl's file transfer mechanisms. You'll then simply modify the applist.txt and reference the right image for your application.
• Base64 image encode your desired image, and copy this string into the applist.txt. The more detailed the image, the larger the string. In this case, you'll have to supply the Chrome app icon image to the Base64 encoder script (see below for methods).

Possible alternate method (theory!): I wonder if Android caches application icons in a separate system directory after installing and reading the APK's manifest.xml. If this is the case, we can then reference the image in applist.txt as long as we have access to the directory.

There are pros and cons with each method:

• Image files
  • Pros: simple, keeps applist.txt neat
  • Cons: need to extract and transfer files to devices, but a simple global sync rule in MC can help. Simply copy all images from a global directory to all devices via sync even if the app isn't installed as there's no harm.
• Base64 strings
  • Pros: self-contained, no need to copy files, great for small images
  • Cons: additional steps involved for conversion, makes applist.txt messy, eventually bloats filesize and possibly affects Kiosk performance

For common Play Store apps, the images are easily available through the web store (right-click -> "Save image as..."). In this case, you'll receive a .webp file format. Converting the image as-is will give you a fairly long Base64 encode string.

Alternatively, you can easily extract the app's icon image via Android SDK's "aapt" tool. Command line as follows:

aapt.exe d --values badging com.android.chrome