On devices MC2200 with installed Android 11 firmware (BSP) after powering on the device the initialization of MX subsystem takes about 40 seconds (is not possible to use MX during this time). If the device turns itself off due to low battery and then turns it on again after connecting to the power supply, the initialization time of MX subsystem is even 70 seconds!
With Android 10 image the initialization of MX subsystem takes only about 20 seconds.
In our kiosk application we frequently use MX functions and user have to wait an inadequate amount of time before being able to use the device.
11 Replies
Hi,
Please make sure you're using the latest LG / OS Patch for the device. We have made some changes to MX in A11 which may have caused the change in initialisation time. If you can reproduce the issue on the latest OS / LG patch I'll pass this feedback onto our engineering team to get some more detail.
The duration of initialization of MX is with the latest BSP 11-23-13.00-RG-U07 is almost the same.
Here are my results with latest A11 BSP on MC2200:
I had installed 11-23-13.00-RG-U01. Therefore I perform update by HE_DELTA_UPDATE_11-23-13.00-RG-U01-STD_TO_11-23-13.00-RG-U07-STD.zip.
It was done by success.
After first restart immediatelly after performed update the duration of initialization of MX was 5 seconds (wow!).
But after all other restarts the duration revert back to 33 seconds (I measured even 41 seconds).
When device powered off due to low battery and then is connected to power then the duration initialization of MX was even 55 seconds.
Thanks for testing & updating the thread. I've reached out internally to get some more info & will get back to you soon. Thanks!
Hi Jiri,
I've had confirmation that this is expected behaviour due to some changes & abstraction improvements as part of our Skinny Cat program in A11. The average times for MX initialization are:
Thanks,
James
But that's too long. You're not going to do anything about it?
For me, 10 seconds would be acceptable.
In particular, the initialization time after the previous automatic shutdown due to the low battery level is very user-nonfriendly. This happens to users very often when they forget to turn off the terminal.
I can pass the feedback onto our engineering team for consideration. What MX settings are you trying to apply immediately after boot & what is the impact on the user needing to wait 60 seconds?
--What MX settings are you trying to apply immediately after boot--
It's depend on what the user want to do. What operation in our kiosk application user choose.
--what is the impact on the user needing to wait 60 seconds?--
User can't work for this time (and is nervous :)).
First MX operations after device boot can be:
- very often used is UiMgr: ShowVirtualKeyBoard=2 or 1.
- sometimes obtaining serial number by AccessMgr: OperationMode=1, ServiceAccessAction=4, ServiceIdentifier="content://oem_info/oem.zebra.secure/build_serial"
- sometimes enabling/disabling wifi by System: WifiAction=enable/disable
- enabling/disabling packages
- add/remove wifi profile
- and more...
- most of the used MX operations are in this xml file: https://www.transfernow.net/dl/20220721G3M9rK3u/MYmmBkAa
Thanks for the further information, however, wouldn't those settings persist over a reboot? Why would the user be re-configuring the device every time it boots up?
Not all things are reconfigured on every restart, but some of them are used very often:
- When our app show or hide onscreen keyboard so must also set UiMgr: ShowVirtualKeyBoard to 1 or 2. My detailed explanation is here https://developer.zebra.com/content/parametr-show-virtual-keyboard-sett… (our app is controlled by hardware keyboard even if no EditText is showed - this is important for understand). There is also proposed the new mode for ShowVirtualKeyBoard = 3. If you implement it then the pain of slow initialization won't be so great.
- We don't want the wifi network to be permanently powered on (enbled on). We enable it only for short time for concrete tasks.
- The user can update our application at any time or can update himself (important point). ONLY with the help of MX functions can this be done in such a way that NO user interaction is needed (important point).
- Our app is kiosk app - Status bar, Navigation bar and many others things are disabled/changed by the help of MX functions. User which have special password can terminate this kiosk app AT ANY time and go back to a fully functional operating system with the Status bar, Navigation bar enabled etc - for this again MX functions are needed.
In our company we already use older device MC2180 (hundreds of pieces) which runs on Windows CE operating system (with also our kiosk app). This is no longer produced and only devices based on Android are produced now. But Android is more targeted at the consumer user. It is not primarily an operating system intended for devices such as the MC2200. If your MX did not exist, the development of our app would not be possible at all and we would have to switch to a competitor such as Dolphin, where there is a similar MX.
Thanks for the info - I've passed your use-case & requests onto our engineering team for consideration.
Please, do you plan to implement this my proposed functionality https://developer.zebra.com/content/parametr-show-virtual-keyboard-sett…? It would be very useful.