Questions Regarding Fully Company-Owned and Managed Devices with AMAPI

BS
Level 1.5: Cupcake

Wednesday

I have a few questions regarding the capabilities and limitations of AMAPI for fully company-owned and managed devices:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.
  6. 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!

0 Kudos
1 REPLY 1

Alex_Muc
Level 2.2: Froyo

yesterday

Hi!

 

These use cases and current solutions can have an extreme impact on device security and data protection for users and customers. I can only strongly advise against processing personal data on rooted devices, whose security patches should also be prevented as far as possible.
I haven't studied some of the questions in depth so far, but maybe some information will help.

 

1) System-Level Permissions

Privileged apps must be located in specific ./priv-app/ directories.

https://source.android.com/docs/core/permissions/perms-allowlist

 

3rd party apps (pre-installed apps, user-installed apps) are installed in /data/app/.
If I am correctly informed, system apps that do not require system-level permissions are installed in /system/app/.
System apps with system permissions are installed in /system/priv-app/.
Privileged apps can also be located in other, special partitions. For example in /product/priv-app/

https://source.android.com/docs/core/architecture/partitions/product-partitions

 

If UEM admins could give system-level permissions to a third-party app via AMAPI, this could undermine the entire device security in the event of a faulty configuration or in cases of a potentially harmful apps.
To be honest, I would never use rooted devices in the enterprise. I would rather approach the OEM to see if they can provide suitable firmware with preloaded system apps. (In case of doubt, however, this is extremely expensive)


2) Granting Special Permissions
Unfortunately, this is not possible. See this topic for more information:
https://www.androidenterprise.community/t5/general-discussions/granting-special-permissions-for-full...


3) Enforcing Default Applications
With Android 15, COPE now has the ability of enforcing the default apps for dialer, messaging and browser:
https://www.androidenterprise.community/t5/news-info/stronger-management-of-company-owned-devices-wi...

With Fully Managed, you may be able to work with app blacklists.

 

4) Disabling Wi-Fi Calling
We are currently using a CustomDPC and not AMAPI. Neither with the CustomDPC nor with an OEM config can we explicitly control Wi-Fi calling.

 

5) Freeze Periods
Android does not allow continuous freeze periods. A freeze period may be a maximum of 90 days long and the interval between freeze periods must be at least 60 days. Permanent blocking of updates could be possible with OEM-specific solutions.

https://developer.android.com/work/dpc/system-updates

 

6) DeviceID
A device can have different identifiers. IMEI, serial number, MAC, etc. What is “the” deviceID?

0 Kudos