问题标签 [android-enterprise]

是否可以使用 AMAPI 将自托管/私有应用程序发布到使用工作配置文件或完全管理而不使用 Play 商店的设备？

我很困惑，因为我在以下帖子中看到的答案与 Google 的文档不符。 如何使用 android management api 静默推送 apk 并通过 android 设备策略安装它？

上述链接中的用户“Fred”表示无法执行此操作，但本网站的文档将其列为“可选” https://developers.google.com/android/work/requirements?api=clouddpx#313-self -hosted-private-app-management

第二个问题，使用 AMAPI 需要设备上的 Android 设备策略，我们是否可以使用自定义 DPC 和 ADP 来发布我们的私有应用程序，因为它们是通过 EMM 托管的？

我正在尝试使用 Package Installer 安装 apk 文件。我的应用程序是当前的个人资料所有者。该方法成功完成，但在我的 BroadcastReceiver 中，我得到了 PackageInstaller.STATUS_PENDING_USER_ACTION。根据 android 文档https://developer.android.com/reference/android/content/pm/PackageInstaller应用程序应该能够静默安装 apk，如果它是配置文件所有者。

我正在使用BluetoothAdapter.startDiscovery()查找特定的蓝牙设备（它是蓝牙 2.0 设备，所以我必须使用BluetoothAdapter.startDiscovery()）。我拥有所有必需的权限（蓝牙、位置），并且该应用程序运行良好。

但是现在我必须在 Android Enterprise (Work Profile) 下使用这个应用程序。在工作配置文件下，它不会开始扫描。配置文件中的所有限制均已禁用。
在调查 logcat 后，我​​发现了这样的行：

非工作资料日志：

工作资料日志：

这是来自 OnePlus 6 的日志，但我在三星 S10 上也观察到了类似的 logcat。客户还表示，他们在 S9、S8 和某些诺基亚设备（实际上是他们测试过的所有设备）上遇到了同样的问题。

通过 Android 资源搜索，我发现了以下代码，产生了这个日志：

哪些电话Utils.checkCaller()要检查：

所以startDiscovery() uid = 10126和startDiscovery() uid = 1010126不同uid，我认为这是由工作资料引起的，我认为这会导致支票(foregroundUser == callingUser)是false.

最后的问题是：我说它是一个错误是对的吗？如果是 - 有没有办法解决它？如果否 - 如何在工作资料中启用蓝牙经典扫描？

我正在使用 Android Enterprise 创建一个应用程序。

为此，我在build.gradle文件中添加了依赖项。

我正在尝试使用以下代码从此处禁用卸载应用程序

但是上面的代码不起作用。不会出现任何异常或警告

我错过了什么？无法找到有关如何使用企业管理 API 的适当文档。

在设备注册时，未通过 DevicePolicyManager 在 Android Q 中为设备所有者应用授予后台位置权限。

所有 3 个 API 调用（coarseP、fineP、backgroundP）的结果都是 true，但只授予前台权限。

奇怪的是，当我在应用程序更新时在广播接收器中添加相同的代码时，在这种情况下会授予后台权限。

无法在 Android 6 及更低版本的个人资料所有者中将文件从个人资料共享到工作资料。

我已经编写了代码来请求和共享从个人资料到个人资料所有者应用程序中的工作资料的文件。我从个人资料所有者应用程序向个人资料中的同一应用程序实例请求文件。我在 onActivityResult 中得到结果。我得到了我处理和保存的文件的内容 Uri。该代码在 android 7 及更高版本中运行良好，但在 Android 6 及更低版本中引发 FileNotFound:Permission Denied 异常。

在个人资料所有者方面，我在 onActivityResult 中收到结果

ParcelFileDescriptor fileDescriptorParcel = getContentResolver().openFileDescriptor(dataUri, "r"); 在这里我得到 FileNotFoundException: Permission denied。

我尝试使用 context.grantUriPermission() 授予权限，但这也不起作用。

我们正在执行 POC 以在设备配置后获取所有设备信息，例如电池状态、地理位置、可用存储等等

通过使用 Android 管理 API

因为我们能够从自定义 DPC 中获得如此多的信息

我正在使用 QR 码以完全托管模式在 Android 8.1.0 上设置 Android Management API。

我正在按照谷歌代码实验室链接来配置一个完全托管的设备，使用我的帐户进行身份验证，然后它就可以工作了。

但是，当我使用服务帐户进行身份验证时，按照示例代码生成 QR 码然后它不起作用：

1. 策略不同步。
2. enterprise.devices.list 返回空列表。

但是，如果我使用它来设置工作配置文件模式，那么它就可以工作。

服务帐号在 Google Cloud 项目中具有 Owner 角色。

这是二维码内容：

我是否必须为该服务帐户配置其他内容？

我在项目中启用了 Android Management API。

我们正在使用android管理API来管理我们内部的企业级设备，即使设备的WIFI功能齐全，有时谷歌似乎也会失去与设备的连接或命令。

我们发现我们在设备补丁上注册的设备之一以更改策略没有更新谷歌设备 JSON 上的 lastPolicySyncTime（显示 lastPolicySyncTime 为 10 月 7 日，但应该是执行设备补丁的最晚日期）。

因此我们尝试在设备上发出 REBOOT 命令，因为我们认为重启可以解决我们的问题，即使这似乎不起作用并且设备没有重启，所以我们进行了手动重启并将 lastPolicySyncTime 更新一次到 10 月 24 日（那天是正确的）。

但是，目前该设备仍未使用最新的 lastPolicySyncTime（即截至今天的 10 月 26 日）进行更新，我的理解是谷歌每天都会对设备进行 ping 操作，并且 lastpolicySycTime 会并行更新。此外，我提到了其中一个设备，这也是许多设备的情况。

我们没有遇到任何使用 android 管理 API 更新设备或策略配置的问题，但问题在于谷歌在任何操作中更新注册的设备。

所以我想问你一些关于上述参考的问题，

google 何时 ping 已注册的设备，是否有某种调度程序正在运行，或者仅当我们对设备或已注册策略执行补丁操作时才运行？

为什么有时我们无法反映设备上的操作（策略补丁、发出命令和设备补丁）？

我有一个带有一些托管配置的 Android 应用程序。但是，当我向 AMAPI 询问此应用程序的架构时，并未检索到所有限制。

这是架构：

这是来自 AMAPI 对托管属性的响应：

您知道为什么 AMAPI 不返回捆绑包的整个配置吗？