In recent years, teams working with Android device sanitization have increasingly encountered cases where the IMEI (International Mobile Equipment Identity) cannot be retrieved automatically. This is typically not a single-device anomaly, but the result of Android privacy changes and OEM-specific security hardening.
1. Android 10 (API 29) and later: tighter access to non-resettable identifiers
Starting with Android 10, access to non-resettable device identifiers (such as IMEI and serial numbers) has been restricted as part of Android’s privacy protections. In many cases, IMEI access is no longer available to regular applications and may require privileged/system-level capabilities.
Reference: AOSP “Device identifiers”: https://source.android.com/docs/core/connect/device-identifiers
2. Why ADB / service call approaches are increasingly unreliable
Some environments historically used ADB shell commands or internal service calls (e.g., service call iphonesubinfo) to retrieve IMEI. However, these paths are unofficial and unstable, and behavior can vary by Android version, security patch level, and OEM implementation. As a result, newer builds more often return empty results or errors.
3. OEM-specific debugging/security settings
Some OEMs and Android variants (e.g., MIUI/HyperOS) add additional security toggles beyond standard “USB debugging,” which can restrict what can be accessed via ADB. In practice, missing one of these settings may lead to incomplete device information retrieval.
4. Practical summary
- On Android 10+, automatic IMEI retrieval is generally harder by design
- ADB/internal commands are device/build-dependent and not guaranteed
- OEM settings can affect the workflow significantly
5. How MASAMUNE Erasure addresses this reality
MASAMUNE Erasure is designed so that sanitization work can proceed even when automatic IMEI retrieval is limited by platform policy. We continuously maintain compatibility with newer Android versions and devices, and provide operational guidance for common on-site issues.
We recommend confirming USB debugging, any OEM-specific security toggles, on-screen authorization prompts, and using the latest version of MASAMUNE Erasure.
6. Notes
On non-root, standard ADB environments, automatic IMEI retrieval can be significantly restricted by design, and manual input may be required depending on the device and OS build. While some privileged configurations may allow access, this should not be assumed in general operations.
Contact: If you need guidance for your device mix and operational environment, please contact our support team.
近年、Android端末のデータ消去や端末情報取得の現場で、IMEI（International Mobile Equipment Identity）の自動取得ができないケースが増えています。これは個別端末の不具合というより、Android OSのプライバシー仕様変更と、メーカーごとのセキュリティ強化の影響によるものです。
1. Android 10（API 29）以降：IMEIなど非リセット識別子へのアクセス制限
Android 10以降、Googleはプライバシー保護の観点から、IMEIやシリアル番号などの非リセット（non-resettable）識別子へのアクセスを段階的に制限しています。一般的なアプリ権限だけではIMEI取得が困難となり、システムアプリ等の特権が必要になるケースがあります。
参考: AOSP（Android Open Source Project）「Device identifiers」: https://source.android.com/docs/core/connect/device-identifiers
2. ADB / service call による取得が不安定化する理由
過去には、ADB経由のシェルコマンドや内部サービス呼び出し（例: service call iphonesubinfo）でIMEIを取得できる場合がありました。しかし、これらは非公式・非安定な経路であり、OSバージョンやセキュリティパッチ、端末実装差により挙動が変わります。そのため、最新OS/最新ビルドほど「取得できない」「空が返る」「エラーになる」などの事象が増えやすくなります。
3. メーカー独自のデバッグ/セキュリティ設定の影響
メーカーやOSカスタム（例: MIUI/HyperOS 等）によっては、USBデバッグとは別に追加のセキュリティ設定が存在し、ADB経由のアクセスが制限される場合があります。現場では、設定が不足していると端末情報取得が不十分になり得ます。
4. 現状まとめ（実務で起きていること）
- Android 10以降、IMEI等の自動取得は原則として難しくなっている
- ADB/内部コマンドは端末/ビルド依存で、成功が保証できない
- メーカー独自設定により、端末情報取得や処理フローが左右される
5. MASAMUNE Erasureの対応
MASAMUNE Erasureは、IMEI自動取得が難しい環境でも、データ消去業務を進められる運用を前提に設計されています。端末側の仕様・設定の影響を踏まえ、最新機種/OSに対応した消去処理と、現場向けのサポート情報を提供しています。
運用上のポイントとして、USBデバッグ設定、必要に応じた追加セキュリティ設定、端末画面での許可（承認操作）、ソフトウェアの最新版利用をご確認ください。
6. 注意点
非root・通常ADB環境では、IMEIの自動取得が仕様上制限されるため、環境によっては手動入力が必要になる場合があります。なお、特権環境（例: システムアプリ相当の権限が付与された構成等）では取得できる場合もありますが、一般的な運用で一律に期待できるものではありません。
お問い合わせ: 運用環境や対象端末に応じた最適な手順については、サポートまでご相談ください。
