User Profile
BS
Level 1.6: Donut
Joined 2 years ago
User Widgets
Contributions
Re: Questions Regarding Fully Company-Owned and Managed Devices with AMAPI
Hi Alex, Thank you so much for your response! 1) System-Level Permissions: That makes sense. We could unroot the device after systemizing our application, but for now we disable the root / super-user manager after granting root access to our application. This way all other applications are denied su access. Systemizing our application is a must for call recordings unless google decides to demote the permission level. 2) Granting Special Permissions: Unfortunate, but not a blocker. 3) Enforcing Default Applications Thanks! Will look into it. 6) DeviceID It's the id which AMAPI assigns to the enrolled device on their end, used for querying and executing commands on the device.363Views0likes0CommentsQuestions Regarding Fully Company-Owned and Managed Devices with AMAPI
I have a few questions regarding the capabilities and limitations of AMAPI for fully company-owned and managed devices: Granting System-Level Permissions: Is it possible to grant system-level permissions (protected permissions) through AMAPI? Alternatively, can the companion app be converted into a system app via policy? Use Case: Enabling call recording, which requires the CAPTURE_AUDIO_OUTPUT system permission. Current Solution: Rooting the devices and making the app a system-level application. Granting Special Permissions to Applications: Can special permissions like AppUsage, System Alert Window, Notification Listener, Full Storage, Screen Capture, or Accessibility be granted via policy? Use Case: Features like monitoring, productivity analysis, and remote control rely on these permissions. Current Solution: Using su commands and an extension app to manage these permissions. Enforcing Default Applications: Is there a way to enforce and set default apps (e.g., default dialer / phone) via policy? Use Case: Setting a specific default dialer for call recordings. Current Solution: Disabling all other dialers or setting the default app using accessibility (automation) if not already set. Disabling Wi-Fi/VoIP Calling: Can policies enforce turning off Wi-Fi or VoIP calling? Use Case: Calls made via Wi-Fi are not recorded unless the call uses the telephone network. Current Solution: Checking and disabling Wi-Fi calling with a READ_PRECISE_PHONE_STATE elevated permission through the system companion app. Freezing System Updates: Is it possible to indefinitely freeze system updates via policy? Use Case: Preventing loss of root access caused by system updates. Current Solution: None, span freeze period during predicted high traffic and sales. Device ID: How can the device ID be retrieved from an enrolled device? Use Case: Improved authentication mechanisms. Current Solution: AMAPI appears to use the GSFAndroidID as the device ID. This identifier is relatively easy to extract and requires the READ_GSERVICES permission. Any insights or suggestions regarding the above use cases would be greatly appreciated!607Views0likes2CommentsRe: [BUG] Android Management API: "Disable" Option Bypasses FORCE_INSTALLED Restriction
The policy remains the same, and we’ve developed our own EMM solution. The documentation provided by AMAPI is comprehensive and made the integration process straightforward and seamless for us. I do have several other questions I always wanted to ask. I'll create a separate post for that. Thanks!604Views0likes0CommentsRe: [BUG] Android Management API: "Disable" Option Bypasses FORCE_INSTALLED Restriction
Hello Lizzie, On the default launcher in Android 14, the 'disable' option does not appear when long-pressing an application, which prevents the exploit from occurring. However, I don’t believe this indicates that the issue has been inherently resolved in Android 14. My question is whether this issue will be addressed for Android 13 as well. Thanks653Views0likes2Comments[BUG] Android Management API: "Disable" Option Bypasses FORCE_INSTALLED Restriction
While implementing the Android Management API to configure a critical application as FORCE_INSTALLED, I encountered a significant issue. Under normal circumstances, this configuration prevents users from uninstalling or disabling the app, displaying an "Action not allowed" message when such actions are attempted via the device settings. However, When the user long-presses the app icon on the launcher, the "Disable" option becomes available, and selecting it successfully disables the application. This behavior undermines the intended enforcement of the FORCE_INSTALLED policy. Moreover, when trying to enable the application, the "Action not allowed" message is displayed. Steps to Reproduce Configure an application in the policy with the following parameters: "applications": [ { "packageName": "com.example.app", "installType": "FORCE_INSTALLED", "allowDisable": false } ] Apply the policy to a managed device. Attempt to disable the application through the device settings; the action will be correctly blocked with an "Action not allowed" message. Long-press the app icon on the launcher and select "Disable" (if the launcher supports this functionality). Expected Behavior: The "Disable" option should not appear in the launcher, or if it does, selecting it should trigger the "Action not allowed" message, consistent with the behavior in the device settings. Observed Behavior Despite the FORCE_INSTALLED restriction, the application can be disabled via the launcher, bypassing the enforced policy. This issue was encountered on an Android 13 device. Seems to have been solved on Android 14. The application was also made to be a system application. Also, adding the extension configuration for the application, also fixes the issue, but only one application can have that enabled.755Views0likes4Comments