/home/Messier82/projects/service-book/app/lint-baseline.xml: Hint: 26 warnings were filtered out because they are listed in the baseline file, lint-baseline.xml [LintBaseline] /home/Messier82/projects/service-book/app/lint-baseline.xml: Hint: 49 errors/warnings were listed in the baseline file (lint-baseline.xml) but not found in the project; perhaps they have been fixed? Another possible explanation is that lint recently stopped analyzing (and including results from) dependent projects by default. You can turn this back on with android.lintOptions.checkDependencies=true. Unmatched issue types: AndroidGradlePluginVersion (3), GradleDependency (36), UnusedResources (10) [LintBaselineFixed] Explanation for issues of type "LintBaselineFixed": If a lint baseline describes a problem which is no longer reported, then the problem has either been fixed, or perhaps the issue type has been disabled. In any case, the entry can be removed from the baseline (such that if the issue is reintroduced at some point, lint will complain rather than just silently starting to match the old baseline entry again.) /home/Messier82/projects/service-book/app/build.gradle.kts:70: Warning: Not targeting the latest versions of Android; compatibility modes apply. Consider testing and updating this version. Consult the android.os.Build.VERSION_CODES javadoc for details. [OldTargetApi] targetSdk = 36 ~~~~~~~~~~~~~~ Explanation for issues of type "OldTargetApi": When your application or sdk runs on a version of Android that is more recent than your targetSdk specifies that it has been tested with, various compatibility modes kick in. This ensures that your application continues to work, but it may look out of place. For example, if the targetSdk is less than 14, your app may get an option button in the UI. To fix this issue, set the targetSdk to the highest available value. Then test your app to make sure everything works correctly. You may want to consult the compatibility notes to see what changes apply to each version you are adding support for: https://developer.android.com/reference/android/os/Build.VERSION_CODES.html as well as follow this guide: https://developer.android.com/distribute/best-practices/develop/target-sdk. html https://developer.android.com/distribute/best-practices/develop/target-sdk.html /home/Messier82/projects/service-book/app/build.gradle.kts:65: Warning: A newer version of compileSdk than 36 is available: 37 [GradleDependency] compileSdk = 36 ~~~~~~~~~~~~~~~ Explanation for issues of type "GradleDependency": This detector looks for usages of libraries where the version you are using is not the current stable release. Using older versions is fine, and there are cases where you deliberately want to stick with an older version. However, you may simply not be aware that a more recent version is available, and that is what this lint check helps find. /home/Messier82/projects/service-book/gradle/libs.versions.toml:11: Warning: A newer version of io.github.takahirom.roborazzi than 1.11.0 is available: 1.63.0 [NewerVersionAvailable] roborazzi = "1.11.0" ~~~~~~~~ /home/Messier82/projects/service-book/gradle/libs.versions.toml:11: Warning: A newer version of io.github.takahirom.roborazzi:roborazzi than 1.11.0 is available: 1.63.0 [NewerVersionAvailable] roborazzi = "1.11.0" ~~~~~~~~ /home/Messier82/projects/service-book/gradle/libs.versions.toml:11: Warning: A newer version of io.github.takahirom.roborazzi:roborazzi-compose than 1.11.0 is available: 1.63.0 [NewerVersionAvailable] roborazzi = "1.11.0" ~~~~~~~~ /home/Messier82/projects/service-book/gradle/libs.versions.toml:24: Warning: A newer version of io.sentry:sentry-android than 8.41.0 is available: 8.42.0 [NewerVersionAvailable] sentry = "8.41.0" ~~~~~~~~ Explanation for issues of type "NewerVersionAvailable": This detector checks with a central repository to see if there are newer versions available for the dependencies used by this project. This is similar to the GradleDependency check, which checks for newer versions available in the Android SDK tools and libraries, but this works with any MavenCentral dependency, and connects to the library every time, which makes it more flexible but also much slower. /home/Messier82/projects/service-book/app/src/main/java/com/yorvana/ui/settings/CategoriesScreen.kt:93: Warning: Reading Resources using LocalContext.current.resources [LocalContextResourcesRead from androidx.compose.ui] context.resources.getQuantityString( ~~~~~~~~~~~~~~~~~ Explanation for issues of type "LocalContextResourcesRead": Changes to the Configuration object will not cause LocalContext.current.resources reads to be invalidated, so calls to APIs such as Resources.getString() will not be updated when the Configuration changes. Instead, use LocalResources.current to retrieve the Resources - this will invalidate callers when the Configuration changes, to ensure that these calls reflect the latest values. Vendor: Jetpack Compose Identifier: androidx.compose.ui Feedback: https://issuetracker.google.com/issues/new?component=612128 /home/Messier82/projects/service-book/app/src/main/java/com/yorvana/ui/navigation/AppNavGraph.kt:348: Hint: Prefer mutableIntStateOf instead of mutableStateOf [AutoboxingStateCreation from androidx.compose.runtime] var step by rememberSaveable { mutableStateOf(1) } ~~~~~~~~~~~~~~ Explanation for issues of type "AutoboxingStateCreation": Calling mutableStateOf() when T is either backed by a primitive type on the JVM or is a value class results in a state implementation that requires all state values to be boxed. This usually causes an additional allocation for each state write, and adds some additional work to auto-unbox values when reading the value of the state. Instead, prefer to use a specialized primitive state implementation for Int, Long, Float, and Double when the state does not need to track null values and does not override the default SnapshotMutationPolicy. See mutableIntStateOf(), mutableLongStateOf(), mutableFloatStateOf(), and mutableDoubleStateOf() for more information. Vendor: Jetpack Compose Identifier: androidx.compose.runtime Feedback: https://issuetracker.google.com/issues/new?component=612128 /home/Messier82/projects/service-book/app/src/main/res/values/strings.xml:159: Warning: The resource R.string.action_show_more appears to be unused [UnusedResources] Show more ~~~~~~~~~~~~~~~~~~~~~~~ /home/Messier82/projects/service-book/app/src/main/res/values/strings.xml:161: Warning: The resource R.string.a11y_state_expanded appears to be unused [UnusedResources] Expanded ~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/Messier82/projects/service-book/app/src/main/res/values/strings.xml:162: Warning: The resource R.string.a11y_state_collapsed appears to be unused [UnusedResources] Collapsed ~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/Messier82/projects/service-book/app/src/main/res/values/strings.xml:199: Warning: The resource R.string.banner_text appears to be unused [UnusedResources] Read-only mode — upgrade to edit ~~~~~~~~~~~~~~~~~~ /home/Messier82/projects/service-book/app/src/main/res/values/strings.xml:200: Warning: The resource R.string.banner_upgrade appears to be unused [UnusedResources] Upgrade ~~~~~~~~~~~~~~~~~~~~~ Explanation for issues of type "UnusedResources": Unused resources make applications larger and slow down builds. The unused resource check can ignore tests. If you want to include resources that are only referenced from tests, consider packaging them in a test source set instead. You can include test sources in the unused resource check by setting the system property lint.unused-resources.include-tests=true, and to exclude them (usually for performance reasons), use lint.unused-resources.exclude-tests=true. Available options: **skip-libraries** (default is true): Whether the unused resource check should skip reporting unused resources in libraries. Many libraries will declare resources that are part of the library surface; other modules depending on the library will also reference the resources. To avoid reporting all these resources as unused (in the context of a library), the unused resource check normally skips reporting unused resources in libraries. Instead, run the unused resource check on the consuming app module (along with `checkDependencies=true`). However, there are cases where you want to check that all the resources declared in a library are used; in that case, you can disable the skip option. To configure this option, use a `lint.xml` file with an