To share virtual devices with a team, choose a reusable setup or access to the same running device first. Prepare the owner, invited people, clean test state and allowed actions. The result should show what was shared, who can use it and how access ends.
These are different tasks. Reproducing an app issue may need a starting setup. Inspecting it together may need the current screen and state. This guide uses Genymotion SaaS as a documented example; no device, recipe or live session was created or shared.
Key Takeaways
- Share a starting setup and share a running instance as separate decisions.
- Inspect test state before making it available to others.
- An invited participant may be able to act, not merely watch.
- Keep the resource owner responsible for ending collaboration.
- Review access and capacity separately from whether an invitation arrived.
Prepare to share virtual devices with a team
Define the job before selecting a sharing control. Does the person need their own test setup, or the state on your current screen? Write the outcome in the invitation notes. "Please check this device" leaves both the resource and allowed action unclear.
Prepare these inputs:
- Owner and exact resource reference.
- Reusable setup or live-session purpose.
- Named recipients and the actions they need.
- Approved app build and nonprivate test material.
- Any current state that must be excluded from sharing.
- End condition and person who checks it.
Use device and operator assignment records to name the owner, not to distribute passwords. Team membership does not grant access to every saved setup. Keep the task and exact resource together so the owner can check the proposed access.
OWASP recommends least privilege and resource-specific authorization. Apply that to the recipe, running instance and permitted action separately. Being signed in is not evidence that someone should receive either resource. OWASP authorization guidance
Choose recipe sharing or live collaboration
The Genymotion SaaS collaboration guide distinguishes custom recipes from Live sessions. A recipe owner can share with named users or organization collaborators. Recipients can launch devices from it; that usage counts against the owner's concurrency limit and metering.
For a Live session, the owner can invite up to four participants to the same virtual device. They can interact with it but cannot save or stop it. This is not a view-only invitation. Keep that documented scope visible when selecting participants.
| Requirement | Sharing route to inspect | Main review question |
|---|---|---|
| Reproduce work from a known starting setup | Shared custom recipe | Is the source setup approved for reuse? |
| Inspect the same current device together | Live session | May every participant interact with this state? |
| Watch without the ability to act | A verified view-only option | Does the selected tool actually enforce that restriction? |
The third row is a requirement, not a claim that Live session provides it. If viewing must be read-only, choose a tool that enforces that. Asking someone not to click does not remove their ability to act.
Check capacity separately. A shared recipe can lead to more launched devices; a live review concerns one current instance. Confirm the provider's limits and billing model. This guide gives no price or measured capacity result.
Steps to share virtual devices with a team
- Select the resource. Match its reference to the approved task. Check the recipe revision or live device, not only a familiar display name.
- Inspect the starting state. Use nonprivate test data. If nobody can explain the saved state, hold sharing until the owner reviews it.
- Choose the audience. Confirm each person and needed action. Sharing with the whole organization needs its own approval; it is not a shortcut for adding one colleague.
- Apply native controls. The owner should use the provider's supported route. Record the shared object and scope, leaving secrets out of the notes.
- Check what opened. Ask the recipient to match the resource and task through approved access. A delivered email alone does not show the correct resource opened.
- Close the right grant. At task end, check each granted resource. Mark live review and recipe access separately, including any approved reason access remains.
Genymotion documents removing Live session participants or stopping the session; stopping the device also ends it. Recipe access has separate recipient controls. Check each resource granted, not one blanket label called sharing ended. Collaboration controls
Verify before you share virtual devices with a team
Use an owned app with a harmless fixture label such as review-start before involving sensitive work. The expected finding for a live review is the intended current instance. For recipe reuse, the question is whether the recipient can start the approved setup. Neither finding proves the other.
A proposed review record should keep these fields separate:
- Resource type and reference checked by the owner.
- Recipient and permitted participation mode.
- Observed resource after opening it.
- Expected task and any mismatch.
- Sharing end action and resulting access observation.
Consider a fictional review where both a recipe and a live instance were shared. The live review ends, but recipe access remains approved for later tests. Record two findings, not one completed switch. These are proposed review fields; mark actual observations untested until inspected.
Review separate client-device boundaries when client accounts are involved. A shared live instance has shared state. It does not give each person a separate account environment.
Limits and failure paths
Unreviewed saved state: pause sharing until the owner checks the source. Genymotion says a recipe can be created by saving a device. That does not prove a saved setup is free of account or private data. Inspect it first. Recipe creation context
Interactive access mistaken for viewing: hold the invitation if view-only access must be enforced. Choose a supported mode that meets that need. A promise not to interact does not change the granted rights.
Credentials in handoff notes: use approved access references instead. OWASP recommends limiting who can read or handle secrets. Ask the owner to resolve recovery needs; a shared task does not justify giving everyone every credential. Secrets management guidance
Moimobi's current mobile workflow integration is paused. This procedure is not a shipped Moimobi sharing demonstration. Use the Moimobi environment evaluation library for broader research, then verify the deployed product before depending on a particular sharing mode.
Frequently Asked Questions
What does sharing a virtual device mean?
It may mean sharing a reusable setup or collaborating on one running instance. Establish which before granting access.
Is a Live session view-only?
Not in the Genymotion mode described here. Its participants can interact, subject to the documented limits.
Does recipe sharing move device ownership?
Do not infer that. Review the resource and access granted rather than treating reuse as an ownership transfer.
Should I share with the whole organization?
Only when the owner has approved that audience. A one-person review does not require a broad default.
Does ending the live review remove recipe access?
Check those grants separately. End the live review and inspect whether any recipe access should remain for the approved task.
Can a saved setup be assumed clean?
No. Inspect the approved test state and data requirements before reuse.
What happens if the wrong resource opens?
Stop interaction, retain the references and ask the owner to correct the assignment before continuing.
Conclusion
Choose the sharing object before inviting the team. A reusable recipe, a live review and a view-only requirement need different checks. Begin with nonprivate fixtures. Confirm what opened and which access grants ended before moving on to sensitive work.
