Extending FunctionGemma for Practical On-Device Mobile Function Calling

# Extending FunctionGemma for Practical On-Device Mobile Function Calling
Source: [https://arxiv.org/html/2609.25373](https://arxiv.org/html/2609.25373)
###### Abstract

On\-device assistants require function\-calling models that map natural language to local system actions, but existing resources emphasize web APIs or narrow mobile\-action catalogs\. We extend FunctionGemma 270M\-it to practical Android workflows by introducingMobileActionsExtended, a synthetic, schema\-validated dataset of∼\\sim9,500 conversations covering fifteen device\-control categories, including messaging, phone calls, camera/screenshot, brightness control, device\-status queries, flashlight control, and application management\. We fine\-tune the 270M model with TRL supervised fine\-tuning under completion\-only loss, producing an extended specialist and a combined model trained jointly with Google’sMobileActionsGoogle\. OnMobileActionsExtended, end\-to\-end accuracy improves from29\.3%29\.3\\%for the base model and17\.2%17\.2\\%for Google’s Mobile\-Actions variant to76\.5%76\.5\\%\. The combined model retains76\.5%76\.5\\%onMobileActionsExtendedand reaches82\.3%82\.3\\%onMobileActionsGoogle, down from the90\.3%90\.3\\%of Google’s Mobile\-Actions specialist, representing an 8\.0\-percentage\-point trade\-off in return for doubling category coverage\. We release the[dataset](https://huggingface.co/UGrowAI/datasets), fine\-tuned[models](https://huggingface.co/UGrowAI/models), reproducible training/evaluation pipeline, and an[Android demo](https://github.com/UgrowAI/HandyChat-apk/releases/latest/download/HandyChat.apk), highlighting compact local function calling as a practical path towards low\-latency and privacy\-preserving mobile assistants\.

## 1Introduction

Modern conversational assistants increasingly bridge natural language to executable actions through*function calling*: instead of generating free\-form text, the model emits a structured tool call \(a name and a JSON\-like dictionary of arguments\) that an external runtime can dispatch to operating\-system APIs, web services, or local hardware\([Schick et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib28);[Yao et al\., 2022](https://arxiv.org/html/2609.25373#bib.bib34);[Patil et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib26);[OpenAI, 2023](https://arxiv.org/html/2609.25373#bib.bib24);[Anthropic, 2024](https://arxiv.org/html/2609.25373#bib.bib3)\)\. The function\-calling formulation is now standard in commercial APIs and underlies most agent frameworks\([Wang et al\., 2026](https://arxiv.org/html/2609.25373#bib.bib31)\)\.

While the formulation is general, deployments differ sharply\. Server\-side agents primarily call*web APIs*\(REST endpoints, search, calendars, SaaS tools\), and most public benchmarks reflect this bias\([Patil et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib26);[Patil et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib25);[Liu et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib21);[Zhuo et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib35)\)\. On\-device assistants, by contrast, rely on*system actions*\(e\.g\., turning the flashlight on, sending an SMS, opening an installed application, querying the battery\) that must be invoked through the host operating system rather than the network\. These actions are high\-frequency, latency\-sensitive, and privacy\-sensitive\.

This shift creates demand for*compact*function\-calling models that can run on a phone\. Sub\-billion\-parameter models such as FunctionGemma 270M\-it\([DeepMind, 2025a](https://arxiv.org/html/2609.25373#bib.bib6)\), built on the Gemma 3 family\([Team et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib29);[DeepMind, 2025b](https://arxiv.org/html/2609.25373#bib.bib7)\), occupy this niche\. However, their training distribution still skews toward general tool use; the ready\-made on\-device specialization, FunctionGemma 270M Mobile Actions\([LiteRT Community and DeepMind, 2025](https://arxiv.org/html/2609.25373#bib.bib19)\), focuses on roughly seven mobile workflows \(calendar event creation, contact creation, mapping, email, Wi\-Fi settings, flashlight on/off\), leaving common everyday intents, like phone calls, SMS, brightness control, camera, screenshots, and application opening uncovered\.

In this study, we evaluate whether a small, targeted dataset of mobile\-action conversations is sufficient to extend a 270M\-parameter function\-calling model to a meaningfully broader set of on\-device intents*without*catastrophically forgetting the original distribution\. Concretely, we investigate three questions:

- •\(Q1\) Coverage gap\.How well does the publicly available FunctionGemma model handle mobile actions outside of its training distribution?
- •\(Q2\) Targeted fine\-tuning\.Does full supervised fine\-tuning on a synthetically generated, schema\-validated dataset of 15 mobile categories close that gap on a 270M backbone?
- •\(Q3\) Cross\-domain transfer\.Can a single fine\-tuned model serve both the original \(Google Mobile Actions\) and the new \(device\-action\) distributions?

Our contributions can be summarized as:

\(i\)An open mobile\-actions dataset\.We releaseMobileActionsExtended, a∼\\sim9,500\-example function\-calling corpus generated through schema\-grounded synthetic prompting, post\-validated for tool\-call legality, and split 90/10 between train and evaluation \(Section[4](https://arxiv.org/html/2609.25373#S4)\)\.

\(ii\)Two extended FunctionGemma fine\-tuned models\.We fine\-tune FunctionGemma 270M\-it with Transformers Reinforcement Learning \(TRL\) supervised fine\-tuning\([von Werra et al\., 2020](https://arxiv.org/html/2609.25373#bib.bib30);[Wolf et al\., 2020](https://arxiv.org/html/2609.25373#bib.bib33)\)under completion\-only loss, releasingFunctionGemma\-270M\-it\-Mobile\-Actions\-ExtendedandFunctionGemma\-270M\-it\-Mobile\-Actions\-Combined\.

\(iii\)A multi\-axis evaluation\.We compare four versions of the model on two held\-out splits using exact\-match metrics for function names, arguments, and end\-to\-end correctness \(Section[6](https://arxiv.org/html/2609.25373#S6)\)\.

\(iv\)An end\-to\-end pipeline\.We open\-source the full reproduction pipeline—from dataset generation through Hugging Face publishing, TRL fine\-tuning, and evaluation—as three independent packages\.

\(v\)An on\-device demo app \(*Handy Chat*\)\.We deploy \.litertlm version ofFunctionGemma\-270M\-it\-Mobile\-Actions\-Extendedin a Buildozer\-packaged Android app \(Python Kivy UI, PyJNIus Java bridge tolitertlm\-android, LiteRT\-LM inference on an exported\.litertlmbundle\) because the Google AI Edge Gallery\([Google AI Edge Team, 2026](https://arxiv.org/html/2609.25373#bib.bib11)\)does not support custom checkpoints in its Mobile Actions workflow \(Sections[7](https://arxiv.org/html/2609.25373#S7), Appendix[E](https://arxiv.org/html/2609.25373#A5)\)\.

Our extended model lifts end\-to\-end accuracy onMobileActionsExtendedfrom29\.3%29\.3\\%\(base\) and17\.2%17\.2\\%\(Google’s Mobile Actions variant\) to76\.5%76\.5\\%, with perfect function\-name accuracy on all fifteen categories\. The*combined*model preserves competitive performance onMobileActionsGoogle: end\-to\-end accuracy drops from90\.3%90\.3\\%for the Google specialist to82\.3%82\.3\\%, an 8\.0\-percentage\-point cost that we consider an acceptable trade\-off for doubling category coverage\. Remaining errors concentrate on optional\-boolean formatting \(dial\_call,create\_chooser\)\. Per\-category breakdown and failure analysis are presented in Appendix[C](https://arxiv.org/html/2609.25373#A3)\.

## 2Related Work

Modern tool\-using LLMs\([Schick et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib28);[Yao et al\., 2022](https://arxiv.org/html/2609.25373#bib.bib34);[Patil et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib26);[Qin et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib27);[OpenAI, 2023](https://arxiv.org/html/2609.25373#bib.bib24)\)replace classical intent\-and\-slot pipelines with schema\-conditioned structured output\. Compact function\-calling models, such as Granite Function Calling\([Abdelaziz et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib1)\), Hammer\([Lin et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib18)\), ToolACE\([Liu et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib20)\), and TinyAgent\([Erdogan et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib8)\)show that targeted fine\-tuning, not scale alone, drives quality at the edge\([Kavathekar et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib14)\)\. FunctionGemma 270M\-it\([DeepMind, 2025a](https://arxiv.org/html/2609.25373#bib.bib6)\)and Google’s Mobile Actions variant\([LiteRT Community and DeepMind, 2025](https://arxiv.org/html/2609.25373#bib.bib19)\)target on\-device deployment; however, available benchmarks such as BFCL\([Patil et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib25)\), BigCodeBench\([Zhuo et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib35)\), and APIGen\([Liu et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib21)\)focus on web APIs rather than Android system actions\. To the best of our knowledge,MobileActionsGoogleis the only public mobile\-actions function\-calling benchmark, and this study aims to extend it\. A more detailed summary of related works is available in Appendix[A](https://arxiv.org/html/2609.25373#A1)\.

## 3Task Definition and Tool Catalog

Table 1:Summary of the new Mobile\-Action categories: supported functions, descriptions, and arguments\.### 3\.1Function Calling as Structured Output

We use the standard formulation\. A*tool catalog*𝒯=\{T1,…,TK\}\\mathcal\{T\}=\\\{T\_\{1\},\\ldots,T\_\{K\}\\\}is a set of typed function declarations; eachTkT\_\{k\}has a name, a natural\-language description, and a parameter schema\. Given a system prompt, the catalog𝒯\\mathcal\{T\}, and a user utteranceuu, the model must produce an ordered sequence of calls

c^1,c^2,…,c^m,c^i=⟨namei,argsi⟩,namei∈\{T1,…,TK\}\.\\begin\{split\}\\hat\{c\}\_\{1\},\\hat\{c\}\_\{2\},\\ldots,\\hat\{c\}\_\{m\},\\ \\hat\{c\}\_\{i\}&=\\langle\\text\{name\}\_\{i\},\\text\{args\}\_\{i\}\\rangle,\\\\ &\\text\{name\}\_\{i\}\\in\\\{T\_\{1\},\\ldots,T\_\{K\}\\\}\.\\end\{split\}FunctionGemma renders calls and declarations with sentinel tokens \(<start\_function\_call\>,<end\_function\_call\>,<escape\>\) so that output can be deterministically parsed\.

### 3\.2Evaluation Granularity

Following[Patil et al\. \(2025\)](https://arxiv.org/html/2609.25373#bib.bib25), the evaluation is executed at three levels:function\-name accuracy\(exact match on ordered name lists\),argument exact match\(exact match on key\-sorted argument dictionaries\), andend\-to\-end correctness\(logical AND\)\. This strict criterion flags any extra or missing key as failure; we therefore complement it with an*execution\-aware*variant \(Section[6\.3](https://arxiv.org/html/2609.25373#S6.SS3)\) and discuss implications in Section[8](https://arxiv.org/html/2609.25373#S8)\.

### 3\.3New Mobile\-Action Categories

In this study, we extend FunctionGemma’s mobile coverage with the fifteen tools presented in Table[1](https://arxiv.org/html/2609.25373#S3.T1)\. The schemas \(full JSON in Appendix[D\.1](https://arxiv.org/html/2609.25373#A4.SS1)\) mirror Plyer\([Kivy Team, 2013](https://arxiv.org/html/2609.25373#bib.bib16)\)\-style cross\-platform Android APIs so that every call can be dispatched to a real handler in a demo runtime\. These categories cover daily “physical” assistant intents absent fromMobileActionsGoogle\(calls, SMS, brightness, camera, screenshots, app management\) and are implementable through Plyer on Android\.

## 4Dataset Construction:MobileActionsExtended

We aimed for a dataset that \(i\) is large enough to fine\-tune a 270M\-parameter backbone end to end, \(ii\) follows FunctionGemma’s exact chat\-template format, and \(iii\) is formatted similar toMobileActionsGoogle\([Google, 2025](https://arxiv.org/html/2609.25373#bib.bib9)\)so the two datasets can be merged easily for cross\-domain training\. Figure[1](https://arxiv.org/html/2609.25373#S4.F1)summarizes the full workflow from schema\-grounded generation through fine\-tuning, evaluation, and on\-device deployment\.

PromptTeacherLLMSyntheticpairsSchemavalidatorFG chatcompleterMA\-Ext\.∼\\sim9\.5KMA\-GoogleMA\-CombinedMA\-CombinedMA\-Ext\.∼\\sim9\.5KTRLfull SFTOurs–COurs–EExact\-matchEvaluationLitertlmHandy ChatKivy \+ BuildozerJava bridge \+ LiteRT\-LMdata generationfine\-tunedmodellightweightmodel

Figure 1:End\-to\-end pipeline\.Top:schema\-grounded synthetic generation, validation, FunctionGemma chat completion, and merge with Google’s mobile\-actions corpus\.Bottom:serving generated datasets, TRL fine\-tuning, fine\-tuned model, exact\-match evaluation, export lightweight\.litertlmmodel quantized by 8\-bit integer weight and 32\-bit float activation, and typed\-input deployment in*Handy Chat*\(Buildozer APK, PyJNIus Java bridge tolitertlm\-android, Plyer dispatch\)\. Dynamic INT8 quantization \(dynamic\_wi8\_afp32: 8\-bit integer weights, 32\-bit float activations\) is applied*solely*to the exported\.litertlmbundle used by the deployed LiteRT\-LM Android demo; all evaluation accuracy figures reported in this paper were measured on the unquantized Hugging Face checkpoints\. \(more details in Sections[4](https://arxiv.org/html/2609.25373#S4)–[7](https://arxiv.org/html/2609.25373#S7)and Appendices[D\.4](https://arxiv.org/html/2609.25373#A4.SS4)and[E](https://arxiv.org/html/2609.25373#A5)\.\)### 4\.1Schema\-Grounded Synthetic Generation

Raw conversations are generated by prompting a strong teacher with the JSON tool list and a worked output example\. The teacher produces \(i\)∼\\sim300 user prompts per single tool and \(ii\)∼\\sim5,000 multi\-tool prompts \(e\.g\.,*“check battery and take a screenshot”*\)\. Each record is auser/assistantpair with goldtool\_calls\. The full prompt is in Appendix[D\.3](https://arxiv.org/html/2609.25373#A4.SS3)\. This recipe follows APIGen\([Liu et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib21)\)and ToolACE\([Liu et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib20)\); unlike APIGen we do not execute calls during generation, relying instead on structural validation\.

### 4\.2Validation and Completion

A validator \(validate\_generated\_dataset\.py\) parses every assistant message and checks that: \(i\) every called function name is present in the catalog; \(ii\) allrequiredarguments are present and of the declared type; \(iii\) argument values match the schema’s primitive types \(STRING,BOOLEAN,NUMBER\)\. Records that fail validation are dropped or repaired withjson\_repair\. A completion script \(complete\_dataset\.py\) augments each surviving record with fields needed by FunctionGemma:metadata\(train/eval\),tools\(declarations\), andmessages\(developer,user,assistant\)\. Thedeveloperrole injects the current date/time and function declarations using sentinel tokens, exactly as in the official cookbook\.

### 4\.3Merging With Google’s Mobile Actions

To produceMobileActionsCombined, we union records fromMobileActionsExtendedwith all records fromMobileActionsGoogle\. Both datasets share identical schemas, so the merge requires no field surgery; we preserve per\-source train/eval flags so evaluation on each source remains held\-out\. The extended and merged datasets are published in[repo 1](https://huggingface.co/datasets/UGrowAI/Mobile-Actions-Extended)and[repo 2](https://huggingface.co/datasets/UGrowAI/Mobile-Actions-Combined), respectively\.

### 4\.4Statistics

MobileActionsExtendedcontains approximately9,5009\{,\}500records, split90/1090/10between train and evaluation\. The evaluation split contains965965examples spread across 15 categories; largest categories areopen\_application\(209 eval examples\) andphone\_sms\(114\)\. Approximately one third of prompts are multi\-call\. For comparison,MobileActionsGooglecontributes961961evaluation examples spanning 7 categories\. Full per\-category counts are in Appendix[D\.6](https://arxiv.org/html/2609.25373#A4.SS6)\.

## 5Model and Training

In this study, FunctionGemma 270M\-it\([DeepMind, 2025a](https://arxiv.org/html/2609.25373#bib.bib6)\)is fine\-tuned with Hugging Face Transformers\([Wolf et al\., 2020](https://arxiv.org/html/2609.25373#bib.bib33)\)and TRLSFTTrainer\([von Werra et al\., 2020](https://arxiv.org/html/2609.25373#bib.bib30)\)in completion\-only mode\. Key settings for this fine\-tuning are as follows: full SFT \(no PEFT/LoRA\) for two epochs, learning rate×10−51\\\!\\times\\\!10^\{\-5\}, cosine schedule with warmup, effective batch size 32 \(4 per device×\\times8 gradient accumulation\), bf16 mixed precision, gradient checkpointing enabled\. The 270M backbone fits comfortably on a single accelerator \(CUDA or Apple Silicon MPS\), so we avoid LoRA adapter complexity and keep deployment simple: a single set of weights replaces the pretrained ones, with no adapter merging at inference\. Full hyperparameters are in Appendix[B](https://arxiv.org/html/2609.25373#A2)\.

Training is done with completion\-only loss\. TRL’scompletion\_only\_loss=truemasks loss over the prompt \(system tools block, developer message, user turn\) so the model is graded only on its assistant continuation\. This stabilizes training when the prompt length dominates, which is common here because the tool catalog alone is several hundred tokens long\.

Two fine\-tuned models are trained under identical settings:FunctionGemma\-270M\-it\-Mobile\-Actions\-Extended\(trained onMobileActionsExtendedonly\) andFunctionGemma\-270M\-it\-Mobile\-Actions\-Combined\(trained on mergedMobileActionsCombined\)\. The first trained model targets coverage gap \(aforementioned Q1\) and targeted fine\-tuning \(Q2\); and the second one focuses more on cross\-domain transfer \(Q3\)\.

At inference, decoding is done greedily \(do\_sample=False,temperature=0\.0,max\_new\_tokens=1024\) and parsing is implemented with a regex decoder \(Appendix[D\.5](https://arxiv.org/html/2609.25373#A4.SS5)\)\. We do not employ schema\-constrained decoding\([Willard and Louf, 2023](https://arxiv.org/html/2609.25373#bib.bib32)\), ensuring that the reported results reflect the model’s unconstrained generation behavior\. The extended and combined fine\-tuned models are publicly available\.

Table 2:Function\-name, argument exact\-match, and end\-to\-end accuracy \(%\) on held\-out eval splits\. Base =FunctionGemma270Mit Base; Google MA =FunctionGemma\-270M\-Mobile\-Actions; Ours: MA\-Extended =FunctionGemma\-270M\-it\-Mobile\-Actions\-Extended; Ours: MA\-Combined =FunctionGemma\-270M\-it\-Mobile\-Actions\-Combined\. Best per column in bold\. Per\-category breakdown in Appendix[C](https://arxiv.org/html/2609.25373#A3)\.
## 6Experiments

### 6\.1Models and Evaluation

We compare four models, all sharing the FunctionGemma 270M\-it architecture:

1. 1\.FunctionGemma270Mit Base–google/functiongemma\-270m\-it\([DeepMind, 2025a](https://arxiv.org/html/2609.25373#bib.bib6)\): instruction\-tuned but not specialized to mobile actions\.
2. 2\.FunctionGemma\-270M\-Mobile\-Actions–litert\-community/FunctionGemma\_270M\_Mobile\_Actions\([LiteRT Community and DeepMind, 2025](https://arxiv.org/html/2609.25373#bib.bib19)\): public mobile\-actions specialization onMobileActionsGoogle\.
3. 3\.FunctionGemma\-270M\-it\-Mobile\-Actions\-Extended– our fine\-tuned[model](https://huggingface.co/UGrowAI/FunctionGemma-270M-it-Mobile-Actions-Extended)onMobileActionsExtended\.
4. 4\.FunctionGemma\-270M\-it\-Mobile\-Actions\-Combined– our fine\-tuned[model](https://huggingface.co/UGrowAI/FunctionGemma-270M-it-Mobile-Actions-Combined)on merged data:MobileActionsCombined\.

Evaluation uses held\-out*eval*splits ofMobileActionsExtended\(965965examples, 15 categories\) andMobileActionsGoogle\(961961examples, 7 categories\)\. Each model produces tool calls; our parser extracts*\(name, args\)*tuples and we compute the three metrics introduced in Section[3](https://arxiv.org/html/2609.25373#S3)\. The pipeline matches Google’s FunctionGemma cookbook which is re\-implemented in ourFGemma\_Evaluationpackage\.

### 6\.2Results

Table[2](https://arxiv.org/html/2609.25373#S5.T2)summarizes the results in terms of accuracy in held\-out sets\.

##### Coverage gap \(Q1\)\.

The base FunctionGemma 270M\-it scores29\.3%29\.3\\%end\-to\-end onMobileActionsExtended\. The Google\-fine\-tuned variant performs worse \(17\.2%17\.2\\%\); fine\-tuning on seven Google categories actively hurts on the fifteen extended categories, presumably because the model now confidently emits in\-distribution calls \(e\.g\.,open\_wifi\_settings\) instead of the correct extended ones\.

##### Targeted fine\-tuning \(Q2\)\.

FunctionGemma\-270M\-it\-Mobile\-Actions\-Extendedreaches100%100\\%function\-name accuracy and76\.5%76\.5\\%end\-to\-end onMobileActionsExtended—a\+47\.2\+47\.2\-point improvement over the base model\. The remaining23\.5%23\.5\\%are argument\-level errors, concentrated on optional booleans \(see Appendix[C](https://arxiv.org/html/2609.25373#A3)\)\.

##### Cross\-domain transfer \(Q3\)\.

FunctionGemma\-270M\-it\-Mobile\-Actions\-CombinedmatchesFunctionGemma\-270M\-it\-Mobile\-Actions\-ExtendedonMobileActionsExtended\(76\.5%76\.5\\%\) and reaches82\.3%82\.3\\%onMobileActionsGoogle, only∼\\sim8 points below the Google specialist trained exclusively on that distribution\. Training only onMobileActionsExtendedyields60\.2%60\.2\\%onMobileActionsGoogle: the merge step matters\.

### 6\.3Execution\-Aware Accuracy

Table 3:Strict exact\-match vs\. execution\-aware end\-to\-end accuracy \(%\) on the held\-out eval splits \(n=965n=965andn=961n=961\)\. Column abbreviations as in Table[2](https://arxiv.org/html/2609.25373#S5.T2)\. Full per\-category tables are in Appendix[C\.2](https://arxiv.org/html/2609.25373#A3.SS2)\.Strict exact match understates deployable quality because it penalizes omissions that a runtime would recover from\. We therefore re\-score all predictions with an*execution\-aware*criterion: the function\-name sequence must still match exactly, and every schema\-required argument must be present and correct,*unless*it belongs to a short, explicit safe\-default list \(phone\_call\.dial\_callandsend\_email\.create\_chooser, both booleans defaulted tofalseby the on\-device dispatcher\); any other schema\-valid optional argument may be freely added or dropped, while a hallucinated \(non\-schema\) key remains a failure because it would raise a runtime error in the real dispatcher\.

Table[3](https://arxiv.org/html/2609.25373#S6.T3)contrasts the two metrics\. ForFunctionGemma\-270M\-it\-Mobile\-Actions\-Extended, execution\-aware accuracy onMobileActionsExtendedreaches100\.0%100\.0\\%\(from76\.5%76\.5\\%strict\): every remaining strict\-metric “error” is a recoverable formatting issue, not a wrong tool selection\.FunctionGemma\-270M\-it\-Mobile\-Actions\-Combinedrises to96\.0%96\.0\\%onMobileActionsExtendedand82\.6%82\.6\\%onMobileActionsGoogle\. The base and Google\-specialist models gain little on out\-of\-distribution data \(\+8\.3\+8\.3and\+0\.0\+0\.0points onMobileActionsExtended, respectively\), confirming that their failures are genuine tool\-selection errors rather than metric artifacts\.

### 6\.4Error Analysis

Per\-category tables \(Appendix[C](https://arxiv.org/html/2609.25373#A3)\) show100%100\\%function\-name accuracy on every extended category for fine\-tuned models\. The dominant error classes are: \(i\)Optional\-boolean omission\.Forphone\_callandsend\_email, gold labels include routing booleans \(dial\_call,create\_chooser\) that the model omits; the executed action would still be correct\. \(ii\)Free\-text argument noise\.Onphone\_smsand Google’sshow\_map, the model occasionally normalizes phone numbers or rephrases location strings—partly a labelling\-ambiguity issue\. \(iii\)Multi\-call ordering\.A small number of multi\-call examples flip call order; addressable with more multi\-call training data\. None of these implicate the backbone’s structural ability to function\-call; they are dataset\-level signal\-quality issues \(full failure\-mode review in Appendix[C](https://arxiv.org/html/2609.25373#A3)\)\.

## 7On\-Device Demo: Handy Chat

We validated deployability with*[Handy Chat](https://github.com/UgrowAI/HandyChat-apk/releases/latest/download/HandyChat.apk)*, a standalone Android application packaged with Buildozer\([Kivy Team, 2024](https://arxiv.org/html/2609.25373#bib.bib17)\)\. The Google AI Edge Gallery\([Google AI Edge Team, 2026](https://arxiv.org/html/2609.25373#bib.bib11)\)showcases on\-device models but does not expose a supported path to load custom checkpoints into its pre\-configured Mobile Actions workflow; we therefore built a dedicated app\. The demo runs on a Google Pixel 8 Pro \(Tensor G3, 12 GB RAM, Android 16\) using the LiteRT\-LM CPU backend; across informal prompt trials, a function\-call turn takes roughly 13 s end to end \(pass 1∼\\sim9 s, tool execution∼\\sim2 s, pass 2∼\\sim2 s\)\. Full hardware, export, and latency details are in Appendix[E](https://arxiv.org/html/2609.25373#A5)\.

## 8Discussion

The results show that a compact 270M\-parameter function\-calling model can be adapted to practical mobile\-device control with a relatively small, schema\-grounded dataset\. A key advantage of the 270M backbone is that it can be deployed locally on the device rather than sending every request to a cloud\-hosted provider model\. This is important for mobile assistants because user requests may contain sensitive information such as contact names, phone numbers, email addresses, application names, device state, or private intent\. Local inference reduces network round\-trip latency and minimizes unnecessary transfer of user data to external providers\. The exported\.litertlmbundle occupies 285\.6 MB on device \(dynamic\_wi8\_afp32\); this quantization applies only to the deployed demo, not to any reported accuracy figure\. Handy Chat runs inference on the LiteRT\-LM CPU backend of a Google Pixel 8 Pro, where a typical function\-call turn completes in roughly 13 seconds end to end \(Section[7](https://arxiv.org/html/2609.25373#S7)\)\.

The Google Mobile Actions fine\-tuned model performs strongly on its original seven\-category distribution, but regresses on extended functions, dropping to 17\.2% exact\-match end\-to\-end accuracy compared with 29\.3% for the base model\. This indicates that narrow fine\-tuning can over\-concentrate the model’s prior on its original tool catalog\. Combined\-domain training addresses this issue, preserving 76\.5% end\-to\-end accuracy on extended functions while reaching 82\.3% on original Google functions\. This supports a unified mobile\-action training mixture rather than separate narrow specialists\.

The main remaining failures in the combined model are not wrong function choices, but argument\-format mismatches\. In particular,phone\_callandsend\_emailfail strict exact match mostly because the model omits optional routing booleans such asdial\_callandcreate\_chooser\. The intended user\-visible action is still correct, and a forgiving execution layer could fill safe defaults\. We therefore expect simple post\-processing to raise end\-to\-end accuracy from 76\.5% to roughly 84%\. Other residual errors involve phone\-number normalization, free\-text rephrasing, and occasional multi\-call ordering mistakes\.

For industrial deployment, exact\-match accuracy should be complemented with execution\-aware evaluation that separates unsafe tool selection from recoverable schema\-formatting errors, as quantified in Section[6\.3](https://arxiv.org/html/2609.25373#S6.SS3)\(Table[3](https://arxiv.org/html/2609.25373#S6.T3)\)\. Runtime validation, default filling, Android permission checks, and explicit confirmation for side\-effecting actions such as calls, SMS, email, and application opening should be treated as part of the system design\. Overall, compact on\-device function\-calling models are a practical path toward low\-latency, privacy\-preserving mobile assistants when paired with careful data coverage and defensive execution logic\.

## Conclusion

We extended FunctionGemma 270M\-it toward practical on\-device mobile function calling by introducing MOBILEACTIONSEXTENDED, a synthetic and schema\-validated dataset covering fifteen Android\-control categories that are underrepresented in existing public mobile\-action resources\. With full supervised fine\-tuning under completion\-only loss, the extended model improves end\-to\-end accuracy on MOBILEACTIONSEXTENDED from 29\.3% to 76\.5%, while the combined model preserves 82\.3% accuracy on Google’s original Mobile Actions benchmark and broadens coverage to a larger action catalog\. These results show that compact function\-calling models can be effectively adapted to everyday device\-control workflows through targeted data curation, without relying on large cloud\-hosted models for every request\. Overall, this work shows that compact, locally deployable function\-calling models are a promising foundation for practical mobile assistants when paired with broad action coverage and defensive execution logic\.

## Limitations

This study focuses on demonstrating the feasibility of extending a compact on\-device function\-calling model to a broader Android action catalog\. As a result, several dimensions remain open for future work\. First,MobileActionsExtendedis synthetically generated and schema\-validated rather than collected from real users\. This enables controlled coverage across functions and arguments, but real deployments may involve noisier inputs, including ASR errors, incomplete requests, ambiguous references, and more diverse phrasing\. Collecting user\-consented interaction data is an important next step for measuring robustness in realistic mobile\-assistant settings\.

Second, our evaluation uses strict exact match over function names and argument dictionaries\. This choice makes the benchmark reproducible and intentionally conservative, but it can underestimate executable success\. In particular, optional\-default fields such asdial\_callandcreate\_chooserare counted as errors when omitted, even though a runtime could safely fill defaults or request confirmation\. The execution\-aware re\-scoring of Section[6\.3](https://arxiv.org/html/2609.25373#S6.SS3)quantifies this gap, and future evaluations should adopt such metrics alongside strict exact match\.

Third, all results are obtained using a single base\-model family: every model we compare shares the FunctionGemma 270M\-it backbone\. We chose it because it is, to our knowledge, the only openly released sub\-billion\-parameter model that has been fine\-tuned by its original authors for mobile\-action calling, making it a natural point of comparison for this resource\. Nevertheless, the generality of our approach across architectures remains unverified\. Evaluating the same training recipe on a second compact family such as a similarly sized Qwen or SmolLM2 checkpoint is an important direction for future work\.

Fourth, the current dataset and demo are limited mainly to English and Android\. Extending the tool catalog, data generation process, and runtime handlers to other languages, iOS, and additional device APIs would make the approach more broadly applicable\. The present examples are also single\-turn, mapping one user message to one tool\-call sequence; multi\-turn clarification and correction remain important directions for practical assistants\.

Finally, side\-effecting tools such as phone calls, SMS, email, and application opening require careful runtime mediation\. Our current training data does not include adversarial or unsafe\-intent prompts, and production deployment should include Android permission checks, confirmation UI, and adversarial safety evaluation\. Future work includes constrained decoding for optional fields, real\-user data collection, multi\-turn dialogue, quantization\-aware fine\-tuning, and joint training with broader web\-API function\-calling benchmarks\([Patil et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib25);[Zhuo et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib35)\)\.

## Ethical Considerations

Side\-effecting categories \(phone\_call,phone\_sms,send\_email,open\_application\) must route through Android permission and confirmation UI rather than executing silently\. The dataset uses synthetic phone numbers \(\+14165550xxx\) and email addresses \(example\.com\); no real user data is included\. We recommend adversarial and unsafe\-intent test slices before production deployment\([Patil et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib25)\)\.

## References

- Abdelaziz et al\. \(2024\)Ibrahim Abdelaziz, Kinjal Basu, Mayank Agarwal, Sadhana Kumaravel, Matthew Stallone, Rameswar Panda, Yara Rizk, GP Shrivatsa Bhargav, Maxwell Crouse, Chulaka Gunasekara, Shajith Ikbal, Sachin Joshi, Hima Karanam, Vineet Kumar, Asim Munawar, Sumit Neelam, Dinesh Raghu, Udit Sharma, Adriana Meza Soria, and 7 others\. 2024\.Granite\-function calling model: Introducing function calling abilities via multi\-task learning of granular tasks\.In*Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing: Industry Track*, pages 1131–1139\.
- Abdin et al\. \(2024\)Marah Abdin, Jyoti Aneja, Harkirat Behl, Sébastien Bubeck, Ronen Eldan, Suriya Gunasekar, Michael Harrison, Russell J Hewett, Mojan Javaheripi, Piero Kauffmann, and 1 others\. 2024\.Phi\-4 technical report\.*arXiv preprint arXiv:2412\.08905*\.
- Anthropic \(2024\)Anthropic\. 2024\.Tool Use with Claude\.[https://docs\.anthropic\.com/claude/docs/tool\-use](https://docs.anthropic.com/claude/docs/tool-use)\.Accessed: 2026\-04\-26\.
- Bai et al\. \(2023\)Jinze Bai, Shuai Bai, Yunfei Chu, Zeyu Cui, Kai Dang, Xiaodong Deng, Yang Fan, Wenbin Ge, Yu Han, Fei Huang, and 1 others\. 2023\.Qwen Technical Report\.*arXiv preprint arXiv:2309\.16609*\.
- Bhan et al\. \(2024\)Nirav Bhan, Shival Gupta, Sai Manaswini, Ritik Baba, Narun Yadav, Hillori Desai, Yash Choudhary, Aman Pawar, Sarthak Shrivastava, and Sudipta Biswas\. 2024\.Benchmarking floworks against openai & anthropic: A novel framework for enhanced llm function calling\.*arXiv preprint arXiv:2410\.17950*\.
- DeepMind \(2025a\)Google DeepMind\. 2025a\.Functiongemma 270m instruction\-tuned \(it\) model checkpoint\.[https://huggingface\.co/google/functiongemma\-270m\-it](https://huggingface.co/google/functiongemma-270m-it)\.
- DeepMind \(2025b\)Google DeepMind\. 2025b\.Gemma 3 270m model checkpoint\.[https://huggingface\.co/google/gemma\-3\-270m](https://huggingface.co/google/gemma-3-270m)\.
- Erdogan et al\. \(2024\)Lutfi Eren Erdogan, Nicholas Lee, Siddharth Jha, Sehoon Kim, Ryan Tabrizi, Suhong Moon, Coleman Richard Charles Hooper, Gopala Anumanchipalli, Kurt Keutzer, and Amir Gholami\. 2024\.Tinyagent: Function calling at the edge\.In*Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing: System Demonstrations*, pages 80–88\.
- Google \(2025\)Google\. 2025\.Mobile Actions: A Function\-Calling Dataset for Mobile Tools\.[https://huggingface\.co/datasets/google/mobile\-actions](https://huggingface.co/datasets/google/mobile-actions)\.Accessed: 2026\-04\-26\.
- Google AI Edge \(2025\)Google AI Edge\. 2025\.LiteRT\-LM: On\-Device LLM Inference Framework\.[https://developers\.google\.com/edge/litert\-lm](https://developers.google.com/edge/litert-lm)\.
- Google AI Edge Team \(2026\)Google AI Edge Team\. 2026\.Google AI edge: High\-performance on\-device ML and GenAI deployment frameworks\.[https://play\.google\.com/store/apps/details?id=com\.google\.ai\.edge\.gallery](https://play.google.com/store/apps/details?id=com.google.ai.edge.gallery)\.
- Hsieh et al\. \(2023\)Cheng\-Yu Hsieh, Si\-An Chen, Chun\-Liang Li, Yasuhisa Fujii, Alexander Ratner, Chen\-Yu Lee, Ranjay Krishna, and Tomas Pfister\. 2023\.Tool documentation enables zero\-shot tool\-usage with large language models\.*arXiv preprint arXiv:2308\.00675*\.
- Kate et al\. \(2025\)Kiran Kate, Tejaswini Pedapati, Kinjal Basu, Yara Rizk, Vijil Chenthamarakshan, Subhajit Chaudhury, Mayank Agarwal, and Ibrahim Abdelaziz\. 2025\.Longfunceval: Measuring the effectiveness of long context models for function calling\.*arXiv preprint arXiv:2505\.10570*\.
- Kavathekar et al\. \(2025\)Ishan Kavathekar, Raghav Donakanti, Ponnurangam Kumaraguru, and Karthik Vaidhyanathan\. 2025\.Small models, big tasks: An exploratory empirical study on small language models for function calling\.In*Proceedings of the 29th international conference on evaluation and assessment in software engineering*, pages 1117–1126\.
- Kim et al\. \(2023\)Sehoon Kim, Suhong Moon, Ryan Tabrizi, Nicholas Lee, Michael W\. Mahoney, Kurt Keutzer, and Amir Gholami\. 2023\.An LLM Compiler for Parallel Function Calling\.*arXiv preprint arXiv:2312\.04511*\.
- Kivy Team \(2013\)Kivy Team\. 2013\.Plyer: A platform\-independent python api for accessing hardware features\.[https://github\.com/kivy/plyer](https://github.com/kivy/plyer)\.
- Kivy Team \(2024\)Kivy Team\. 2024\.Buildozer: Generic Python Packager for Android and iOS\.[https://github\.com/kivy/buildozer](https://github.com/kivy/buildozer)\.Accessed: 2026\-04\-26\.
- Lin et al\. \(2024\)Qiqiang Lin, Muning Wen, Qiuying Peng, Guanyu Nie, Junwei Liao, Jun Wang, Xiaoyun Mo, Jiamu Zhou, Cheng Cheng, Yin Zhao, Jun Wang, and Weinan Zhang\. 2024\.[Hammer: Robust function\-calling for on\-device language models via function masking](https://arxiv.org/abs/2410.04587)\.*Preprint*, arXiv:2410\.04587\.
- LiteRT Community and DeepMind \(2025\)LiteRT Community and Google DeepMind\. 2025\.Functiongemma 270m fine\-tuned mobile actions \(litert format\)\.[https://huggingface\.co/litert\-community/functiongemma\-270m\-ft\-mobile\-actions](https://huggingface.co/litert-community/functiongemma-270m-ft-mobile-actions)\.
- Liu et al\. \(2025\)Weiwen Liu, Xu Huang, Xingshan Zeng, Shuai Yu, Dexun Li, Shuai Wang, Weinan Gan, Zhengying Liu, Yuanqing Yu, Zezhong WANG, and 1 others\. 2025\.Toolace: Winning the points of llm function calling\.In*International conference on learning representations*, volume 2025, pages 41359–41381\.
- Liu et al\. \(2024\)Zuxin Liu, Thai Hoang, Jianguo Zhang, Ming Zhu, Tian Lan, Shirley Kokane, Juntao Tan, Weiran Yao, Zhiwei Liu, Yihao Feng, and 1 others\. 2024\.Apigen: Automated pipeline for generating verifiable and diverse function\-calling datasets\.*Advances in Neural Information Processing Systems*, 37:54463–54482\.
- Loshchilov and Hutter \(2016\)Ilya Loshchilov and Frank Hutter\. 2016\.Sgdr: Stochastic gradient descent with warm restarts\.*arXiv preprint arXiv:1608\.03983*\.
- Loshchilov and Hutter \(2017\)Ilya Loshchilov and Frank Hutter\. 2017\.Decoupled weight decay regularization\.*arXiv preprint arXiv:1711\.05101*\.
- OpenAI \(2023\)OpenAI\. 2023\.Function calling and other API updates\.[https://openai\.com/index/function\-calling\-and\-other\-api\-updates/](https://openai.com/index/function-calling-and-other-api-updates/)\.Published June 13, 2023; Accessed August 27, 2026\.
- Patil et al\. \(2025\)Shishir G\. Patil, Huanzhi Mao, Charlie Cheng\-Jie Ji, Fanjia Yan, Vishnu Suresh, Ion Stoica, and Joseph E\. Gonzalez\. 2025\.The berkeley function calling leaderboard \(bfcl\): From tool use to agentic evaluation of large language models\.In*Forty\-second International Conference on Machine Learning*\.
- Patil et al\. \(2024\)Shishir G Patil, Tianjun Zhang, Xin Wang, and Joseph E Gonzalez\. 2024\.Gorilla: Large language model connected with massive apis\.*Advances in Neural Information Processing Systems*, 37:126544–126565\.
- Qin et al\. \(2024\)Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, and 1 others\. 2024\.Toolllm: Facilitating large language models to master 16000\+ real\-world apis\.In*International Conference on Learning Representations*, volume 2024, pages 9695–9717\.
- Schick et al\. \(2023\)Timo Schick, Jane Dwivedi\-Yu, Roberto Dessi, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom\. 2023\.[Toolformer: Language models can teach themselves to use tools](https://openreview.net/forum?id=Yacmpz84TH)\.In*Thirty\-seventh Conference on Neural Information Processing Systems*\.
- Team et al\. \(2024\)Gemma Team, Thomas Mesnard, Cassidy Hardin, Robert Dadashi, Surya Bhupatiraju, Shreya Pathak, Laurent Sifre, Morgane Rivière, Mihir Sanjay Kale, Juliette Love, and 1 others\. 2024\.Gemma: Open models based on gemini research and technology\.*arXiv preprint arXiv:2403\.08295*\.
- von Werra et al\. \(2020\)Leandro von Werra, Younes Belkada, Lewis Tunstall, Edward Beeching, Tristan Thrush, Nathan Lambert, Shengyi Huang, Kashif Rasul, and Quentin Gallouédec\. 2020\.Trl: Transformers reinforcement learning\.[https://github\.com/huggingface/trl](https://github.com/huggingface/trl)\.Accessed: 2026\-04\-26\.
- Wang et al\. \(2026\)Maolin Wang, Yingyi Zhang, Bowen Yu, Bingguang Hao, Cunyin Peng, Yicheng Chen, Wei Zhou, Jinjie Gu, Chenyi Zhuang, Ruocheng Guo, and 1 others\. 2026\.Function calling in large language models: Industrial practices, challenges, and future directions\.*ACM Computing Surveys*, 58\(9\):1–37\.
- Willard and Louf \(2023\)Brandon T\. Willard and Rémi Louf\. 2023\.Efficient Guided Generation for Large Language Models\.In*arXiv preprint arXiv:2307\.09702*\.
- Wolf et al\. \(2020\)Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Rémi Louf, Morgan Funtowicz, and 1 others\. 2020\.Transformers: State\-of\-the\-art natural language processing\.In*Proceedings of the 2020 conference on empirical methods in natural language processing: system demonstrations*, pages 38–45\.
- Yao et al\. \(2022\)Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao\. 2022\.React: Synergizing reasoning and acting in language models\.*arXiv preprint arXiv:2210\.03629*\.
- Zhuo et al\. \(2024\)Terry Yue Zhuo, Minh Chien Vu, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, and 1 others\. 2024\.BigCodeBench: Benchmarking Code Generation with Diverse Function Calls and Complex Instructions\.*arXiv preprint arXiv:2406\.15877*\.

## Supplementary Materials

## Appendix AExtended Related Work

### A\.1From Slot Filling to Function Calling

Mapping natural language to executable code has a long history\. Classical spoken dialogue systemsfactor the problem into intent classification followed by slot filling: a small inventory of intents is matched by handcrafted grammars or feature\-based classifiers, and remaining slots \(recipient, time, application\) are filled by sequence labellers\. Such systems generalize poorly to long\-tail phrasings and require manual maintenance\. Semantic parsing approaches subsequently learned mappings from utterances to logical forms or structured queries, but were largely dataset\-specific\.

Modern*tool\-using*language models replace these task\-specific stacks with a single instruction\-tuned LLM that, given a list of available tools and a user query, emits a structured call\([Schick et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib28);[Yao et al\., 2022](https://arxiv.org/html/2609.25373#bib.bib34)\)\.*Toolformer*\([Schick et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib28)\)demonstrated that LLMs can be self\-supervised to invoke tools;*ReAct*\([Yao et al\., 2022](https://arxiv.org/html/2609.25373#bib.bib34)\)interleaved reasoning and action generation;*Gorilla*\([Patil et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib26)\)and ToolLLM\([Qin et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib27)\)showed how to scale to thousands of APIs\. OpenAI\([OpenAI, 2023](https://arxiv.org/html/2609.25373#bib.bib24)\)and Anthropic\([Anthropic, 2024](https://arxiv.org/html/2609.25373#bib.bib3)\)subsequently formalized function calling as a first\-class API feature, making structured outputs the default I/O format for tool\-using assistants\. Tool documentation\([Hsieh et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib12)\)has been shown to enable strong zero\-shot tool use, motivating schema\-rich prompting strategies\.

### A\.2Compact Function\-Calling Models

A growing body of work targets*small*function\-calling models\. Granite Function Calling\([Abdelaziz et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib1)\)introduces multi\-task training across granular sub\-tasks \(function selection, slot filling, response generation\)\. Hammer\([Lin et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib18)\)proposes a function\-masking objective that improves robustness in on\-device settings\. ToolACE\([Liu et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib20)\)aggressively curates tool\-use trajectories\. TinyAgent\([Erdogan et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib8)\)and the LLM Compiler\([Kim et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib15)\)demonstrate that planning and parallel function calling can be moved to the edge\.*Small Models, Big Tasks*\([Kavathekar et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib14)\)surveys the empirical landscape of sub\-3B function\-calling LLMs and finds that targeted fine\-tuning, rather than pure scale, drives most quality gains\.

The Gemma family\([Team et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib29);[DeepMind, 2025b](https://arxiv.org/html/2609.25373#bib.bib7)\)and its function\-tuned descendant FunctionGemma 270M\-it\([DeepMind, 2025a](https://arxiv.org/html/2609.25373#bib.bib6)\)occupy the most aggressive end of this trend at 270M parameters, designed for “hyper\-efficient” on\-device deployment\. The pre\-fine\-tuned community variant FunctionGemma 270M Mobile Actions\([LiteRT Community and DeepMind, 2025](https://arxiv.org/html/2609.25373#bib.bib19)\)was released alongside Google’sMobileActionsGoogledataset\([Google, 2025](https://arxiv.org/html/2609.25373#bib.bib9)\)and covers seven mobile workflows\. Phi\-3\-mini\([Abdin et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib2)\)and Qwen\([Bai et al\., 2023](https://arxiv.org/html/2609.25373#bib.bib4)\)provide larger but still on\-device\-feasible alternatives\. Our work builds on FunctionGemma 270M\-it and asks how far purely*data\-driven*extension can take it\.

### A\.3Function\-Calling Benchmarks

The Berkeley Function Calling Leaderboard \(BFCL\)\([Patil et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib25)\)is the de\-facto reference for function\-calling evaluation, covering simple, parallel, multiple, and live function calls across many languages\. BigCodeBench\([Zhuo et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib35)\)stresses diverse function calls and complex instructions\. LongFuncEval\([Kate et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib13)\)measures degradation under long contexts and many\-tool catalogs\. APIGen\([Liu et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib21)\)contributes both a benchmark and a verifiable synthetic\-data pipeline\. Floworks\([Bhan et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib5)\)evaluates large commercial models on enterprise function\-calling tasks\. None of these benchmarks specifically target Android system\-level actions;MobileActionsGoogleis, to our knowledge, the only public mobile\-actions function\-calling benchmark, and we extend it\.

### A\.4Synthetic Data Generation for Tool Use

Function\-calling datasets are typically synthetic: a strong teacher LLM is prompted with the tool schemas and asked to produce diverse user queries and gold tool calls\. APIGen\([Liu et al\., 2024](https://arxiv.org/html/2609.25373#bib.bib21)\)formalizes this pipeline with verifiability checks, and ToolACE\([Liu et al\., 2025](https://arxiv.org/html/2609.25373#bib.bib20)\)emphasizes points\-style scoring during curation\. Our dataset construction follows the same overall recipe \(Section[4](https://arxiv.org/html/2609.25373#S4)\): we ground the teacher in the exact tool schema, generate hundreds of single\-tool prompts plus thousands of multi\-tool combinations, validate with a parser that re\-checks names and required arguments, and then complete each record into the FunctionGemma chat\-template format used by the backbone\.

## Appendix BTraining Hyperparameters

Full supervised fine\-tuning settings \(bothFunctionGemma\-270M\-it\-Mobile\-Actions\-ExtendedandFunctionGemma\-270M\-it\-Mobile\-Actions\-Combined\):

Table 4:Supervised fine\-tuning configuration\. The same configuration is used to train bothFunctionGemma\-270M\-it\-Mobile\-Actions\-ExtendedandFunctionGemma\-270M\-it\-Mobile\-Actions\-Combined; only the dataset differs\.
## Appendix CPer\-Category and Failure Analysis

Table[5](https://arxiv.org/html/2609.25373#A3.T5)drills into per\-category accuracy onMobileActionsExtended\. The fine\-tuned models hit100%100\\%name accuracy on every category\. The two clear “argument cliffs” arephone\_call\(0%0\\%argument accuracy\) andsend\_email\(0%0\\%argument accuracy\), pulling the headline number down by roughly77absolute points\. Both failures share a single root cause: the gold labels include a boolean argument \(dial\_callfor phone calls,create\_chooserfor emails\) that the model omits from its output\. The function name is correct, the user\-visible action is correct, and a forgiving execution layer would accept the calls; only our*strict*exact\-match metric counts them as failures\. We discuss in Section[8](https://arxiv.org/html/2609.25373#S8)why this is a low\-cost issue \(constrained decoding or a default\-fill post\-processor solves it without retraining\)\.

A second pattern isphone\_sms\(29\.8% argument accuracy\)\. Inspection of failures shows that the model occasionally substitutes phone\-number normalization \(\+14165550104vs\.14165550104\) or shortens long natural\-language messages, both of which are real ambiguity in the gold labels rather than model defects\.

Table 5:Exact\-match end\-to\-end accuracy \(%\) per category on the held\-outMobileActionsExtendedeval split, grouped by the first call in each example\. Column abbreviations as in Table[2](https://arxiv.org/html/2609.25373#S5.T2)\. The two zero rows \(phone\_call,send\_email\) are the boolean\-argument failure mode discussed above\.Table[6](https://arxiv.org/html/2609.25373#A3.T6)reports the same breakdown onMobileActionsGoogle\.FunctionGemma\-270M\-it\-Mobile\-Actions\-Combinedretains 80–95% accuracy on every Google category; the largest residual gap toFunctionGemma\-270M\-Mobile\-Actionsis onshow\_map\(62\.8% vs\. 74\.3%\), which involves free\-form location strings\.

Table 6:Exact\-match end\-to\-end accuracy \(%\) per category on the held\-outMobileActionsGoogleeval split\. Column abbreviations as in Table[2](https://arxiv.org/html/2609.25373#S5.T2)\. Ours: MA\-Combined preserves competitive performance on every Google category despite training on twice as many functions\.### C\.1Failure\-Mode Analysis

We manually reviewed the per\-row logs produced by our evaluation pipeline\. The dominant error classes are:

1. 1\.Optional\-boolean omission\.Forphone\_callthe gold includesdial\_call: false\(ortrue\); the model emits onlynumber\. Forsend\_emailthe gold includescreate\_chooser: false; the model emits onlyto,subject,body\. These are pure schema\-formatting mismatches; the action that would be executed is correct\.
2. 2\.Free\-text argument noise\.Onphone\_smsand on Google’sshow\_map, the model occasionally rephrases or normalizes free\-text arguments\. This is partly a labelling\-ambiguity issue\.
3. 3\.Multi\-call ordering on rare combinations\.A small number of multi\-call examples inphone\_sms\+phone\_callpairs flip the order or merge adjacent calls\. These are addressable with more multi\-call training data\.
4. 4\.Out\-of\-distribution generalization\. OnMobileActionsGoogle’screate\_contactandcreate\_calendar\_event,FunctionGemma\-270M\-it\-Mobile\-Actions\-Combinedoccasionally drops less\-common optional fields \(e\.g\.,emailvs\.phone\_number\); the function name is correct but the strict argument metric flags it\.

None of these classes implicate the backbone’s structural ability to function\-call; they are dataset\-level signal\-quality issues that targeted data augmentation can resolve\.

### C\.2Per\-Category Execution\-Aware Accuracy

Tables[7](https://arxiv.org/html/2609.25373#A3.T7)and[8](https://arxiv.org/html/2609.25373#A3.T8)report the per\-category breakdown of the execution\-aware metric of Section[6\.3](https://arxiv.org/html/2609.25373#S6.SS3), complementing the aggregate comparison of Table[3](https://arxiv.org/html/2609.25373#S6.T3); the strict exact\-match counterparts are Tables[5](https://arxiv.org/html/2609.25373#A3.T5)and[6](https://arxiv.org/html/2609.25373#A3.T6)\.

OnMobileActionsExtended, Ours: MA\-Extended reaches100%100\\%execution\-aware accuracy on*every*category: the strict\-metric “argument cliffs” disappear entirely \(phone\_call→100\.00\.0\\\!\\rightarrow\\\!100\.0,send\_email→100\.00\.0\\\!\\rightarrow\\\!100\.0,phone\_sms→100\.029\.8\\\!\\rightarrow\\\!100\.0,open\_application→100\.067\.0\\\!\\rightarrow\\\!100\.0\)\. Ours: MA\-Combined behaves almost identically, with residual gaps only onsend\_email\(82\.8%\),phone\_sms\(71\.1%\), andopen\_application\(99\.5%\)\. By contrast, Google MA gains nothing in any extended category \(its scores are identical under both metrics\), confirming that its failures are genuine wrong\-tool selections rather than recoverable formatting; Base improves only where the safe\-default booleans dominate \(phone\_call→64\.30\.0\\\!\\rightarrow\\\!64\.3,send\_email→34\.50\.0\\\!\\rightarrow\\\!34\.5,open\_application→24\.44\.3\\\!\\rightarrow\\\!24\.4\)\.

OnMobileActionsGoogle, the uplifts are small for all models: the largest iscreate\_contact\(e\.g\., Base→67\.636\.8\\\!\\rightarrow\\\!67\.6, Ours: MA\-Extended→71\.441\.8\\\!\\rightarrow\\\!71\.4\), driven by dropped*optional*contact fields, while free\-text categories such asshow\_mapare unchanged because their errors are value mismatches on*required*arguments, which the execution\-aware criterion deliberately does not forgive\.

Table 7:Execution\-aware end\-to\-end accuracy \(%\) per category on the held\-outMobileActionsExtendedeval split, grouped by the first call in each example\. Column abbreviations as in Table[2](https://arxiv.org/html/2609.25373#S5.T2); strict exact\-match counterparts in Table[5](https://arxiv.org/html/2609.25373#A3.T5)\. Best per row in bold\.Table 8:Execution\-aware end\-to\-end accuracy \(%\) per category on the held\-outMobileActionsGoogleeval split\. Column abbreviations as in Table[2](https://arxiv.org/html/2609.25373#S5.T2); strict exact\-match counterparts in Table[6](https://arxiv.org/html/2609.25373#A3.T6)\. Best per row in bold\.

## Appendix DDataset

### D\.1Tool Catalog: Full JSON Schema

The fifteen extended\-mobile\-action tools are declared with the following JSON schema, which is identical to the catalog used to generateMobileActionsExtendedand at fine\-tuning time\. The schema mirrors Plyer\([Kivy Team, 2013](https://arxiv.org/html/2609.25373#bib.bib16)\)’s Android facade so each call has a real handler\. Appendix[D\.2](https://arxiv.org/html/2609.25373#A4.SS2)summarizes argument keys*per dataset*:MobileActionsExtended\(below\) versus Google’sMobileActionsGoogle\(seven tools\); the mergedMobileActionsCombinedcorpus uses the union of both catalogs and is not listed separately here\.

\[

\{"function":\{"name":"list\_application",

"description":"ListtheapplicationsinstalledonthisAndroidplatform\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"open\_application",

"description":"OpenanapplicationinstalledonthisAndroidplatform\.",

"parameters":\{"type":"OBJECT",

"properties":\{"application\_name":\{"type":"STRING",

"description":"Nameoftheapplicationtobeopened\."\}\},

"required":\["application\_name"\]\}\}\},

\{"function":\{"name":"set\_brightness",

"description":"Setaspecificlevelofthecurrentscreenbrightness\.",

"parameters":\{"type":"OBJECT",

"properties":\{"level":\{"type":"STRING",

"description":"Brightnesslevelin\[0,100\]\."\}\},

"required":\["level"\]\}\}\},

\{"function":\{"name":"decrease\_brightness",

"description":"Stepthecurrentbrightnessdown\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"increase\_brightness",

"description":"Stepthecurrentbrightnessup\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"get\_current\_brightness",

"description":"Readthecurrentscreenbrightness\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"send\_email",

"description":"Sendanemail\.",

"parameters":\{"type":"OBJECT",

"properties":\{"to":\{"type":"STRING",

"description":"Therecipientemailaddress\."\},

"subject":\{"type":"STRING",

"description":"Theemailsubject\."\},

"body":\{"type":"STRING",

"description":"Theemailbody\."\},

"create\_chooser":\{"type":"BOOLEAN",

"description":"Whethertodisplayaprogramchooser\."\}\},

"required":\["to","subject"\]\}\}\},

\{"function":\{"name":"battery\_status",

"description":"Provideinformationaboutthebatteryofthedevice\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"bluetooth\_status",

"description":"GettheBluetoothstatusinfo\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"phone\_call",

"description":"Makeacallwithanumberoropenthephonedialpad\.",

"parameters":\{"type":"OBJECT",

"properties":\{"number":\{"type":"STRING",

"description":"Thenumbertocall\."\},

"dial\_call":\{"type":"BOOLEAN",

"description":"Truetoopenthedialer;Falsetocalldirectly\."\}\},

"required":\["number","dial\_call"\]\}\}\},

\{"function":\{"name":"phone\_sms",

"description":"SendanSMSmessage\.",

"parameters":\{"type":"OBJECT",

"properties":\{"sms\_recipient":\{"type":"STRING",

"description":"Therecipientphonenumber\."\},

"sms\_message":\{"type":"STRING",

"description":"Themessagebody\."\}\},

"required":\["sms\_recipient"\]\}\}\},

\{"function":\{"name":"take\_picture",

"description":"Takeapictureusingthedevicecamera\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"take\_screenshot",

"description":"Captureadigitalimageofwhatiscurrentlyvisibleonscreen\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"turnOff\_light",

"description":"Turnofftheflashlight\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\},

\{"function":\{"name":"turnOn\_light",

"description":"Turnontheflashlight\.",

"parameters":\{"type":"OBJECT","properties":\{\},"required":\[\]\}\}\}

\]

### D\.2Tool arguments by dataset \(MobileActionsExtended,MobileActionsGoogle\)

Following the same conventions as Hugging Face / FunctionGemma tool schemas, tables list each assistantargumentsdictionary: types are STRING, BOOLEAN, or none \(parameter\-free tool\)\. Keys marked “req\.” appear in each record’s schemarequiredarray; other keys may appear in gold tool calls depending on context\. Naming differs between datasets for flashlight tools \(turnOn\_light/turnOff\_lightvs\.turn\_on\_flashlight/turn\_off\_flashlight\)\. The combined training/eval corpusMobileActionsCombinedis omitted: its declarations are exactly the disjoint union of the two catalogs below\.

#### MobileActionsExtended\(UGrowAI/Mobile\-Actions\-Extended\)

#### MobileActionsGoogle\(google/mobile\-actions\)

### D\.3Synthetic Data Generation Prompt

The teacher prompt below was used to generate the rawMobileActionsExtendedconversations\. It \(i\) supplies a worked input/output example, \(ii\) injects the full tool catalog of Appendix[D\.1](https://arxiv.org/html/2609.25373#A4.SS1), and \(iii\) requests a target distribution over single\-tool and multi\-tool prompts\.

Givenatoollist,generateuserpromptsampleswiththeright

answer\(assistantrole\)\.Therightanswershouldprovidethe

rightfunctioncallsintherightorderalongwiththeir

requiredparameters\.

Forproducingeachexample,followtheconventionsbelow:

\-About300userpromptspersingletool\.

\-About5,000userpromptsthatcombinetwoormoretools\.

\-OutputasaJSONlist:

Messages=\[Message\_1,Message\_2,\.\.\.\]

Message=\[\{"role":"user","content":USER\_QUERY\},

\{"role":"assistant","tool\_calls":\[Functions\]\}\]

Function=\{"function":\{"name":FUNCTION\_NAME,

"arguments":\{KWARGS\}\}\}

Toollist:

\[\.\.\.AppendixA\.1catalog\.\.\.\]

Workedexample\(input\-\>expectedassistantoutput\):

\-user:"Sendanemailtojessica\.moraes@examplecorp\.com

withthesubject’Lunchtomorrow?’andbody

’Areyoufreetogrababiteatthecafeat1PM?’\."

\-assistant:tool\_calls=\[\{"function":\{"name":"send\_email",

"arguments":\{"to":"jessica\.moraes@examplecorp\.com",

"subject":"Lunchtomorrow?",

"body":"Areyoufreetogrababite

atthecafeat1PM?"\}\}\}\]

### D\.4End\-to\-End Pipeline \(Reproducibility\)

The full reproduction pipeline is split into three independent packages so that each step can be re\-run in isolation\. We list the salient entry points; full code is at the artifact location accompanying this paper\.

##### Step 1: dataset generation \(GenerateDataset\)\.

1. 1\.Generate synthetic data by giving the prompt of Appendix[D\.3](https://arxiv.org/html/2609.25373#A4.SS3)\. Then runmain\_mobile\_actions\.pyor follow the steps below\.
2. 2\.Validate withMobileActions/New\_Generated/validate\_generated\_dataset\.py\(drops illegal tool names and missing required arguments\)\.
3. 3\.Complete records withMobileActions/New\_Generated/complete\_dataset\.py\(addsmetadata,tools, and thedevelopermessage; sets the train/eval flag\)\.
4. 4\.\(Optional\) Merge withMobileActionsGoogleviaMobileActions/Merge/merge\_dataset\.py\.
5. 5\.Publish withpublish\.pyto a Hugging Face dataset repository\.

The source code is available[here](https://github.com/UgrowAI/Research_FuncGemma_GenerateDataset)\.

##### Step 2: fine\-tuning \(FineTuning\)\.

Editrun\_config\.yamlto point at the desired Hugging Face base model and dataset \(UGrowAI/Mobile\-Actions\-Extended

orUGrowAI/Mobile\-Actions\-Combined– the merged dataset\)\. The TRL hyper\-parameters live insrc/FineTuning/FunctionGemma/finetune\_config\.yaml\(full SFT, 2 epochs,lr=10−5\\text\{lr\}=10^\{\-5\}, cosine, bf16, completion\-only loss\)\. The trainer is invoked throughmain\.py; the resulting checkpoint is pushed back to Hugging Face viato\_cloud\.py\. The source code is available[here](https://github.com/UgrowAI/Research_FuncGemma_FineTuning)\.

##### Step 2b: device export \(To\_Device\.py\)\.

Convert a fine\-tuned checkpoint to a\.litertlmbundle for Handy Chat usinglitert\_torch\.generative\.export\_hf\.exportwithdynamic\_wi8\_afp32quantization andbundle\_litert\_lm=True\(Appendix[E\.2](https://arxiv.org/html/2609.25373#A5.SS2)\)\.

##### Step 3: evaluation \(FGemma\_Evaluation\)\.

main\.pyloads any number of model IDs \(we used the four of Section[6](https://arxiv.org/html/2609.25373#S6)\) and any number of dataset IDs, runs greedy generation, parses outputs with the regex decoder of Appendix[D\.5](https://arxiv.org/html/2609.25373#A4.SS5), computes the three metrics of Section[3](https://arxiv.org/html/2609.25373#S3), and writes per\-row CSV/JSON, an aggregate pickle, and a free\-textreview\_result\_\*\.txtfor failure inspection\. The same script produces all numbers in Tables[2](https://arxiv.org/html/2609.25373#S5.T2),[5](https://arxiv.org/html/2609.25373#A3.T5), and[6](https://arxiv.org/html/2609.25373#A3.T6)\. The source code is accessible[here](https://github.com/UgrowAI/Research_FuncGemma_Evaluation)\.

##### Hugging Face artifact IDs\.

- •Datasets:google/mobile\-actions\([Google, 2025](https://arxiv.org/html/2609.25373#bib.bib9)\),UGrowAI/Mobile\-Actions\-Extended,UGrowAI/Mobile\-Actions\-Combined\(merged corpus\)\.
- •Models:google/functiongemma\-270m\-it\([DeepMind, 2025a](https://arxiv.org/html/2609.25373#bib.bib6)\),litert\-community/FunctionGemma\_270M\_Mobile\_Actions\([LiteRT Community and DeepMind, 2025](https://arxiv.org/html/2609.25373#bib.bib19)\),UGrowAI/FunctionGemma\-270M\-it\-Mobile \-Actions\-Extended,UGrowAI/FunctionGemma\-270M\-it\-Mobile \-Actions\-Combined,UGrowAI/FunctionGemma\-270M\-it\-Mobile \-Actions\-Extended\-litert\-lm,UGrowAI/FunctionGemma\-270M\-it\-Mobile \-Actions\-Combined\-litert\-lm\.

### D\.5FunctionGemma Output Parser

FunctionGemma encodes calls with sentinel tokens\. The minimal parser used in our evaluation pipeline is reproduced below \(Python\)\.

importre

defextract\_function\_call\(model\_output\):

"""Parse<start\_function\_call\>\.\.\.<end\_function\_call\>blocks\.

Eachblockhastheform:

call:func\_name\{key:<escape\>value<escape\>,key:<escape\>value<escape\>\}

Returnsalistof\{"function":\{"name":\.\.\.,"arguments":\.\.\.\}\}\.

"""

results=\[\]

raw\_calls=re\.findall\(

r"<start\_function\_call\>\(\.\*?\)"

r"<end\_function\_call\>",

model\_output,

re\.DOTALL,

\)

forraw\_callinraw\_calls:

ifnotraw\_call\.strip\(\)\.startswith\("call:"\):

continue

try:

pre\_brace,args\_segment=raw\_call\.split\("\{",1\)

function\_name=pre\_brace\.replace\("call:",""\)\.strip\(\)

args\_content=args\_segment\.strip\(\)

ifargs\_content\.endswith\("\}"\):

args\_content=args\_content\[:\-1\]

arguments=\{\}

forminre\.finditer\(

r"\(?P<key\>\[^:,\]\*?\):<escape\>\(?P<value\>\.\*?\)<escape\>",

args\_content,re\.DOTALL,

\):

arguments\[m\.group\("key"\)\.strip\(\)\]=m\.group\("value"\)

results\.append\(\{"function":\{

"name":function\_name,"arguments":arguments\}\}\)

exceptValueError:

continue

returnresults

### D\.6Per\-Category Counts ofMobileActionsExtended

Eval\-split sample counts per first\-call category \(multi\-call examples are listed under their first call\):

The 90/10 train/eval split was applied at the record level via the dataset’smetadataflag, giving a training set of∼\\sim8,500 examples\.

### D\.7Demo Traces

We list two representative end\-to\-end traces from Handy Chat \(FunctionGemma\-270M\-it\-Mobile\-Actions\-Extendedserved via LiteRT\-LM\([Google AI Edge, 2025](https://arxiv.org/html/2609.25373#bib.bib10)\)\); theuserfield is the typed prompt, thepredictedfield is the parsed tool call, and theoutcomefield is the Plyer\([Kivy Team, 2013](https://arxiv.org/html/2609.25373#bib.bib16)\)dispatch result\.

##### Single call\.

user : "Open Spotify and set the brightness to 80%\."predicted : \[open\_application\(application\_name="Spotify"\),set\_brightness\(level="80"\)\]outcome : OK \-\- Spotify launched, brightness set to 80

##### Multi\-call SMS \+ call\.

user : "Text \+14165550101 saying ’I am on my way\.’ and thencall the same number directly\."predicted : \[phone\_sms\(sms\_recipient="\+14165550101",sms\_message="I am on my way\."\),phone\_call\(number="\+14165550101"\)\]outcome : OK \(SMS dispatched\), then phone call placed\.note : argument metric flags this as IMPERFECT because the goldlabel includes "dial\_call: false"; the user\-visibleoutcome is correct\.

### D\.8Dataset Format Reference

Each record inMobileActionsExtended\(andMobileActionsGoogle\) is a JSON object with three top\-level fields:metadata,tools, andmessages\.metadatais the literal stringtrainoreval\.toolsis the catalog of Appendix[D\.1](https://arxiv.org/html/2609.25373#A4.SS1)\.messagesis an ordered list of role\-tagged turns:

- •developer: “You are a model that can do function calling with the following functions …”, followed by the current date/time/weekday and the function declarations rendered with the FunctionGemma sentinel tokens\.
- •user: the natural\-language utterance\.
- •assistant: the goldtool\_callslist of\{"function": \{"name": …, "arguments": \{…\}\}\}objects\.

At training time, the chat template renders this list into a single string; at evaluation time, our parser of Appendix[D\.5](https://arxiv.org/html/2609.25373#A4.SS5)converts the model’s continuation back into*\(name, args\)*tuples\.

## Appendix EHandy Chat: On\-Device Demo Application

We deploy \.litertlm version ofFunctionGemma\-270M\-it\-Mobile\-Actions\-Extendedin*[Handy Chat](https://github.com/UgrowAI/HandyChat-apk/releases/latest/download/HandyChat.apk)*, a standalone Android APK built with Buildozer\([Kivy Team, 2024](https://arxiv.org/html/2609.25373#bib.bib17)\)\(org\.earthisgreen\.funcgemmachat\)\. The Google AI Edge Gallery\([Google AI Edge Team, 2026](https://arxiv.org/html/2609.25373#bib.bib11)\)does not currently allow loading custom checkpoints into its pre\-configured Mobile Actions workflow; we therefore ship our own runtime\.

### E\.1Architecture

The app combines four layers:

1. 1\.Kivy UI \(typed input only\)\.A Kivy/KivyMD chat tab displays conversation history and a text field with a Send button\.*Speech input is not enabled*in the current release \(the microphone control is unused\)\.
2. 2\.LiteRT\-LM via Java bridge \(CPU\)\.On\-device inference uses thelitertlm\-androidlibrary with theCPUbackend \(Backend\.CPU\)\. A thin Java class \(litertlm\_kotlin\) wrapsEngine\.initialize\(\),createConversation\(\), andsendMessage\(\); Python invokes it through PyJNIus on the Android UI thread\.
3. 3\.Conditional two\-pass loop\.The Python layer builds FunctionGemma chat\-template prompts and sends the user turn to LiteRT\-LM \(pass 1\)\. If the regex parser \(Appendix[D\.5](https://arxiv.org/html/2609.25373#A4.SS5)\) detects a function call, each call is executed throughFunctionExecutor/Plyer and serialized tool responses are sent back forpass 2; if no function call is found, the app returns the pass 1 text directly without a second decode\.
4. 4\.Plyer dispatch\.Registered tool handlers mirror the fifteen extended categories and invoke Android intents \(turnOn\_light,phone\_sms,open\_application, etc\.\) via Plyer\([Kivy Team, 2013](https://arxiv.org/html/2609.25373#bib.bib16)\)\.

### E\.2Checkpoint Export to\.litertlm

Handy Chat consumes a LiteRT\-LM bundle rather than the raw Hugging Face weights\. We export offline withTo\_Device\.pyin our fine\-tuning repository\. The script loads the fine\-tuned checkpoint directory and calls

> litert\_torch\.generative\.export\_hf\.export\( model=checkpoint\_dir, quantization\_recipe="dynamic\_wi8\_afp32", output\_dir=\.\.\., bundle\_litert\_lm=True\)

which produces a[\.litertlmfile](https://huggingface.co/UGrowAI/FunctionGemma-270M-it-Mobile-Actions-Extended-litert-lm/tree/main)111https://huggingface\.co/UGrowAI/FunctionGemma\-270M\-it\-Mobile\-Actions\-Extended\-litert\-lm\(285\.6 MB for our extended checkpoint\) bundled with the tokenizer artifacts needed by the on\-device runtime\. Export runs on a development machine; the APK ships the bundle under application assets\.

The on\-device loop is: typed message→\\topass 1 decode→\\toparse\. When a function call is present, Plyer dispatches it and pass 2 ingests the tool response; otherwise pass 1 output is shown to the user\. We verified all fifteen extended categories on a developer device\. Representative traces are in Appendix[D\.7](https://arxiv.org/html/2609.25373#A4.SS7)\. The demo APK and source are released alongside the Hugging Face artifacts\.

### E\.3Hardware, Device, and Latency Details

All demo measurements were taken on aGoogle Pixel 8 Pro\(“husky”\): Tensor G3 SoC, 12 GB RAM, Android 16\. The Mali\-G715 GPU is present but*not*used for inference; Handy Chat runs entirely on theLiteRT\-LM CPU backend\(Backend\.CPU\)\. The deployed model is the 285\.6 MB\.litertlmbundle exported with thedynamic\_wi8\_afp32recipe \(Appendix[E\.2](https://arxiv.org/html/2609.25373#A5.SS2)\); note that this dynamic INT8 quantization affects only the demo, and all accuracy numbers in the paper were measured on the unquantized base or fine\-tuned models\.

Across a handful of prompt trials, a function\-call turn takes roughly13 seconds average end\-to\-end latency, broken down by stage as follows: pass 1 \(prompt prefill and tool\-call decode\)∼\\sim9 s; tool execution through Plyer∼\\sim2 s; pass 2 \(ingesting the serialized tool response and producing the user\-facing reply\)∼\\sim2 s\. Turns without a function call skip stages two and three and return the pass 1 output directly\.