看起来你需要实现的是仅允许企业自有/管理设备登录应用的需求，同时想搞清楚怎么在非企业管理的设备上做认证层面的拦截——毕竟Android系统级的设备管理黑白名单只覆盖管控内的设备对吧？下面是几个经过实践验证的可行思路：

核心方向：从设备身份校验入手，而非单纯依赖系统管控 #

系统级的黑白名单（比如Android Enterprise的应用管控）只能管到企业已经纳入管理的设备，对于外部设备，得从应用登录流程里加拦截逻辑，结合后端校验来实现。

1. 用Android Enterprise的官方能力识别管理设备 #

如果你们已经在用Android Enterprise（不管是完全管理设备、工作资料模式还是专用设备模式），这是最靠谱的方式：

• 通过DevicePolicyManager类来判断设备状态：调用isDeviceManaged()可以知道设备是否被企业MDM管控，isProfileOwnerApp()能判断当前应用是否在工作资料环境下运行。
• 让你们的MDM系统给每个管理设备分配唯一的设备令牌，应用登录时把这个令牌传给后端，后端和MDM的设备库比对，只有匹配的才允许登录。这种方式安全性很高，因为令牌是MDM下发的，很难伪造。

2. 自定义设备指纹校验（覆盖非管理的指定设备） #

如果有些企业设备没纳入MDM管控，那就得自己搞设备身份识别：

• 收集设备的特征组合（比如Settings.Secure.ANDROID_ID、硬件序列号、设备首次启动时生成的UUID），注意Android 10+拿不到IMEI这类敏感信息，所以优先用Android ID或者自己生成的UUID（存在应用私有存储里，卸载重装会重置）。
• 把所有允许登录的设备指纹提前录入后端数据库，应用登录时把本地的指纹发过去，后端比对通过才放行。
• 为了防篡改，最好再加一层应用签名校验（确保登录的是你们官方签名的应用）和Root检测（拒绝Root过的设备，避免指纹被篡改）。

3. 后端维护认证黑名单，拦截非授权设备 #

不管是管理设备还是自定义指纹的设备，后端都可以维护一个黑名单列表：

• 把那些校验失败、用户举报的设备标识加进去，只要设备尝试登录，后端先查黑名单，直接拒绝请求。
• 前端也可以缓存本地黑名单（比如连续3次登录失败的设备），减少不必要的后端请求，提升用户体验。

4. 关于系统级黑白名单的补充说明 #

你提到的Android设备管理的应用黑白名单，确实只能在企业管控的设备（比如包名以com.google.android.apps.work.clouddpc开头的MDM管控设备）上生效，这类管控是系统级的，能直接限制应用安装或启动，但管不到外部设备。所以必须结合应用层的认证校验，才能实现全场景的登录限制。

内容的提问来源于stack exchange，提问作者Jeff Lockhart