[device_info] add PackageManager's SystemFeatures to AndroidDeviceInfo #2567
Conversation
| /// The Android hardware device ID that is unique between the device + user and app signing. | ||
| final String androidId; | ||
|
|
||
| /// A list of available features, from PackageManager.getSystemAvailableFeatures. |
There was a problem hiding this comment.
This would require Flutter apps to know Android specific system feature strings. Would it be possible to expose this as an enum? It would be OK for it to be less generic in the name of making API easier to grok.
There was a problem hiding this comment.
I think that would create a maintenance headache, and it would restrict the flexibility of the API (unless we also surfaced the strings that don't match to an enum, which would be a bit redundant).
The Android API that this maps to is inherently based on strings. Some of the more common feature strings are surfaced as public constants in PackageManager (see https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_ACTIVITIES_ON_SECONDARY_DISPLAYS and below) but that list is both regularly updated, and always incomplete. For example, there's manufacturer features like "com.google.android.feature.GOOGLE_EXPERIENCE" that would never be added to the list of string constants in PackageManager, but some app developers may care to check for. For any developer wanting to use this API, it should be a simple effort to figure out which strings they care about, and hardcode them in a simple wrapper around AndroidDeviceInfo.
There was a problem hiding this comment.
The Android API that this maps to is inherently based on strings.
Good to know. In that case, I am OK with this API.
common feature strings are surfaced as public constants
Can we do the same and expose a bunch of const values for common cases that the apps can use?
Flutter developers are not typically familiar with Android and how it works. They might not even know what to google. Ideally, everything they need to know is in the Dart API. If that's not the case, we should improve the API.
There was a problem hiding this comment.
Talked a bit offline. It would be a lot of constants to add (PackageManager has ~140 public FEATURE_ constants), and they're already available through PackageManager's documentation, so we agreed there's not much value in adding the consts in Dart. Updated the documentation on the dart side to reference PackageManager's documentation where the common strings are available, as well as to caution people against using this API except for in specific circumstances where they have no other option.
There's a variety of scenarios where checking at runtime which system features are available is useful. System features are device capabilities that do not change at runtime (for example, FEATURE_BLUETOOTH is always present if the device has a bluetooth radio, even if Bluetooth is presently disabled), so DeviceInfo seems like the right place to put this.
EricEnslen
force-pushed
the
system_features
branch
from
a4eea5b to
148a8fd
Compare
|
We have a breaking change for this PR. It happens when the receiver of the function fromList is null. Could you provide proper checks please? |
flutter#2567) There's a variety of scenarios where checking at runtime which system features are available is useful. System features are device capabilities that do not change at runtime (for example, FEATURE_BLUETOOTH is always present if the device has a bluetooth radio, even if Bluetooth is presently disabled), so DeviceInfo seems like the right place to put this.
flutter#2567) There's a variety of scenarios where checking at runtime which system features are available is useful. System features are device capabilities that do not change at runtime (for example, FEATURE_BLUETOOTH is always present if the device has a bluetooth radio, even if Bluetooth is presently disabled), so DeviceInfo seems like the right place to put this.
4 participants
Description
There's a variety of scenarios where checking at runtime which system
features are available is useful. System features are device
capabilities that do not change at runtime (for example, FEATURE_BLUETOOTH
is always present if the device has a bluetooth radio, even if Bluetooth
is presently disabled), so DeviceInfo seems like the right place to put
this.
Related Issues
N/A
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze) does not report any problems on my PR.Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?