Updating checkstyle fixed a vulnerability and fixed a final class check in version 10.12.2 for local classes without constructor. Local classes without a constructor should be marked as final. That is done in this commit.
For more info see https://github.com/checkstyle/checkstyle/releases/tag/checkstyle-10.12.2
formatters() is called again by the player before the user has a chance to click on the language in the language chooser.
So the correct solution would probably be to attach to https://developer.android.com/reference/android/content/Intent#ACTION_LOCALE_CHANGED, but let's keep it simple. I added `PlayerHelper.resetFormat();` in `ContentSettingsFragment.onDestroy()` and it works. It will mean the player formatters will be reset every time the user exits content settings, but whatever.
and reset them when the language is changed/changing.
This way they will be re-initialized on the next call.
Also Remove a bunch of outdated/non-thread safe code (STRING_FORMATTER)
* Use build constants when possible
* Inline variables
* Don't use var for normal-sized types (that way it's easier to review)
* Split code into methods
Copied select_channel_fragment to select_feed_group_fragment
Copied select_channel_item to select_feed_group_item
# Change
Replaced the Layout references in the new Class SelectFeedGroupFragment
* IcePick fails on Java 21 (default in Android Studio 2024.2)
* Bridge is the most modern alternative that is currently available. It is backed by ``Android-State`` and can be configured with various frameworks
* In the long term this should be replaced with something better
NewPipe is contacting its servers without asking for the users' consent. This is categorized as "tracking" by F-Droid (see https://github.com/TeamNewPipe/NewPipe/discussions/10785).
This commit disables checking for udpates by default and adds a dialog asking for the user's consent to automatically check for updates if the app version is eligible for them. After upgrading to a version containing this commit the user is asked directly on the first app start. On fresh installs however, showing it on the first app start contributes to a bad onboarding an welcoming experience. Therefore, the dialog is shown at the second app start.
Co-authored-by: Stypox <stypox@pm.me>
