Migration of shared_preferences to kotlin, upgraded flutter base repository.

[Crdzbird]

Description

• Migrated SharedPreferences Handler from JAVA to KOTLIN, upgraded issues with flutter deprecated versioning(updated).
• Reduced code utilized when created duplicated FlutterEmbeddedActivity, now works with just 1 Activity instead of 2.
• Updated all related android versioning to the most stable release.
• Reduced manifest.

Related Issues

none

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.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[stuartmorgan-g]

Thanks for the submission! We’re currently working through a large backlog of PRs, and this will require non-trivial review, so it will take some time before we’re able to review it. As explained in CONTRIBUTING.md, votes for the corresponding issue are the primary way we’re prioritizing non-trivial reviews, so if you want to prioritize this, filing an issue describing the benefits would be the first step.

For this PR specifically, note that we don't currently use Kotlin for any plugins, so the first step in moving forward here would be a decision about whether to add a new language to this repository; if you're interested in pursuing that conversation an issue on that subject, or even a design doc would be a good idea.

We apologize for the long delay in triaging this PR. We’re in the process of overhauling our PR triage system to respond much more quickly, as well as working through the backlog.

[Crdzbird]

Thanks for the response @stuartmorgan the migration of the plugin into flutter was something that i considered necessary, i wish to help on the migration of the code base of the flutter plugins(due to the efficient that comes from kotlin) however if you considers necessary we can continue in an issue or as you suggested a Design Document.

[stuartmorgan-g]

if you considers necessary we can continue in an issue or as you suggested a Design Document.

Adding a new language to the repository (meaning another language that people maintaining the plugins here have to be familiar with and context switch between, in addition to the 4 we already have), or rewriting every Android plugin implementation, are both major decisions that should be discussed in a proposal via design document.

[stuartmorgan-g]

https://flutter.dev/go/flutter-plugin-languages has since been written up as a proposal for language migration, but there is still no resolution on that. It's something that the platform teams will continue to evaluate, but currently there's no plan to adopt Kotlin.

Given that there's no timeline on that, I'm going to close this; it's already bitrotted significantly, and will continue to do so as long as there's no path for it to move forward. Thanks for your interest though, and if in the future we decide to adopt Kotlin here please feel free to contribute to migrations!