Switching user programmatically

Dear Magic Leap community,

As part of our project, it is necessary that the stored user-profiles on a Magic Leap 2 can be changed programmatically. I'm reaching out to you to elaborate the best way possible.

So far I have considered the following approaches.

  1. Via ADB command, sent from a locally running app (as far as I know, the Magic Leap 2 would have to be rooted for this)
  2. Via ADB command over the network
  3. With the help of an MDM
  4. Other possibility, e.g. via Magic Leap SDK / API?

Which approach would you consider to be the most suitable? I only want to root the device as a last resort because it poses a security risk and has a potential impact on Magic Leap's OS updates, etc.

I would be very grateful for any suggestions :slight_smile:

Kind regards,
Julien

Hello again @julien.villiger ,

My response is going to focus on points 3 and 4 and on the assumption you might be pursuing building your own solution rather than doing an off-the-shelf MDM. I leave it up to you to analyze if it is cost effective for your project.

I would start here reading up on the Android documentation around Dedicated devices, effectively that is the only way to access an API surface that allows User management. Dedicated devices overview  |  Android Developers

Effectively you will be writing an MDM app yourself if you want to call APIs on device that allows User management, at the end of the day we are targeting Android 10 behaviors related to this stack and any documentation related to Device Management should be accurate for your reference.

PS I personally would either go with a light open source MDM / pay for one depending on the size of your development team.

Hope that helps,
Mark

1 Like

Hi @mrushton

Big thanks for the useful input. Especially the "Dedicated devices"-approach sounds promising.

As far as I know, the google play services are necessary. Is that correct? And are they supported by Magic Leap?

Kind regards,
Julien

Depends! Android Enterprise provides APIs that exist on device side as well as in google play. Given we have several MDM solutions that avoid the need for cloud services provided by google play I advocate you roll an implementation that doesn't require functionality. Local user management calls off the top of my head DO NOT require Google Play.

Hi @mrushton,

We achieved to implement an app to manage user almost as we had in mind thanks to the links and information you provided. Thanks !

A follow-up question is regarding initial setup of a user. Once we created a user and we switch to it for the first time, the onboarding process triggers with the following steps / Screens:

  • Select Language
  • Information for insert
  • Confirm Profile Name
  • Ask if desired to run Custom fit
  • Ask if desired to set a device lock
  • Ask if desired to enable Voice Commands
  • Inform the setup is complete

Is there a way to skip those ? Like setting the values from the device owner component ?

Thanks for the support !

Cheers

1 Like

@alain.birchmeier Just to confirm what you have tried, in your DevicePolicyManager did you try either of the following:

This isn't specific to Magic Leap but rather Android MDM device but I suspect you can skip / set a lot of relevant fields just following the Android Overview of the android.app.admin classes.

We already use SKIP_SETUP_WIZARD and we don't want to make the user ephemeral :slight_smile:

Thanks for the pointer, I'll go dive into those android.app.admin classes :slight_smile:

@alain.birchmeier Is the main goal to avoid setup wizard completely and leave those fields in their default state? I might split part of this as a Voice of the Customer request for a feature addition to how Magic Leap 2's Out-of-Box Experience (our Setup Wizard equivalent) behaves if the current field behavior isn't enough after configuring those settings.

@mrushton
Excuse me for the delay. We've been aligning with the team regarding this user flow.

To answer your question, yes the main goal is to avoid setup wizard (com.magicleap.oobe/.MainActivity) completely, leaving any fields to their default state.

A bit of context regarding our use case. The target users of our application are people with reduced mobility (tetra- and quadriplegics). We aim to bridge the digital world to those users and we implemented it for inclusivity in mind such that the ones with the most severe incapacity can use it (gaze-only interaction).

To ease the onboarding and daily use for them we also want to remove any frictions which could lead to unfriendly setup.

Our ideal setup would also allow us to set the pin and trigger the Iris ID calibration, as main UI doesn't support gaze-only interaction.

Hi @mrushton,
Any update ? Have you been able to forward this feedback to the ML2 Out-of-Box Experience team ?

@alain.birchmeier The feedback has been forwarded to the relevant parties, I did this shortly after you confirmed my understanding of the request. I'll be looking into the issue with the SKIP_SETUP_WIZARD flag not being respected but I can't confirm exact timelines at this point. For the Voice of the Customer request it would be best to follow up with @kbabilinski in the future once we have had time to size up the feasibility of a Gaze-only interaction vs exposing programmatic hooks.

1 Like