Move LogCat prop to SentryOptions

[kanadaj]

Addresses #2935 (Move LogCat prop to SentryOptions)

[bruno-garcia]

There's a partial class defined in Platform/Android for SentryOptions so the properties can stay there (just not under the native binding options.Android that map to the native SDK options:

main/src/Sentry/Platforms/Android/SentryOptions.cs

All Android specific code that can go there is better located under Platform/Android (similar to a MAUI app structure).
We can avoid #ifdef at the top level stuff a lot this way.

[bruno-garcia]

This could stay in Sentry/Platform/Android, no need to move it up.

[bruno-garcia]

LGTM but looking at the sample made me realize that having it under Android had the advantage of not requiring additional #ifdef from the client app. Since the whole property is by definition Android specific.
The fact it breaks the simple explanation that's "binding the native Android SDK" is the challenge.

So I'm happy making this change, but at the same feel less strongly we must, because I see the trade off of the original approach vs this.

cc @bitsandfoxes @jamescrosswell @vaind for thoughts

[kanadaj]

It still requires #ifdef on MAUI so long as the property is only available on Android. At the same time, of we don't do that, it will get confusing that the property is there on platforms without logcat

[bruno-garcia]

It still requires #ifdef on MAUI so long as the property is only available on Android. At the same time, of we don't do that, it will get confusing that the property is there on platforms without logcat

right it makes sense the property is only available on Android. My learning from seeing this PR is that the usage of the Android-only option is a bit awkward if sitting directly on option when compared to having it under options.Android.Abc

It's easy to communicate and discover to:

#if ANDROID
options.Android... // Intellisense shows all options

vs somehow inside the #if inspecting the top level options properties and having to discover something "new" in the mix of a ton of other things that show regardless of platform

[bruno-garcia]

We are renaming Android to Native which frees up adding a new property Android (lol?) that would only only Android specific things.

• refactor: rename native options #2940

As I mentioned before I don't know if this is the best way forward, but wanted to share these thoughts. @vaind wdyt?

[jamescrosswell]

My learning from seeing this PR is that the usage of the Android-only option is a bit awkward if sitting directly on option when compared to having it under options.Android.Abc

I agree. I wouldn't move it, tbh.

If we do want to make it always available (so the client code doesn't need #if directives) I think it's inconsistent with how we surface all the other platform specific options. So either we we do or we don't, but let's not do it for some options but not others.

[bruno-garcia]

My learning from seeing this PR is that the usage of the Android-only option is a bit awkward if sitting directly on option when compared to having it under options.Android.Abc

I agree. I wouldn't move it, tbh.

If we do want to make it always available (so the client code doesn't need #if directives) I think it's inconsistent with how we surface all the other platform specific options. So either we we do or we don't, but let's not do it for some options but not others.

Now that the binding option became option.Native, we can create a SentryAndroidOptions class to add Android-only properties, and keep the original location.

Basically pulling main into this PR will force you into that set up since the Android to Native renaming was merged already

[bitsandfoxes]

Making that PR now work with what got merged on main looks annoying. Sorry about that. I finished this over here #2959