DroidCall: A Dataset for LLM-powered Android Intent Invocation

Li Zhang; Mengwei Xu; Rongjie Yi; Shihe Wang; Weikai Xie

REVIEW 4 major objections 5 minor 1 cited by

DroidCall: A Dataset for LLM-powered Android Intent Invocation

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A 10,000-sample synthetic dataset derived from Android's implicit intents lets small on-device language models match or exceed a large cloud model at translating natural-language requests into function calls.

desk verdict Useful new dataset for Android intent invocation, but the claimed edge over GPT-4o rests on a 200-sample synthetic test set labeled by the same generator as the training data. read the letter →

arxiv 2412.00402 v1 pith:WA2XPTWQ submitted 2024-11-30 cs.AI

Weikai Xie , Li Zhang , Shihe Wang , Rongjie Yi , Mengwei Xu This is my paper · ORCID

classification cs.AI

keywords Androidintentinvocationfunctioncallingsmalllanguagemodelssyntheticdataseton-deviceagentLoRAfine-tuningGPT-4obaselinemobilecomputing

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that a 10,000-sample synthetic dataset, DroidCall, can teach small on-device language models to translate natural-language instructions into Android intent invocations (the mechanism that triggers app actions) more accurately than a large cloud model. The authors fine-tune models such as Qwen2.5-3B and Gemma2-2B with the dataset and report that they reach or surpass GPT-4o's accuracy on a 200-sample test set, while using much shorter prompts and running locally. The claim matters because on-device assistance avoids sending user data to the cloud and removes network latency, and because the dataset pipeline requires no hand-written seed data. If correct, this makes private, responsive mobile agents practical with models small enough to fit on a phone.

What carries the argument

The load-bearing mechanism is the pairing of a function-call representation with an automated synthetic-data generation loop. The authors predefine 24 functions with typed arguments and docstrings, sample examples from a general function-calling dataset to seed the generator, then repeatedly prompt a strong LLM to produce new query–call pairs with varied wording, filtering outputs by JSON validity and ROUGE similarity. Fine-tuning uses the model's own chat template with the function descriptions in the system prompt and the call in the assistant turn, which avoids format gaps; a 'code_short' prompt with 645 average tokens is chosen for efficiency. Evaluation uses exact-match accuracy and a soft accuracy that applies semantic similarity for free-text parameters, with a fake retriever that always returns the ground-truth functions to isolate intent-call accuracy from retrieval.

What would settle it

Collect a set of real user instructions for the same 24 functions from a live user study, label them by hand, and run the DroidCall-fine-tuned models and GPT-4o on that set under the same fake-retriever condition; if the small models no longer match or beat GPT-4o, or if a noticeable fraction of the synthetic test labels are shown to be wrong, the claimed superiority does not transfer.

Watch

Extended reading notes

Core claim

The central discovery is that Android intent invocation can be reformulated as function calling, and that a compact domain-specific dataset built by an automated pipeline is enough to unlock this capability in small models. The authors define 24 functions wrapping common Android implicit intents (alarms, timers, contacts, messages, maps, camera, settings), generate user queries and matching function-call annotations with the help of a larger language model, filter and deduplicate them, and fine-tune small models with low-rank adaptation. On their 200-example test set, Gemma2-2B fine-tuned on DroidCall reaches 85% exact-match accuracy versus 77% for GPT-4o, and several other sub-4B models land in the low-to-mid 80s, compared to 17.5–67% for the same models zero-shot. The authors also provide an end-to-end Android app where the fine-tuned model runs on-device, demonstrating tasks like adding a calendar event.

Load-bearing premise

The reported accuracies assume that the GPT-4-turbo-generated labels in the test set are correct ground truth and that those synthetic queries resemble what real users will actually say; if either assumption fails, the gap over GPT-4o may shrink or disappear.

Editorial extensions

If this is right

A general-purpose phone assistant could perform common tasks (set alarm, send message, open camera, search maps) with a sub-2B model running entirely on the device.
Developers could regenerate the dataset for their own predefined function sets without writing seed examples, since the pipeline only requires function signatures and docstrings.
Intent invocation would become faster and cheaper than UI-gesture automation, since the model directly calls the function rather than simulating taps and swipes.
Prompt length for intent calling drops from roughly 1,367 tokens for GPT-4o to about 645 tokens for fine-tuned small models, reducing latency and memory.
Because functions shield the model from version-specific intent details, the same trained model could work across Android versions by reimplementing the function bodies.
If the approach transfers, other structured mobile APIs beyond Android intents could be controlled with the same small-model recipe.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A natural next test is to swap the fake retriever for the embedding-based retriever used in the demo and measure end-to-end accuracy; the paper's headline numbers would likely drop because retrieval errors add to call errors.
The same pipeline could be pointed at other on-device APIs, such as iOS shortcuts, automotive infotainment, or smart-home actions, by changing only the function definitions.
Because the test set is synthetic and drawn from the same generator as the training set, the reported accuracy probably overestimates performance on out-of-distribution user phrasing; a human-authored test set would give a fairer comparison.
The dataset construction itself is a small-scale instance of a broader pattern: using a large model to generate training data for a narrow, well-specified task, then distilling that skill into a small model.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: DroidCall is a genuinely useful new dataset and the core engineering story holds up, but the "surpasses GPT-4o" headline is not yet supported. The 85 vs 77 gap is 16 samples out of 200, with test labels from the same GPT-4-turbo pipeline that made the training data.

What is new and good: this is the first dataset specifically for Android intent invocation, 10k training samples over 24 common functions, built with a self-instruct pipeline seeded from xlam-function-calling-60k. The pipeline is reusable and they open-source it. They fine-tune a wide spread of SLMs, show clear gains over zero- and few-shot baselines, and demonstrate that domain-specific data beats a generic function-calling dataset for this task. That is a concrete, citable contribution for the mobile-agent community.

Where it is soft: the test set is synthetic, generated by GPT-4-turbo under the same prompts as training, filtered only for JSON format and ROUGE redundancy. No human check verifies that the labels are correct or that arguments are actually inferable from the query. The appendix prompt says "do not fabricate" but nothing enforces it. Checkpoint selection uses the test set (train 24 epochs, pick the best checkpoint), and no error bars or variance are reported. The fake retriever is honestly disclosed, but it means the metric measures function completion, not end-to-end intent invocation. The soft-accuracy semantic threshold of 0.75 is a free parameter.

None of this kills the dataset's value. The training data is useful precisely because a strong model generated it, and the fine-tuning improvements are large and consistent. But the abstract's "approach or even surpass GPT-4o" should be softened or re-evaluated on a human-labeled benchmark before it is taken at face value.

Who this is for: people building on-device mobile agents or studying synthetic data for function calling. It deserves a serious referee, but the review should ask for external validation of the test set, error bars, and a more cautious headline. I would cite the dataset, not the claim.

Referee Report

4 major / 5 minor

Summary. The paper introduces DroidCall, a 10k-example synthetic dataset for fine-tuning small language models to invoke Android intents via predefined functions. The generation pipeline follows the self-instruct paradigm with GPT-4-turbo, starting from seed examples sampled from an existing function-calling dataset, and applies JSON format and ROUGE-based deduplication filters. The authors fine-tune several on-device SLMs with LoRA and compare their accuracy and soft accuracy against GPT-4o and GPT-4o-mini on a 200-sample test split, reporting that Gemma2-2B-it reaches 85% accuracy versus GPT-4o's 77%. They also present an end-to-end Android demo with a GTE-based retriever and the mllm inference engine.

Significance. If the reported results hold, DroidCall would be a useful first open dataset for Android intent invocation, with a reusable and customizable data generation pipeline and a practical on-device deployment demonstration. The paper's strengths include open-sourcing the data generation, fine-tuning, and evaluation code, and making the dataset and demo publicly available. The main contribution is the dataset itself rather than any new learning method. However, the central comparative claim that fine-tuned SLMs approach or surpass GPT-4o is currently not established: the evaluation is partly circular, the test-set size is small, checkpoint selection uses the test split, and the evaluation uses an oracle retriever. The dataset may still be valuable for future work, but the headline claim requires additional validation.

major comments (4)

[Section 3.2.3 and Section 4 (Metrics)] The test split of DroidCall is generated by GPT-4-turbo under the same self-instruct pipeline as the training split, and Section 3.2.3 describes only JsonExtractor, FormatFilter, and SimilarityFilter—there is no human or independent programmatic verification that the generated function call and argument values are correct or inferable from the query. Because fine-tuned SLMs are trained to mimic the generator's query-to-label conventions, the 85% accuracy reported in Table 2 is partly circular: the models are scored on the same distribution they were trained to reproduce, while GPT-4o is not fine-tuned on DroidCall. This does not by itself invalidate the dataset, but it does mean the abstract's claim that SLMs 'approach or even surpass' GPT-4o is not yet supported. A human-verified subset or an independent benchmark of real user intents is needed.
[Section 3.3 and Section 4.1] The paper states in Section 3.3 that the authors 'pick the best checkpoint' after training for 24 epochs, and Section 4.1 describes selecting checkpoints by testing accuracy on the DroidCall test set. This means the reported test accuracies in Table 2 are optimistic, since the test set is used for model selection rather than being reserved for a single final evaluation. The choice of prompt format in Section 4.1 is also made on the same test split. The authors should report validation-set-based selection, or clearly state and justify the use of the test set for checkpoint selection, and ideally re-evaluate the final selected models on a held-out portion.
[Table 2 and Section 4 (Metrics)] The headline difference between Gemma2-2B-it (85%) and GPT-4o (77%) corresponds to 16 samples out of 200, and no confidence intervals, standard errors, or significance tests are reported. Given that Acc requires exact match to the GPT-4-turbo-generated labels, a small number of incorrect or ambiguous test labels could reverse the reported ranking. The authors should provide bootstrap or repeated-evaluation intervals and, if possible, human adjudication of the test labels to establish that the 8-point gap is statistically meaningful.
[Section 4 (Evaluation setup) and Abstract] The evaluation uses a 'fake retriever that always retrieves the ground-truth functions,' so Acc and Soft Acc measure function-call generation under oracle retrieval, not the full Android intent invocation pipeline. The abstract's phrase 'accurate Android intent invocation' is therefore stronger than what Table 2 demonstrates. The authors should either integrate the GTE-based retriever from Section 3.4 into the reported evaluation, or explicitly qualify the conclusions as applying to the function-calling component only.

minor comments (5)

[Section 3.4] There is a typo in the last sentence: 'on Andrid devices' should be 'on Android devices'.
[Appendix A] Several typos appear in the prompt templates: 'respone' should be 'response', 'infomation' should be 'information', and 'provider' should be 'provide'.
[Figure 6 and Table 2] Zero-shot results in Figure 6(b) use the code prompt format, while Table 2 reports zero-shot and few-shot results using the json prompt format; this inconsistency in evaluation conditions should be stated clearly in the captions or the text so readers can compare the two sets of numbers correctly.
[Section 4 (Metrics)] The semantic-similarity threshold for non-exact parameters is set to 0.75, and the choice of threshold is not further justified or ablated; a brief justification or sensitivity analysis would strengthen the metric definition.
[Section 4.1] The text says 'the final outcome indicates that the json format performed slightly better' but then chooses code_short for subsequent experiments based mainly on token count; the sentence should more clearly separate accuracy considerations from efficiency considerations.

Circularity Check

2 steps flagged · score 6.0 of 10

Headline superiority over GPT-4o rests on a test set generated by the same GPT-4-turbo pipeline as the training data, so fine-tuned SLMs are scored on how well they mimic the generator.

fitted input called prediction [Section 3.2, Section 3.2.3, Section 4]
"The entire dataset generation process leverages GPT-4-turbo as the underlying language model. ... Using the method described above, we generated the DroidCall dataset, which is made up of two parts: train and test. The train split contains 10,000 data entries, while the test split contains 200 data entries. ... We use the 200 data entries from the test split of DroidCall to evaluate SLMs."

By the paper's own description, both train and test splits are outputs of the same GPT-4-turbo self-instruct pipeline, with only a JSON-format filter and a ROUGE-based deduplication filter applied; nothing verifies that the generated 'answers' are the correct Android intents or that arguments are actually inferable from the query. Fine-tuning on the train split therefore teaches SLMs to reproduce GPT-4-turbo's query-to-call mapping, and the 200-sample test split scores them on that same mapping. GPT-4o is evaluated zero-shot on this self-generated distribution without such fine-tuning, so its lower 77% vs 85% reflects format/distribution mismatch rather than a validated capability gap.
fitted input called prediction [Section 3.3, Section 4.1]
"We train for 24 epoch and pick the best checkpoint. ... We selected nine checkpoints throughout the entire fine-tuning process to test for accuracy, with the results shown in Figure 6(a)."

The only evaluation set described is the 200-sample DroidCall test split, and checkpoint selection is performed by accuracy on that same set (Figure 6). The final fine-tuning accuracies in Table 2 are therefore the maximum over checkpoints evaluated on the test set that was used for selection, not a held-out estimate. This makes the reported superiority over GPT-4o statistically forced in the optimistic direction: the test set is used both to choose the model and to claim the result.

full rationale

The dataset generation pipeline itself is not circular: it is a self-instruct-style synthesis process that could in principle be checked against real Android invocations, and the code and dataset are released. The circularity is confined to the evaluation used to support the headline claim. Both the 10k training samples and the 200 test samples are produced by the same GPT-4-turbo pipeline, with only format and ROUGE-dedup filters applied; no independent check verifies that a generated 'answer' is the correct intent call. Thus the fine-tuned SLMs are scored on how well they reproduce GPT-4-turbo's query-to-call conventions, while GPT-4o is tested zero-shot on those same self-generated labels without fine-tuning. The 85% vs 77% gap is only 16 samples, so small label noise or prompt-format differences can reverse the ranking. Additionally, the best checkpoint is selected using the same 200-sample test set that later appears in Table 2, and the evaluation uses a fake retriever that always returns the ground-truth functions, so the reported numbers are optimistic upper bounds. There is no load-bearing self-citation: the PhoneLM and mllm citations are to released artifacts used in the demo, not to justify the central accuracy claim. None of this invalidates the dataset's usefulness, but the claim that small models 'approach or even surpass GPT-4o for accurate Android intent invocation' is not yet independently established.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central claim depends on the validity of synthetic labels and the representativeness of the generated distribution; no external benchmark is used.

free parameters (1)

Semantic similarity threshold for correctness = 0.75
Used in both Accuracy and Soft Accuracy to judge whether free-text parameters like title or subject match ground truth. The threshold directly changes reported scores and is chosen without sensitivity analysis.

assumptions (4)

domain assumption GPT-4-turbo-generated function calls are correct ground truth for Android intent invocation
The paper validates format and deduplicates but does not semantically verify the generated labels in either train or test split. All accuracy numbers rely on this assumption.
domain assumption Synthetic self-instruct data distribution approximates real user intents
The dataset is generated by an LLM rather than collected from users; the paper provides no evidence that the distribution matches real requests.
domain assumption Fake retriever that always returns ground-truth functions is a fair evaluation setup
Stated in Section 4, the evaluation bypasses a real retriever, so end-to-end performance in a deployed app is not measured.
domain assumption The 24 hand-picked functions adequately cover common Android operations
The paper manually selects intents from Android documentation; the coverage is not empirically justified.

how reviews work

0 comments

Cite this review

Pith. "Pith review of DroidCall: A Dataset for LLM-powered Android Intent Invocation." pith.science (2026). https://pith.science/paper/WA2XPTWQ

@misc{pith2026241200402,
  author       = {Pith},
  title        = {Pith review of: DroidCall: A Dataset for LLM-powered Android Intent Invocation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WA2XPTWQ}},
  note         = {Machine review of arXiv:2412.00402}
}

read the original abstract

The growing capabilities of large language models in natural language understanding significantly strengthen existing agentic systems. To power performant on-device mobile agents for better data privacy, we introduce DroidCall, the first training and testing dataset for accurate Android intent invocation. With a highly flexible and reusable data generation pipeline, we constructed 10k samples in DroidCall. Given a task instruction in natural language, small language models such as Qwen2.5-3B and Gemma2-2B fine-tuned with DroidCall can approach or even surpass the capabilities of GPT-4o for accurate Android intent invocation. We also provide an end-to-end Android app equipped with these fine-tuned models to demonstrate the Android intent invocation process. The code and dataset are available at https://github.com/UbiquitousLearning/DroidCall.

Figures

Figures reproduced from arXiv: 2412.00402 by the authors.

**Figure 1.** Small language models fine-tuned with DroidCall have the capability to assist users in completing common tasks such as adding events to the calendar. due to privacy and latency constraints (goo, 2024; Lu et al., 2024b; Yin et al., 2024; Xu et al., 2023b; Yuan et al., 2024). Since user data are processed locally, sensitive information remains on devices, thereby mitigating risks associated with data transmission ove… view at source ↗

**Figure 2.** Workflow of DroidCall, which consist of three key phases:(1) Functions Predefinition; (2) Data Generation; (3) Finetuning and Evaluation. prone UI actions. Taking the task “setting of an alarm” as an example, an agent could directly tell the app the user’s intent to set an alarm, rather than acting on behalf of the user to locate and enter the alarm app, tap to set the alarm, adjust the time, and then confirm. The l… view at source ↗

**Figure 3.** (a) shows how implicit intent works in Android; (b) shows an example to help user set an alarm with implicit intent. ponents in an Android application. It acts as a glue that connects individual components such as activities, services, broadcast receivers, and content providers. Android intent can be divided into two categories: • Explicit Intents specify the exact component to start by providing the fully qualified… view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: Details of data generation in DroidCall. To avoid manually creating seed data, DroidCall initially samples examples from an external dataset to generate its first set of data. Subsequently, the data is used as seed data to continuously generate new data, thereby elim…

**Figure 5.** Figure 5: Design of our demo [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]

**Figure 6.** Figure 6 [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Every Software as an Agent: Blueprint and Case Study
cs.SE 2025-02 conditional novelty 6.0 of 10

An LLM agent that writes code and executes it inside the app's runtime can complete tasks that GUI-clicking agents struggle with, with a small case study reporting up to 80% task completion.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages · cited by 1 Pith paper

[8]

The parameter values generated with function call generated must be values that can be inferred from the user’s query; YOU CANNOT FABRICATE PARAMETERS THAT CANNOT BE OBTAINED FROM THE USER’S REQUEST

work page
[9]

name: "

Attach each answer with an id starting from 0. And if a tool should use the respone from another tool, you can reference it using #id, where id is the id of the tool. following are some examples: $examples Now I will give you a tool, and you help me generate 15 query-answer pairs. REMEMBER TO GENERATE THE RESULT IN JSON FORMAT LIKE THE EXAMPLE ABOVE REMEM...

work page
[15]

When providing parameters, if a parameter has required=False, it is not necessary to provide its value

work page
[16]

The query-answer pairs should cover as many possible uses of the tool as possible

work page
[18]

following are tool I provided and some examples of query-answer pairs: tool: $tool examples: $examples Now please help me generate 40 query-answer pairs

The parameter values generated with function call generated must be values that can be inferred from the user’s query; YOU CANNOT FABRICATE PARAMETERS THAT CANNOT BE OBTAINED FROM THE USER’S REQUEST. following are tool I provided and some examples of query-answer pairs: tool: $tool examples: $examples Now please help me generate 40 query-answer pairs. REM...

work page
[23]

DroidCall: A Dataset for LLM-powered Android Intent Invocation

For the queries you generate, you should provide answers using the tool, i.e., give the tool used and the values for each parameter. DroidCall: A Dataset for LLM-powered Android Intent Invocation

work page
[28]

It means that you should generate a query that needs to use all the tools I provided to solve, and remember to provider an answer that uses all the tools to solve the query

You should use all the tools I provided to generate the query and answer. It means that you should generate a query that needs to use all the tools I provided to solve, and remember to provider an answer that uses all the tools to solve the query

work page
[31]

i.e., the argument of a function call is the response of another function call

Generate data of nested function calls if possible. i.e., the argument of a function call is the response of another function call. following are some examples: $examples Now I will give you a tool, and you help me generate 15 query-answer pairs. REMEMBER TO GENERATE THE RESULT IN JSON FORMAT LIKE THE EXAMPLE ABOVE AND PUT IT IN A JSON LIST. REMEMBER YOU ...

work page

Show all 21 references

[32]

Queries can be long or short, complex or concise

For queries, try to use different vocabulary and syntax to ensure query diversity. Queries can be long or short, complex or concise. In short, try not to generate similar queries; I want to ensure query diversity
[33]

This means a query can be a command, a question, or a request with detailed descriptions, etc

The language of the queries should be as diverse as possible. This means a query can be a command, a question, or a request with detailed descriptions, etc
[34]

The generated queries should cover all possible uses of the tool as much as possible, meaning the coverage of various parameters should be comprehensive, ensuring the tool can be used to complete various forms of work
[35]

The generated queries should be solvable using the given tools
[36]

For the queries you generate, you should provide answers using the tool, i.e., give the tool used and the values for each parameter
[37]

When providing parameters, if a parameter has required=False, you may omit its value
[38]

The generated data must be presented in the format given in my example
[39]

THE PARAMETER V ALUES GENERATED WITH FUNCTION CALL GENERATED MUST BE V ALUES THAT CAN BE INFERRED FROM THE USER’S QUERY; YOU CANNOT FABRICATE PARAMETERS THAT CANNOT BE OBTAINED FROM THE USER’S REQUEST
[40]

THIS IS ALSO TO GUARANTEE THAT YOU DON’T FABRICATE PARAMETERS

THE GENERATED QUERY SHOULD CONTAIN ENOUGH INFOMATION SO THAT YOU COULD CORRECTLY GENERATE PARAMETER USED BY THE TOOLS. THIS IS ALSO TO GUARANTEE THAT YOU DON’T FABRICATE PARAMETERS
[41]

You should use all the tools I provided to generate the query and answer. It means that you should generate a query that needs to use all the tools I provided to solve, and remember to provider an answer that uses all the tools to solve DroidCall: A Dataset for LLM-powered And...
[42]

You can use the same tool multiple times in a single query to ensure the query diversity
[43]

And if a tool should use the respone from another tool, you can reference it using #id, where id is the id of the tool

Attach each answer with an id starting from 0. And if a tool should use the respone from another tool, you can reference it using #id, where id is the id of the tool
[44]

recipient@example.com

Generate data of nested function calls if possible. i.e., the argument of a function call is the response of another function call. Now I will give you some tools and some example data of query-answer pairs using these tools. Please help me generate 40 query-answer pairs. tool...

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [8]

The parameter values generated with function call generated must be values that can be inferred from the user’s query; YOU CANNOT FABRICATE PARAMETERS THAT CANNOT BE OBTAINED FROM THE USER’S REQUEST

work page

[2] [9]

name: "

Attach each answer with an id starting from 0. And if a tool should use the respone from another tool, you can reference it using #id, where id is the id of the tool. following are some examples: $examples Now I will give you a tool, and you help me generate 15 query-answer pairs. REMEMBER TO GENERATE THE RESULT IN JSON FORMAT LIKE THE EXAMPLE ABOVE REMEM...

work page

[3] [15]

When providing parameters, if a parameter has required=False, it is not necessary to provide its value

work page

[4] [16]

The query-answer pairs should cover as many possible uses of the tool as possible

work page

[5] [18]

following are tool I provided and some examples of query-answer pairs: tool: $tool examples: $examples Now please help me generate 40 query-answer pairs

The parameter values generated with function call generated must be values that can be inferred from the user’s query; YOU CANNOT FABRICATE PARAMETERS THAT CANNOT BE OBTAINED FROM THE USER’S REQUEST. following are tool I provided and some examples of query-answer pairs: tool: $tool examples: $examples Now please help me generate 40 query-answer pairs. REM...

work page

[6] [23]

DroidCall: A Dataset for LLM-powered Android Intent Invocation

For the queries you generate, you should provide answers using the tool, i.e., give the tool used and the values for each parameter. DroidCall: A Dataset for LLM-powered Android Intent Invocation

work page

[7] [28]

It means that you should generate a query that needs to use all the tools I provided to solve, and remember to provider an answer that uses all the tools to solve the query

You should use all the tools I provided to generate the query and answer. It means that you should generate a query that needs to use all the tools I provided to solve, and remember to provider an answer that uses all the tools to solve the query

work page

[8] [31]

i.e., the argument of a function call is the response of another function call

Generate data of nested function calls if possible. i.e., the argument of a function call is the response of another function call. following are some examples: $examples Now I will give you a tool, and you help me generate 15 query-answer pairs. REMEMBER TO GENERATE THE RESULT IN JSON FORMAT LIKE THE EXAMPLE ABOVE AND PUT IT IN A JSON LIST. REMEMBER YOU ...

work page