feat: Adding support for gemma4 e2b models

[mkopcins]

Description

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

Test by running apps/llm app on llm screen (for text only model) and multimodal screen (for audio-vision-text model). Text model should work as any other llm model. Multimodal can process up-to-30sec audio chunks as well as image inputs, should be able to transcribe audio, describe pictures or similar.

Screenshots

Related issues

#1062

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

[chmjkb]

not going to block the PR over this, however this is getting pretty similar to vision encoder, maybe we can lift something up

[chmjkb]

i believe we should sanity check the inputs provided by user in setters here

[msluszniak]

We needs to add some kind of symbol to messages with audio attached, now it is not clear for the user. Also, how big is the context in this model? It seems to be really small which makes it hard to keep conversation with this model using multimodal inputs. Another thing which is concerning is that the TTFT rapidly grows when we keep sending messages.

[msluszniak]

Clicking on the send button does not block UI which is not intuitive for the user that something is already happening.

[mkopcins]

context is 2048 tokens

[chmjkb]

i'll test the app on iOS

[chmjkb]

Something feels off about the demo app 😅

[msluszniak]

Review of the latest state (ccb5526c1) across the native runner, TS layer, and the example app. Inline comments group into: confirmed correctness bugs — the prefiller return-handling (processMultimodalInput has no Error::Ok path + prefill() discards every helper's return; these are coupled), the PLE element-size shadowing that zeroes the per-chunk offset on long prompts, and the LLMModule imperative API dropping audioConfig — plus robustness/API gaps and nits. A few items are phrased as questions where I couldn't confirm intent (e.g. the audio-encoder scalar). Verified against the code; happy to discuss any of them.

[msluszniak]

Two recording-robustness issues: (1) this result.status === 'error' branch is effectively dead — with no file output, AudioRecorder.start() always returns { status: 'success' }, so a real native start failure still flips the UI to 'recording' and yields empty audio; register recorder.current.onError(...) instead. (2) onAudioReady pushes a Float32Array per ~0.1s with no cap, so a long recording grows memory unbounded and hands a huge buffer to sendMessage despite the model's ~30s window — enforce a max-duration stop (and reject oversized decoded buffers in loadAudioFromUrl).

[msluszniak]

Mic permission is requested once on mount and this is a dead-end on denial: the button isn't disabled when !hasMicPermission, so tapping it only sets 'enable it in Settings' with no way to act, and there's no re-check or Linking.openSettings(). Re-request inside startRecording (await requestRecordingPermissions() and update state), offer Linking.openSettings() when Denied, and/or disable the button when permission is known-denied.

[chmjkb]

besides what Mateusz requested, i think everything is fine on my end

[msluszniak]

I think all issues that I raised are now addressed. Thank you for working on this one Mateusz. 🚀