Inventorying Android devices in GLPI

Inventorying Android devices in GLPI: what it does and when you need it

Mobile inventory in GLPI answers a question most asset registers cannot: which Android phones and tablets hold access to company data, who owns them, and where they sit in the asset record. Enrolling them means bringing devices that are often personally owned or briefly loaned into the same inventory that already tracks laptops and servers. The core answer is that GLPI Agent and the Agent Config plugin can report Android devices into GLPI inventory, but only after you confirm that the current agent and plugin versions support Android enrollment. The researched GLPI Agent documentation describes Windows, macOS and Linux, so do not promise Android coverage in a proposal until the Android-specific pages for both components have been read against the versions you plan to deploy.

GLPI Agent is the component that collects hardware and software data and sends it to GLPI. The Agent Config plugin manages how agents are configured, which matters for mobile devices because you cannot rely on a script or a GPO to reach them. In practice, the planning questions are the enrollment method (for example, QR code onboarding and whether it is tied to a scoped OAuth client), what the device record must contain to be useful, and which entity or location it lands in under your import rules. Confirm each of these with the vendor documentation and a pilot on a small device group before committing to a rollout.

Treat mobile inventory as its own workstream when phones or tablets reach internal mail, file shares, line-of-business apps or privileged tools, or when auditors ask for evidence that mobile endpoints are tracked. It is also worth scoping separately when a meaningful share of the fleet is personally owned, because consent, data boundaries and offboarding steps differ from corporate laptops. If mobile devices are only a minor part of your estate, a simpler list maintained alongside your existing process may be enough. Ask any implementation partner to state in writing which Android features are supported at your agent version, what must be configured in GLPI, and what the client must provide, such as an MDM policy, an OAuth client or device owner records.

Enrollment options and when each fits

This table compares three ways to bring Android phones and tablets into GLPI inventory, measured against fleet size, ownership model and how much of the process the team wants to automate. Read each row for its main trade-off and the points to confirm in the GLPI and Agent Config plugin versions you plan to run, since onboarding behavior changes between releases.

Approach	Best fit	Main trade-off	Confirm in the target version
QR code onboarding	Small to mid-sized fleets of corporate devices where a technician can enroll each unit by hand	Fast to start and easy to supervise, but every device needs someone present and effort grows with the fleet	Which Agent Config plugin screens generate the QR code and what the Android agent expects to scan
Manual enrollment with a token	Mixed fleets, contractor devices or a pilot where an administrator wants a visible approval step	Flexible and auditable per device, but tokens must be issued, tracked and revoked by someone	How token scope, expiry and reuse are controlled, and where enrollment events are logged
Managed device platform feeding GLPI	Large corporate fleets already run mobile device management and want inventory to follow device records automatically	Least manual work once connected, but inventory accuracy depends on the upstream platform and its data mapping	Which fields the platform can export or push, and whether GLPI accepts them without custom import rules
Corporate-owned devices	Organization-controlled phones and tablets where the agent can be deployed under company policy	Full visibility into hardware and software, which must be justified to staff and documented in your privacy notice	Which inventory attributes the Android agent collects on your device models and OS versions
Personally owned devices	Bring-your-own-device programs with limited enrollment scope	Collection is narrower and staff consent and data protection rules apply, so coverage is usually partial	Consent workflow, what data is collected and whether an OAuth client can be limited to inventory only
Scoped OAuth client	Any approach that lets the Android agent reach GLPI without broad API access	Tighter access control, but an extra object to create, rotate and document	How the client scope is set in the GLPI API settings and how rotation is handled

How to set up Android inventory in GLPI

This sequence takes an Android fleet from an unconfigured GLPI instance to devices that report into the correct entity with the fields your team relies on. Each step closes with a check, so problems surface on a pilot group before the whole fleet enrolls.

Confirm GLPI version and plugin compatibility
Record your GLPI version and the Agent Config plugin release that supports it, using the plugin's own documentation as the source. Confirm which GLPI Agent version your Android devices will run, and check whether the plugin depends on other plugins that must already be active. Your GLPI administrator owns this check. It is done when you have a written version pairing that the administrator has signed off on, and when every open question has a named owner.
Install and activate the Agent Config plugin
Install the Agent Config plugin using the same method your team uses for other GLPI plugins, then activate it from the plugin list. Open its configuration page as a super-administrator to confirm that it loads without errors. Review the GLPI logs for warnings from the plugin during activation. The step is done when the plugin shows as active, its settings page opens, and the logs are clean after a page reload.
Create the scoped OAuth client
Create a dedicated OAuth client in the GLPI API configuration and limit it to the rights that enrollment needs. Do not give it full administrator access, and do not reuse a client that other integrations already depend on. Store the client identifier and secret in your password manager and record which account owns the client. Test the client with a token request and confirm that it returns a token for the scoped account only. Confirm the exact rights and token behavior in the plugin documentation for your version.
Generate the enrollment QR code
Generate the enrollment QR code from the plugin configuration, using the client you created and the GLPI server address that phones will reach. Confirm that the address is HTTPS, that devices can resolve it, and that they trust its certificate, since a code pointing at a name mobile devices cannot reach will not enroll. Treat the code as a credential: keep it out of shared documents and check the plugin documentation for expiry and regeneration options. The step is done when a test device on a separate network path enrolls from the code.
Onboard a pilot group
Enroll a small pilot group that covers the device models, Android versions and user roles in your fleet. The IT team owns this step, and the pilot users should be told what the agent collects before they scan. Keep a list of enrolled devices with their owners and models so you can compare it against GLPI later. The step is done when every pilot device has reported at least once and no device is enrolled twice.
Verify entity and fields on pilot devices
Check that each pilot device lands in the expected GLPI entity and that the fields you depend on populate correctly, such as model, operating system version, assigned user and serial number where the platform exposes it. Compare the results against the list you kept during onboarding. If devices land in the wrong entity or fields stay empty, review the inventory import rules before enrolling more devices. The step is done when the pilot results match the expected values for every device.
Build plugin reactivation into updates
Add plugin reactivation to every GLPI update runbook. GLPI 11 suspends plugins after it detects a new version, and they must be reactivated after major updates, so the Agent Config plugin will stop working until someone reactivates it. Before updating, back up the database, the files and the config directory, including glpi.key and glpicrypt.key, as the update documentation describes. Record the active plugin list beforehand and compare it afterward. The step is done when the post-update checklist confirms the plugin is active and pilot devices still report.

How the enrollment and OAuth pieces fit together

The GLPI administrator owns the instance side of enrollment. This work starts in the plugin configuration, where the mobile agent settings, the target entity and the import rules that decide where each device lands are defined. Once a phone reports in, its inventory payload enters GLPI and passes through the same rule engine that processes data from other agents, so the rules must be planned for mobile device types as well as computers.

Plugin setup: Install and activate the Agent Config and GLPI Inventory plugins, and confirm both are compatible with your GLPI release before enabling anything.
Entity assignment: Decide which entity receives mobile devices so ownership and access follow your existing organizational tree.
Import rules: Define rules that match device identifiers, assign the correct asset type, location and group, and set conditions for devices that should be ignored.
Agent configuration: Set the server URL and the tags or profile that enrolled phones use, and keep them separate from desktop settings where your policy differs.

Confirm the exact menu paths and rule criteria against the plugin release you install, because these details change between versions. The GLPI Agent documentation is the natural starting point for agent behavior.

Securing the OAuth client and enrolled devices

The Android enrollment path touches three things an attacker or a careless administrator could abuse: the OAuth client that lets devices talk to GLPI, the traffic that carries inventory, and the phones themselves. The cards below cover each of these, plus who is allowed to change enrollment settings in the first place.

Scope the OAuth client tightly

Create a dedicated OAuth client for Android enrollment rather than reusing an administrator client or a client shared with other integrations. Grant only the API scopes that inventory submission needs, and confirm in the GLPI OAuth2 API configuration exactly which scopes the client receives. Record the client's owner, purpose and the enrollment profiles that depend on it, so that a later audit can match each client to a business reason.

Store and rotate the client secret

Keep the client secret in a secrets manager or a restricted configuration store, never in a shared document or a ticket comment. Plan a rotation schedule and test it in a non-production instance first, because rotating the secret invalidates the enrollment configuration on every device that depends on it. Ask your implementation partner to document the exact steps to rotate, verify a new token and revoke the old one.

Enforce TLS for all agent traffic

Agents must reach GLPI over HTTPS with certificates that the Android device trusts, including any private certificate authority your organization runs. Check that the enrollment QR code or configuration points to the correct HTTPS URL and that plain HTTP endpoints are closed. Confirm how the Android client validates certificates for your chosen agent version, and test a device on a network you do not control.

Define the personal device policy

Where employees enroll personal phones, decide in writing which inventory fields are collected and which are not, and whether the agent can read data outside work contexts. Agree how personal device records are labeled in GLPI and who can see them. Involve HR, legal and your privacy function before the first QR code is issued, since their requirements shape the collection scope more than the technical setup does.

Remove lost and retired devices

Define what happens to a device record when a phone is lost, reassigned or returned. Decide whether the GLPI asset is marked, moved to a retired status or deleted, and whether the OAuth access for that device is revoked. Without a defined process, stale mobile records accumulate and inflate asset counts. Confirm with your team which status values and transitions your GLPI instance uses before the enrollment rollout starts.

Audit enrollment setting changes

Limit who can edit the Agent Config plugin settings, the OAuth client and the enrollment profiles, and map those rights to named roles. Review the GLPI logs for changes to these objects on a regular schedule, and confirm that administrators cannot change them without a traceable record. Ask your partner to show where these events appear in your instance so that a reviewer can find them without help.

Keeping Android inventory accurate after go-live

Accuracy after go-live depends on handling two kinds of drift: devices that stop reporting and devices that report under a new identity. A phone that is wiped, replaced or re-enrolled can appear in GLPI as a second asset while the original record stays active. That inflates device counts and splits ownership, software and ticket history across two entries. Set a recurring review of Android assets that have not reported recently, and decide in advance who merges or retires duplicates and which record is kept as the source of truth. Use a test enrollment to confirm which identifier the inventory uses for a re-enrolled device, because that determines whether a duplicate is created at all. Write the review interval down with a named owner, and base it on your own device turnover policy.

GLPI configuration is the second risk. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so an upgrade can quietly stop the Android collection path until someone turns the plugin back on. Before any update, back up the database, the files and the config directory, including glpi.key and glpicrypt.key, as the GLPI update documentation requires. Keep copies of the agent configuration and the OAuth client definition in your change records as well. Confirm with the plugin documentation which settings are stored encrypted, so you know what a restored backup can and cannot bring back on its own.

After each GLPI upgrade, run a short checklist before closing the change. Confirm that the Agent Config and inventory plugins are active, check that the scoped OAuth client still authenticates, and enroll one test device to see a fresh record arrive. Compare the number of Android devices that reported in the last reporting window with the number recorded before the upgrade, and investigate any large drop. Treat a plugin that failed to reactivate as a blocking issue, not a follow-up task. Ask your engineers or DeployOpen to confirm the exact console steps for your GLPI and plugin versions before the first upgrade window, since release-specific steps can change.

Limits to confirm in your environment

Android enrollment depends on several moving parts: the agent, the Agent Config plugin, the GLPI release and the OAuth scopes it needs. Each limit below should be confirmed with the vendor or proven in a pilot on a small device group before you roll out to the full fleet.

Android version support

Confirm which Android versions the GLPI Agent build you plan to use supports for inventory collection, and which of your current device models run those versions. Older or heavily customized releases from some manufacturers may report fewer fields. Test on a representative sample of each model family you own, including tablets, and record which fields arrive and which stay empty.

Plugin and GLPI release match

Check that the Agent Config plugin version you intend to install is built for the exact GLPI release in your environment. Plugins are suspended after a new GLPI version is detected, so a mismatch can block enrollment after an upgrade. Ask the plugin maintainers which GLPI releases each version supports, and rerun the onboarding test after every GLPI update.

Managed versus personal device fields

Decide which inventory fields you need for corporate-owned phones and which you are willing to collect from personal devices under bring-your-own-device rules. Some hardware and software details may be visible only on managed devices, and privacy obligations in your jurisdiction may limit collection on personal ones. Document the field list per device ownership type and get sign-off from HR and legal before onboarding begins.

MDM coexistence

Identify any mobile device management product already enforcing policy on your phones and confirm whether it blocks, restricts or overwrites the GLPI Agent installation or its background permissions. Overlapping inventory sources can also create duplicate asset records. Test the enrollment path on a device that is already under MDM control and agree which system is the source of record for each asset attribute.

OAuth scopes in your GLPI version

Verify that the scoped OAuth client used for QR code onboarding supports the exact scopes the enrollment flow requests in your GLPI release. A scope may be missing, named differently or unavailable in older versions. Ask the vendor for the scope list per release, then confirm that a client limited to those scopes can complete enrollment and nothing beyond it.

Questions teams ask before enrolling Android devices

What drives the cost and effort of an Android rollout in GLPI?

Cost follows the number of devices, the number of enrollment groups and how much of the surrounding GLPI setup must be built first. Your team or a partner pays for scoping, GLPI configuration, Agent Config plugin setup, the OAuth client, test devices and end-user documentation. Recurring costs are mostly staff time for onboarding new hires, handling lost or replaced phones and reviewing inventory data, plus any GLPI subscription or hosting you already carry. The main drivers are the number of device models and Android versions in use, the number of entities or departments that need different rules, and whether personal devices are included. Ask for a quote that lists each of these as a separate line item.

How long does an Android inventory pilot take?

A pilot runs until you have shown enrollment, inventory accuracy and removal on a set of devices that reflects your fleet, and no fixed length applies. Several factors set it: how many Android versions and manufacturers you include, whether the QR code onboarding flow and the scoped OAuth client behave consistently across your device policies, and how quickly administrators can review and correct the records that arrive in GLPI. Pilot length also depends on whether you test with corporate devices only or add a small group of personal devices, which brings consent and policy questions. Agree on exit criteria in writing before the pilot starts, such as required fields and the entity each device should land in. Ask any provider to state the pilot duration and those criteria in the statement of work.

What must our team provide before Android enrollment work starts?

Your team provides the devices for testing, GLPI administrator access to install and configure the Agent Config plugin and the OAuth client, and a named owner who can approve changes. You also need a decision on personal devices, a list of device models and Android versions in use, and the network path from phones to your GLPI server, including any reverse proxy or certificate chain the agent must trust. Provide a test group that can enroll and unenroll freely, along with access to the entities and profiles where devices will be placed. Without these, work usually stalls at the first access request. Confirm who owns the database and file backups before any configuration change, because GLPI's update procedure begins with backing up the database, files and configuration keys.

Should personal Android phones be enrolled in GLPI inventory?

Personal devices should only enter inventory when your policy covers them, because device ownership changes what data you can collect, who may see it and how it is removed. Decide which data the agent may read, how users give consent, who can view the records in GLPI and what happens when someone leaves the organization. Corporate-owned devices are simpler because your organization sets the enrollment policy, retention rules and offboarding steps. Personal devices add review by your privacy or legal function and often call for separate entities or restricted profiles in GLPI. Make this decision before the pilot, since changing it later means reworking records and rules. Confirm the position with your data protection function before you finalize the scope.

Can an in-house IT team enroll Android devices in GLPI without a partner?

Yes, an in-house team can do it if it has GLPI administration skills, someone who can run the mobile enrollment flow, and an owner for ongoing agent upgrades and inventory rules. The work is mostly configuration and testing rather than custom code, so skill gaps usually sit in GLPI's rule engine, OAuth client handling and the Android device side of enrollment. Check your team against that list before deciding. A partner makes sense when the team lacks time for the pilot, needs documented evidence for an assessment, or must coordinate enrollment with other GLPI workstreams at the same time. DeployOpen plans and implements self-hosted GLPI inside your infrastructure and documents the result, under a written scope agreed before work begins.

How does Android inventory differ from a Windows agent rollout?

Windows rollouts often push a package to machines your organization already manages, while Android enrollment depends on the device owner, the enrollment method and the account the phone uses. GLPI Agent runs on Windows, macOS and Linux according to its documentation, so the Android path uses different installation and identity steps even though data flows into the same GLPI inventory. Expect more variation in Android versions, manufacturer behavior and user-driven setup, and less control over timing. Windows deployment usually relies on distribution tools you already run, while Android onboarding depends on the QR code flow and the scoped OAuth client you configure. Confirm the current Android support and steps in the GLPI Agent documentation before you plan the rollout.

What a fixed-scope Android inventory engagement covers

A written scope for Android inventory starts with decisions that only your organization can make: which device types are in scope (company-owned phones, tablets, or personally owned devices enrolled under a work profile), which attributes must reach GLPI as asset fields, who owns the GLPI entity and profile that receives the devices, and who approves the enrollment flow before it reaches users. The statement of work should then list the GLPI configuration to be changed, including the GLPI Agent settings delivered through the Agent Config plugin, the scoped OAuth client design, the QR code onboarding steps, and the pilot group with its exit criteria. Documentation and handover, meaning runbooks for enrolling and retiring devices and a record of every configuration key set, should be named as deliverables rather than left as an assumed side effect.

Most of the cost is one-time: requirements, configuration, OAuth client setup, pilot enrollment and documentation. Recurring cost sits in plugin maintenance when GLPI and its plugins move to new versions, since GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates, as described in the GLPI installation docs on updates. Device churn is also recurring: each new phone, reissued device or retired handset changes the enrollment and cleanup workload. Ask any quote to separate these lines, to state who maintains the OAuth client secret and its rotation, and to say whether the pilot is included or priced as an option.

When you request quotes, ask for the scope in writing with named responsibilities for your team and the partner, the list of GLPI and plugin versions the work targets, and an explicit statement of what happens if a plugin is incompatible with the GLPI release you run. Ask how acceptance is tested on real devices from your fleet, not only on test handsets, and how many devices the pilot covers. Confirm with the plugin documentation whether a given Android enrollment option is supported in your GLPI version before accepting a timeline. Illustrative example: a pilot of a few dozen devices might reveal a naming rule gap that is cheaper to fix before the full rollout than after it.

Inventorying Android devices in GLPI