In a mixed fleet, the same action does not behave the same on every box. The most concrete difference is updates: they are silent on boxes where the agent is a system app or has root, and they ask for confirmation on screen on certified ones. The solution is to treat each model as a group with its own rules.
Almost no real fleet is homogeneous. Generic boxes are bought for price, a few certified ones are added for reliability or at a customer's request, and two years later there are four or five models from different manufacturers living together. Managing them as if they were all the same is the source of most operational problems.
What they have in common
The good news is that monitoring is the same for all of them. Every box with the agent installed reports its status every 15 minutes regardless of type: model, Android version, CPU, memory, disk, temperature, network and installed apps. That common base is what lets you compare them in a single dashboard.
What changes by box type
- Generic (white-label) boxes. With the agent as a system app or with root, updates and app operations happen in the background, with the user seeing nothing. They are also the ones that most often ship with factory-preinstalled software, so this is where per-app usage is most worth watching.
- Certified boxes (for example onn or ZTE). Updates are not silent: they ask for confirmation on screen. That makes them slower to update and requires someone on the user side or on site to accept them.
And on both, the real screenshot depends on how the agent is installed: with a system app or with root you get the image; with the agent as a user app you receive a diagnostic board with the device status. The details are on the compatibility page.
App rules per model
Define what gets installed, uninstalled or eradicated for the whole fleet or only for one model.
How to segment: one group per model
The practical unit of management is the model. Each has its own Android version, hardware quirks and way of updating. In AdminSTB you can define which apps are installed, uninstalled or eradicated (uninstalled and disabled) for all your devices or only for one model, and the model's rule takes priority over the general one. That lets you, for example, eradicate a preinstalled app that appears only on one generic model without touching the rest.
An update policy per group
- Generic with system app or root: update whenever it suits you, in batches, without coordinating with anyone.
- Certified: plan the update with whoever is on site or with the user, because someone needs to confirm. Avoid launching it at peak usage hours.
- Generic with the agent as a user app: they behave like the certified ones: they ask for confirmation. If you can, it is worth moving them to a system app.
Common mistakes
- Expecting an update to reach every box equally. On certified ones it sits waiting for someone to accept.
- Measuring the fleet as an average. A health average hides that an entire model has problems. Look by model.
- Assuming the install type. Not every box of the same model has the agent installed the same way. Check each one before promising a capability.
What to do now
- List your fleet's models and mark which are generic and which certified.
- Note how the agent is installed in each group: system app, root or user app.
- Define an update policy per group and, if needed, an app rule per model.