FARMDevice lifecycle and maintenance for a reliable phone fleet
Keep phone environments usable through provisioning, health checks, app updates, troubleshooting, replacement and retirement with a worked maintenance example.
A phone fleet changes every day, even when nobody buys another device. Apps update, sessions expire, local storage fills, a teammate leaves, and a once-useful account stops needing daily attention. Device lifecycle management is the process of keeping each environment useful from its first setup to its final handoff or removal.
For PhoneFarm users, the practical objective is continuity: the next operator can reach the intended phone, identify the correct account, find the approved media and understand unfinished work. PhoneFarm's Phones, live control, Videos, Publish jobs and Proof reports support those checks. The maintenance record described here is your operating worksheet; this guide does not assume a separate PhoneFarm monitoring API, automatic backup or retirement control.
Give each phone a purpose and a known starting state
A baseline is a recorded configuration that has passed the task you intend to perform. It is more useful than “setup completed,” because it explains what was working and under what conditions.
A publishing phone may need a persistent account session, approved media access and a predictable operator handoff. A phone used to test your own app may deliberately start with fresh test data. Resetting the publishing phone after every task would discard continuity; reusing all the data on the test phone could hide a first-run defect. Choose the state from the job.
| Baseline field | Fictional example | Why it matters later |
|---|---|---|
| Phone identifier and purpose | PF-NL-03, Northline product tutorials | Identifies the resource without relying on a screenshot's position in a list |
| App and visible account | TikTok, @northline.example | Separates device access from correct-account access |
| OS and app version | Record the versions shown on the phone | Helps compare an affected device with one that still works |
| Network arrangement | Assigned customer proxy record NET-03 | Makes network changes traceable without copying credentials into a shared sheet |
| Media and work state | Tutorial v4 available; no unresolved submission | Prevents accidental repeats after maintenance |
| Last successful check | September 17, 10:20 PDT; profile and media preview opened | Shows freshness and exactly what was established |
| Recovery responsibility | Brand owner plus authorized backup | Avoids making one operator the only route back into the account |
Keep passwords, proxy secrets and recovery codes in the appropriate secure system. A worksheet needs a reference and an owner, not the secret itself. Use the account inventory for the account-to-phone mapping.
In the current documented cloud-phone setup, customers supply their proxy configuration. PhoneFarm does not include a dedicated IP. Record the actual arrangement for your service instead of assuming every phone has an included or unique exit address.
Accept a phone by completing a small, observable task
Before assigning routine work, open the phone from Phones and connect to live control. Confirm that the screen changes when you use a harmless control such as Home. Open the intended app, inspect the visible profile, and check that the required page or media picker opens.
Then verify the task's inputs. If the workflow publishes a video, confirm the correct asset version can be previewed and is available at the stage where the app needs it. A file in Videos is a library asset; it does not alone establish that the phone has received it or that a post exists. Follow the first-post walkthrough when a real publication is part of the approved acceptance task.
Write the result as “profile X and video Y opened on phone Z,” rather than “everything works.” A completed preview establishes readiness for that step. A verified published post establishes a different, later outcome.
For owned physical phones, also record the model, storage capacity, charging/data connection, manufacturer support window and any existing damage. Before buying used devices, resolve ownership locks and confirm the necessary OS and app compatibility. A low purchase price is poor value if the phone cannot enter your required baseline.
Decide where maintenance responsibility belongs
A home or office fleet gives the team direct access to cables and phones, but someone must respond when power, internet or a handset fails. A colocated or hosted fleet changes that responsibility; it does not automatically establish redundant power, faster repair or unlimited bandwidth. Ask who can physically replace a device, the expected response window, how access is controlled, which network dependencies are shared and what happens during an outage.
Compare locations using your required availability and recovery time. A daytime internal test bench can tolerate a different support arrangement from a time-sensitive publishing operation. Record who handles the phone, host, network and application layers, because those responsibilities may belong to different people or providers.
Monitor useful outcomes and their freshness
A heartbeat is a periodic signal that a component is still responding. It can help distinguish a silent device from one reporting regularly, but it only tests the component that sends it. A host heartbeat cannot prove that a phone's app is logged into the intended account.
Use available product states and your own observations to track separate layers:
| Observation | What it tells you | What it does not establish |
|---|---|---|
| Phone listed as running | The service reports a running environment | Usable control, correct network or account readiness |
| Recent screen response | The current control session responds | Successful publishing or unrestricted account access |
| Intended app/profile opened | That account was accessible at the observation time | That the next action is eligible or will succeed |
| File preview completed | That asset was readable at that stage | Delivery to another stage or public publication |
| Job and proof inspected | Recorded workflow progress or evidence | Public visibility unless the actual destination was checked |
Track repeated interventions, failed tasks by stage, task duration and unresolved outcomes. Add storage, battery or temperature observations only where the equipment or service exposes meaningful data. These are useful fleet metrics, not a claim that every field appears in the PhoneFarm dashboard.
Compare measurements with the same kind of work. A ten-second profile check and a large video transfer have different normal durations. Set investigation thresholds from your baseline and service needs, rather than importing a universal “healthy phone” number. Always preserve the observation time: yesterday's successful connection does not settle today's incident.
Update a representative phone before changing the fleet
Treat an update as a change to a working configuration. Android system updates and user-installed app updates are separate mechanisms; the Android project's OTA overview explains the system-update scope. Record which layer changed before diagnosing the result.
A practical canary is one representative environment used to discover problems before applying the same planned change more widely. If you control update timing, choose a phone with the relevant app, permissions and task type. Record the old configuration, resolve any unfinished publication, apply the update through the supported process, and repeat the baseline task.
Inspect login state, media permissions, file selection, captions, navigation and the actual final result where publication is authorized. A successful app launch is too narrow if the operation depends on selecting a video. Expand to a small group only after the representative task works. For a hosted phone, coordinate update responsibilities with the provider rather than assuming you control its system image.
Keep a recovery option before the change: original assets, current account recovery access, task records and a known working alternative where available. Do not assume an OS downgrade, restored app session or full-device backup will be available. A recovery plan can mean using another verified environment while support investigates; it need not mean reversing every update.
Diagnose one failure before repeating the repair everywhere
Start with the last successful observation and the first failed step. Then compare the affected phone with another relevant phone.
- Control fails before the app opens: follow phone connection troubleshooting. Separate the control session from the phone's own network access.
- Several phones fail together: compare shared network arrangements, asset batches, app versions and service incidents. Replacing every phone can leave the common cause untouched.
- One account fails while another opens: inspect the account notice and login recovery path before changing infrastructure.
- A submission may have succeeded: inspect the destination and publication evidence before repeating the action.
- The device has repeated resource or hardware problems: remove it from new assignments in your operating plan, preserve unfinished work and arrange diagnosis with the responsible provider or equipment owner.
Start with the narrowest repair supported by the evidence. Clearing app data or resetting a phone can remove the state that would explain the failure. Google explicitly notes that a factory reset erases local data and removes apps and their data; recovery depends on what was actually backed up and the necessary account access.
A worked maintenance example
Northline has six publishing phones. After an app update on PF-NL-03, its operator can open the correct profile but the media picker shows no usable video. The other five phones still complete the same preview.
The team records the app version and the exact permission message on PF-NL-03. It confirms the source asset still previews in Videos, then checks phone delivery and the app's media access. It does not conclude that the customer proxy is broken merely because publication stopped.
In this fictional case, the app's media permission needs to be reviewed and granted by the authorized operator. After that change, the operator reopens the picker and previews the intended asset. The team completes its approved publication and verifies the resulting post. Only then does it continue the planned app updates on the remaining phones. The useful lesson is the tested sequence; permission changes are one possible cause, not a universal explanation for missing files.
Replace or retire a phone without losing the operation
Replacement is appropriate when a resource no longer meets the required task reliably, cannot run supported software, or costs more operator time than a suitable alternative. Use observed failure frequency and total operating cost. There is no single lifespan that fits every model, workload and support policy.
Before removing a phone, reconcile pending jobs and uncertain publications. Preserve original media, necessary business records and account recovery access. Move only the accounts and workflows you actually intend to continue, then verify them in the destination environment. Record the final account assignment so the next operator does not continue using the old phone.
For equipment you own, follow the manufacturer's supported transfer and data-erasure procedure after the required records are preserved. For hosted resources, confirm the provider's removal, retention and access-revocation process. Data removal, account closure and service cancellation are different decisions; completing one does not prove the others occurred.
Finally, check the billing arrangement and retain confirmation of the requested service change. If the appropriate control or policy is unclear, contact support with the resource identifier and desired outcome. A useful lifecycle record ends with a verified handoff or closure, not simply a phone disappearing from a team spreadsheet.