An Android shared device brief describes what happens when more than one employee uses the same work phone or tablet. A Kenyan business may have a dispatch phone, a warehouse tablet or a service counter device used across shifts. The app needs to make the current operator, unfinished work and next handover clear.
Discuss those requirements with an Android app developer in Kenya before approving a login screen. Sharing hardware does not mean that everyone should share the same business identity or have access to the same records. A workable handover includes both the software behaviour and the staff process.
The scenarios below are illustrative requirements, not a description of a particular deployed Mocky application. Use the app portfolio to review available examples, then prepare a brief around your own operations and supported devices.
Map the people and physical device handovers
List who uses each device, where it stays and which tasks it supports. A tablet that remains at a staffed counter has a different handover pattern from a phone carried between field workers. Record whether devices leave the premises and who is responsible for returning and charging them.
Describe when the operator changes. This may happen at the end of a shift, during a break or when a supervisor takes over an exception. Avoid assuming that sign-out occurs neatly after every completed task. Real handovers can happen while a form, upload or stock check is unfinished.
Name a business owner for the process. The developer needs decisions about permitted work and responsibility, while operations staff need a routine they can follow. Leaving either side undefined can encourage people to stay signed in under a colleague's account because it seems easier than completing the handover.
Choose the management model deliberately
Decide whether the requirement is an ordinary app on a shared phone or a managed device dedicated to work. These are different deployment discussions. Restricting a tablet to a particular set of apps requires more than adding a custom sign-in screen to your business software.
Android's dedicated device guidance describes fully managed devices for specific purposes, including employee workflows and kiosks. It discusses capabilities such as lock task mode and managed users, with administration requirements. Ask the implementation team which approach applies to your devices and how it will be provisioned.
Do not promise that any downloaded app can automatically control the whole phone. Record device ownership, management responsibilities, supported hardware and any provider involved. Include setup and ongoing management in the quotation where needed, rather than discovering after delivery that staff must configure an entire fleet themselves.
Separate device identity from the operator
Give the device a stable inventory reference and the staff member an appropriate individual account. These identify different things: which hardware was used and who performed the business action. A shared device name should not become the only explanation for a sensitive change.
Specify how the app shows the current operator. A visible name or role near important actions can help staff notice when they are using the wrong session. Decide how much identifying information is appropriate for the working environment, especially if customers can see the screen.
Define the tasks each operator may perform. Viewing assigned jobs, completing a checklist and approving a financial adjustment are separate responsibilities. Ask the developer to explain how the server checks authority. A device remaining in a particular room is not a substitute for checking whether the signed-in person may change a record.
Decide what happens to unfinished work
List the temporary information each task creates: entered text, selected items, photographs, pending submissions and local drafts. Decide what should happen when the operator signs out or the device changes hands before the work is complete.
Possible choices include submitting an approved handover, saving a draft for its original owner or discarding a task after a clear warning. Choose according to the actual business process. Do not silently expose the previous employee's draft to the next person merely because both use the same phone.
Treat uploads and queued actions explicitly. A transfer may still be in progress when someone attempts to leave the session. The attachment upload brief covers transfer and receipt requirements. Add the separate rule identifying who owns that transfer and whether it may continue during an operator change.
Specify the next user's starting state
Write what a new operator should see after signing in. The starting screen should reflect that person's authorised tasks and records. Review search history, recently opened items, cached images and temporary messages as well as the main dashboard.
A successful sign-out message alone does not demonstrate separation. Ask the developer to show what remains accessible through back navigation, a reopened screen and a new session. Include the device's normal app switching behaviour in the agreed test plan so the review reflects how staff actually use it.
Decide which convenience settings can remain shared. A preferred printer or branch selection may reasonably belong to the device, while private task content may belong to the operator. Record that distinction. Clearing everything indiscriminately can interrupt work, while retaining everything can expose information to the wrong person.
Plan lost connections and interrupted shifts
Describe what staff should do when they cannot reach the server during handover. Do not assume the app can safely switch users and reconcile every queued action without design work. Identify which operations must wait for a connection and which can continue under the agreed model.
For a queued action, record its original operator and intended business record. Ask how a later upload will be checked if that person's role changes before synchronisation. A task created earlier should not automatically acquire the new operator's authority because the hardware has changed hands.
Use the offline requirements guide for the broader connectivity plan. This shared-device brief adds a narrower question: how identity and unfinished information remain understandable when both connectivity and the operator change. Test that combination instead of approving each feature separately and assuming they will work together.
Give supervisors a controlled recovery route
Define what happens when an employee leaves without completing the handover. Staff need an authorised escalation path for a locked session, forgotten access or a device that contains unfinished work. They should not need a shared administrator password to continue the shift.
Record who can investigate and which evidence is useful. A device reference, approximate time and task status may be enough to locate the issue. Avoid including passwords, private customer content or entire device exports in ordinary support messages.
Discuss lost and stolen devices with the responsible management provider. Identify the contact and the approved response process without assuming that app sign-out alone controls every copy of information on the phone. Keep account recovery and device recovery understandable as separate operational responsibilities.
Review a complete shift transition in testing
Use fictional staff accounts and harmless records in an isolated environment. Have one operator start and complete a task, begin another, then follow the proposed handover. Have a second operator sign in and attempt both permitted work and access to information that should remain unavailable.
Include a connection interruption, an app restart and a role change in the agreed scenarios. Record the visible result and the stored business outcome. A clean-looking screen is not sufficient if the server attributes the previous operator's pending action to the next employee.
Ask the reviewer to explain what happened without reading technical logs. They should be able to identify the current operator, the owner of unfinished work and the person responsible for resolving an exception. If that explanation is unclear, revise the workflow and labels before expanding it to more devices.
Prepare the handover material for staff
Create a short shift checklist: finish or save work using the agreed method, confirm submission status, leave the account correctly and pass the physical device to the responsible person. Adapt this to the actual implementation instead of writing instructions for features that have not been built.
Keep a device register and a support contact. Record training and update responsibilities so that new staff receive the current instructions. Review the process after an operational change, such as moving a tablet to a different branch or introducing a new role.
Before requesting a quotation, prepare the device list, operator roles, unfinished-work decisions and management expectations. Request an app development discussion with those materials. Ask for shift-transition acceptance and staff handover to be included alongside the core app features.
Frequently asked questions
Does shared hardware require a shared login?
No. Device ownership and the identity performing business actions are separate requirements. Discuss individual access and practical handover with the developer.
Can the next operator finish a colleague's draft?
Only if the business workflow and implementation explicitly allow that transfer. Define ownership, permitted changes and attribution rather than treating every local draft as shared.
Is a kiosk app the same as a normal staff app?
No. A managed dedicated device introduces provisioning and administration decisions. Confirm the supported approach and responsibilities before purchasing hardware or approving the scope.
Will this guarantee app store approval?
No. Operational planning does not guarantee distribution approval. Review the distribution route and its current requirements separately when preparing the release.
