Includes:
- https://github.com/JetBrains/skia/pull/25

`encodeToData` has been deprecated in Skia some time ago:
https://skia.googlesource.com/skia/+/refs/heads/main/RELEASE_NOTES.md#milestone-114

Previously, for png format the `quality` was ignored as it is a lossless
format.
The current skiko behavior for png format converts quality to zlib
compression level which makes the default value to 9 compared to the
default value 6 in skia.

Also, it was confusing as with lower quality you expect smaller size
which was not the case for png images. Quality stayed the same but
the size increased as the compression level was smaller

Fixes - [SKIKO-1150](https://youtrack.jetbrains.com/issue/SKIKO-1150)

Based on the book *The Java Native Interface: Programmer's Guide and
Specification*
> The ReleaseStringChars call is necessary whether GetStringChars has
set *isCopy to JNI_TRUE or
JNI_FALSE. ReleaseStringChars either frees the copy or unpins the
instance,
depending upon whether GetStringChars has returned a copy or not.

**What and why**
This PR fixes a memory leak in the `Canvas.drawVertices` JNI
implementation. The `indexArr` elements were accessed via
`GetShortArrayElements` but were never released, which could lead to
pinned arrays or memory exhaustion over time.

**Testing**
Successfully built the native C++ libraries locally on Windows x64. Ran
tests — all passed except `TextLineTest.emojiTest`, which seems to be a
local Windows environment issue unrelated to Canvas bindings.

**Release Notes**
* Fixed a JNI memory leak in `Canvas.drawVertices`.

**Issue:**

https://youtrack.jetbrains.com/issue/SKIKO-1149/Memory-leak-pinned-array-in-Canvas.drawVertices-JNI-due-to-missing-ReleaseShortArrayElements

Closes - [SKIKO-1100](https://youtrack.jetbrains.com/issue/SKIKO-1100)

Closes [SKIKO-1120](https://youtrack.jetbrains.com/issue/SKIKO-1120)

Part of [SKIKO-1100](https://youtrack.jetbrains.com/issue/SKIKO-1100)

To extract Skottie and other extensions from Skiko core, we need to
expose certain private symbols from skia. This requires creating tasks
to control the visibility of Skia symbols.

To control visibility of symbols the following things were applied:

### JVM
We are generating a lists of symbols that we want to export. To obtain
the symbols we're doing the following:

1. Collecting all globally defined symbols from the core Skiko/Skia
inputs: Skia static libraries plus core object files.
2. Collecting all undefined symbols from extension/module inputs. These
represent symbols that extension modules need the core library to
provide.
3. Adding JNI infrastructure symbols from the core exports, such as
`Java_`, `JNI`, and `jvm`, so the JVM can still find the native entry
points.
4. Intersecting the extension imports with the core exports. The result
is the list of core symbols that should stay exported.

Generated symbol list it then passed to the linker which hide symbols we
don't need to have visible.

### Native 
For Native targets, Skia is linked into the final produced binary rather
than exposed as a shared "core" library that extension modules link
against. Because of that, Skia symbols do not need to remain externally
visible for other Skiko modules to resolve against them.
Since we are going to build Skia from our fork with Skia symbols public
by default we need to hide them on native.

### WASM
This PR does not include wasm parser as we don't need it. We can first
create the wasm binary for extension functions and then provide them
when compiling the core. This will allow to export only symbols that are
needed by the extension modules automatically. This will be introduced
in the PR with Skottie extraction.

Closes [SKIKO-1142](https://youtrack.jetbrains.com/issue/SKIKO-1142)

Missing part after #1196

Updated automatically via run of
`./gradlew wrapper --gradle-version 9.5.0`

Fixes:
```
03:57:36.872  A  java_vm_ext.cc:598] JNI DETECTED ERROR IN APPLICATION: incompatible array type short[] expected char[]: 0x7fd297fa00
                 java_vm_ext.cc:598]     in call to GetCharArrayRegion
                 java_vm_ext.cc:598]     from long org.jetbrains.skia.BreakIteratorKt._nSetText(long, java.lang.Object, int, java.lang.Object)
```

- Upgrade Gradle wrappers to `9.5.0` across root and sample projects.
- Migrate Android build logic to AGP 9-compatible APIs (including KMP
Android integration updates).
- Fix `SkiaMultiplatformSample` iOS simulator run flow:
  - remove `applePlugin` usage
- replace invalid simctl spawn `--standalone <kexe>` with app bundle
install + launch
  - add `-Pskiko.iosSimulatorDevice=<device>` for simulator targeting
  - fix `IosClocks` renderApi reference typo
- Disable Kotlin JS Yarn lock generation in JS-enabled projects

Includes
- https://github.com/JetBrains/skia/pull/18
- https://github.com/JetBrains/skia/pull/20

Fixes a crash in offscreen Metal Swing rendering (`SkiaSwingLayer`) when
running against a Skia build with Metal API validation enabled.

`MetalSwingRedrawer.mm` (`makeMetalTexture`) creates the offscreen
texture with `texture2DDescriptorWithPixelFormat:...`, which defaults
`.usage` to `MTLTextureUsageShaderRead`. The same texture is then
wrapped as a `GrBackendRenderTarget` and rendered into, so on a debug
Skia `GrMtlGpu::onWrapBackendRenderTarget` asserts:

```
check(MTLTextureUsageRenderTarget & mtlTexture.usage)
```

and the process SIGTRAPs on the first paint. On a release Skia the
assert is compiled out and Metal tolerates the missing flag, so the bug
is latent there (and CI, which builds against release Skia, never sees
it). Present since `MetalSwingRedrawer` was added (v0.144.6), unchanged
on current `master`.

The fix sets the usage bits explicitly — `RenderTarget` because Skia
renders into the texture, `ShaderRead` because it is then sampled when
blitted back to `Graphics2D`:

```objc
textureDescriptor.usage = MTLTextureUsageRenderTarget | MTLTextureUsageShaderRead;
```

Repro (stock skiko + the published Debug Skia):

```
git clone --depth 1 --branch v0.144.6 https://github.com/JetBrains/skiko.git
./gradlew :skiko:publishToMavenLocal -Pskiko.debug=true
# paint any offscreen SkiaSwingLayer on macOS -> SIGTRAP on first paint
```

Validated: `:skiko:awtTest` green; a 2400-frame `SkiaSwingLayer` soak on
the debug Skia runs leak-free (median frame 2.4 ms, RSS flat) where it
previously crashed on frame 1. No behavior change on release builds —
the change is descriptor-time only.

Release Notes - Fixes a crash in offscreen Metal Swing rendering
(`SkiaSwingLayer`) when running against a Skia build with Metal API
validation enabled.

Fixes [SKIKO-1144](https://youtrack.jetbrains.com/issue/SKIKO-1144)

Prepare Skiko config to allow easier registration of
new modules

It consists of:

- A custom DSL for registering Skia archives and linker flags by: Env
(jvm/native/wasm), OS and Arch
- Extracting Skia library declarations and some core-specific linker
flags from environment configuration tasks
- Parameterizing `SkikoArtifacts` to reuse the publication config

Fixes [SKIKO-1141](https://youtrack.jetbrains.com/issue/SKIKO-1141)

Previously we didn't check JVM Linux x64/arm64, macOs x64, Windows arm64
AWT runtimes

---------
Co-authored-by: Ivan Matkov <ivan.matkov@jetbrains.com>

It transforms Matrix* classes to be value classes so that we avoid
double allocation in these simple classes (1 fo FloatArray and 1 for the
Matrix class itself)
https://github.com/JetBrains/skiko/pull/1137 followup (at least partly)

Fixes
[SKIKO-1140](https://youtrack.jetbrains.com/issue/SKIKO-1140/Change-Matrix-to-value-classes)

**Next**
Follow-up PR in Compose Core to make use of the internal float array
constructor to reuse if coming from another FLoatArray

---------
Co-authored-by: Ivan Matkov <matkov.ivan@gmail.com>

We must use the same clang flags to build JNI cpp shims as we use to
build skia

This PR introduces the extraction of test utilities into a separate
module.

This is a required preparation step for extracting `Skottie` into a
separate module, as it uses some of these test utilities.

Fixes [SKIKO-1136](https://youtrack.jetbrains.com/issue/SKIKO-1136)

```
Failed to get resource: GET. [HTTP HTTP/1.1 429 Too Many Requests: https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugins-bom/2.0.21/kotlin-gradle-plugins-bom-2.0.21.pom)]
Failed to get resource: GET. [HTTP HTTP/1.1 429 Too Many Requests: https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/2.0.21/kotlin-stdlib-2.0.21.pom)]
```

[CMP-10199](https://youtrack.jetbrains.com/issue/CMP-10199) [iOS]
Undefined symbol '_org_jetbrains_skia_Path__1nUpdateBoundsCache

It was removed in #1187 by accident, and there was no test to catch it

[SKIKO-1099](https://youtrack.jetbrains.com/issue/SKIKO-1099) Update
skia to m148

[SKIKO-1130](https://youtrack.jetbrains.com/issue/SKIKO-1130) Update
skia to m147 and its consumption

PathSegment.hashCode() threw RuntimeException("Unreachable") for
PathVerb.CLOSE segments when used in hash-based collections such as
intersect(). Added CLOSE case consistent with what equals() checks for
CLOSE segments. Also removed the else branch since all PathVerb values
are now handled. Added a test which fails unless CLOSE is handled in
hashCode().

## Testing
Ran test on awt locally — the new test `closedPathIntersectTest` fails 
before the fix and passes after.

## Release Notes
Fix crash when using closed paths in hash-based collections such as
`intersect()`

Fixes: [SKIKO-1038](https://youtrack.jetbrains.com/issue/SKIKO-1038)

This PR fixes Metal Swing offscreen rendering behavior when the active
`GraphicsConfiguration` is not compatible with JBR shared textures, and
adds focused regression tests for the fallback path.
`AcceleratedSwingPainter` now explicitly falls back to software painting
for incompatible graphics configurations (for example,
offscreen/`BufferedImage` paint flows).

## Changes

- Introduced `SharedTexturesAdapter` as a small abstraction over JBR
shared textures so production code keeps using JBR while tests can
inject a fake adapter.
- Updated `MetalSwingRedrawer` to create and pass the shared texture
adapter into `AcceleratedSwingPainter`.
- Updated `AcceleratedSwingPainter` to support test injection and
preserve fallback behaviour for incompatible graphics configurations.
- Added minimal test hooks in `AcceleratedSwingPainter` with
`org.jetbrains.annotations.VisibleForTesting` so tests can validate
cache-reset behaviour.
- Added `org.jetbrains:annotations` as an `awtMain` dependency to use
`VisibleForTesting`. I can undo this and remove the annotation, but I
think it's worth keeping...
- Added `AcceleratedSwingPainterTest` covering:
  - fallback is used for incompatible `GraphicsConfiguration`
  - accelerated cache state is cleared on fallback
  - `dispose()` delegates to fallback painter

---

Fixes https://youtrack.jetbrains.com/issue/SKIKO-1082

---------
Co-authored-by: Igor Demin <igordmn@users.noreply.github.com>

Add the step to patch all C/C++ symbols for iOS and tvOS targets to
prevent symbol clashes when the user's app uses another skia library, or
one of its dependencies.

Fixes:
https://youtrack.jetbrains.com/issue/CMP-6845/How-to-use-compose-multiplatform-on-iOS-in-app-with-lib-skia-dependency

---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

[SKIKO-1098](https://youtrack.jetbrains.com/issue/SKIKO-1098) Update
skia to m146

[SKIKO-1067](https://youtrack.jetbrains.com/issue/SKIKO-1067) Build
Skiko with Kotlin 2.3.0

[SKIKO-1095](https://youtrack.jetbrains.com/issue/SKIKO-1095) Move build
scripts from `skia-pack` to `skia` fork

https://github.com/JetBrains/skia/pull/15

This is backport of https://github.com/JetBrains/skiko/pull/1173 to
Kotlin 2.2.20

---------
Co-authored-by: Ivan Matkov <ivan.matkov@jetbrains.com>

Improve performance of critical paths by preventing allocating
intermediate objects like lists, arrays,.... (chunked, map,
to*Collection)

---------
Co-authored-by: Ivan Matkov <matkov.ivan@gmail.com>
Co-authored-by: Alexander Maryanovsky <msasha@gmail.com>

Fixes from #1168 extracted as a followup patch for #1162

Added support for custom blend modes through
RuntimeEffect.makeForBlender() and Paint.blender.

There was a discussion on the topic at
https://youtrack.jetbrains.com/issue/CMP-5046.