[Enhancement proposal]: Split out service status checks from Permissions

[wujek-srujek]

Please check the following before submitting a new issue.

• I have searched the existing issues.
• I have carefully read the documentation and verified I have added the required platform specific configuration.

Please select affected platform(s)

All of them, the API changes for the better ;).

Proposal

Currently service checks use permissions as input, and this sometimes is strange to use.

Bluetooth on Android is a good example. Until API level 30 there was Permissions.BLUETOOTH, and this is also used to check if BT is enabled on the device (almost, see #773). With API level 31, Permissions.BLUETOOTH is removed and others (.BLUETOOTH_SCAN, .BLUETOOTH_CONNECT etc.) are introduced instead. This means that on phones > API level 30 we will request the new permissions, but still need to use the old / legacy one for checking if BT is enabled on the device. IMHO this sounds clumsy.

An idea: service checks should not use permissions; instead, a type ServiceType is introduces with values like location, bluetooth, telephony etc. There is an extension on ServiceType with a member status, which allows for checking the status without using permissions, e.g.

extension ServiceTypeActions on ServiceType {
...
  Future<ServiceStatus> get status => _handler.checkServiceStatus(this);
...
}

This allows users to just do:

await ServiceType.bluetooth.status

If you want to additionally keep the current way and let the user check service status based on the permissions, PermissionWithStatus gets a new member service and the extension PermissionWithService.serviceStatus gets updated to

extension ServicePermissionsActions on PermissionWithService {
...
  Future<ServiceStatus> get serviceStatus => _handler.checkServiceStatus(service); // not _checkServiceStatus(this)
...

or even just

extension ServicePermissionsActions on PermissionWithService {
...
  Future<ServiceStatus> get serviceStatus => service.status;
...

In the BT example, Permissions.bluetooth, .bluetoothScan, .bluetoothConnect etc. all are a PermissionWithService whose service member returns ServiceType.bluetooth.

Pitch

I think the code will become easier to maintain as there will be fewer conditions with OR, e.g. https://github.com/Baseflow/flutter-permission-handler/blob/permission_handler_v10.4.2/permission_handler_android/android/src/main/java/com/baseflow/permissionhandler/ServiceManager.java#L40-L42 and easier to understand, as currently permissions are used for two purposes.

I think it will be easier for end users because they would be able to check a service status without having to think about which permission they should use for the check (but they could still do it due to the facts that the extension PermissionsWithService.serviceStatus would be updated.). This nicely separates the concerns of checking services vs checking permissions.

Finally, I think it would make the API more robust against changes like the one for Bluetooth described above, where it is currently necessary to use a legacy permissions on new phones.