similar comment about nullability.

It seems like only baseOS, previewSdkInt, and securityPatch should be nullable:

We are going with git dependencies, but feel free to change it after this PR is merged.

We have forked this package internally and my migration followed a different path. I am not a fan of making all these fields required for two reasons:

• Constructing the object (for tests) becomes painful. Consider an app test that only needs to set manufacturer. They now have to initialize all the other fields in their tests or use the obscure Map constructor.
• Semantically, these fields are not required to exist. They can be empty. To reflect that, we are initializing them to empty string. As an app developer, I would much rather have a signal that a field is nullable rather than having it be an empty string which does not provide compile-time safety.

In my migration, I marked all these fields as nullable. However, this failed tests because gallery uses this code and assumes they are not nullable.

Semantically, these fields are not required to exist. They can be empty. To reflect that, we are initializing them to empty string.

If it's referring to usage of Map, this is a limitation of the implementation.

When looking at this, we were trying to answer the question of what is a valid AndroidDeviceInfo based on the information available from the platform. If something changes in future versions of Android, then that is a breaking change to the API exposed to Dart.

In my opinion, if everything is nullable by default, then the API becomes some sort of "best-effort". "we think version is available, but we can't guarantee that".

This was the rationale behind it. That said, could you point to the cases where testing was painful?

we were trying to answer the question of what is a valid AndroidDeviceInfo based on the information available from the platform.

That means these fields are not supposed to be nullable. In that case, it would be far better to construct them via map values like so:

   someField: map[key]!,
   // rather than
   // someField: map[key] ?? '',

The code, today, reads like any one of these values can be non-existent and that's OK.

The test pain is a secondary reason. If these are truly non-nullable values, you can always expose a forTest constructor that effectively does what your map constructor is doing.

someField: map[key]! makes sense to me. We should fix it. This is an area where I think Pigeon could help, but that is a different discussion 😃