These two parameters are system-internal and should not be part of
the function calling contract. Remove them from the registered
options schema so LLM agents don't see them. Parser no longer reads
them from options: userId defaults to INVALID_USER_ID (-1) filled
by CheckAndUpdateParam, displayId defaults to INVALID_DISPLAY_ID
filled by SCB. ResolveUserId/ResolveDisplayId methods and their
constants are deleted.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Unify on Generic (ExtractInsightIntentInfo) as the sole data format
for registration. Drop ConvertFromExtractProfile, FilterProfile, the
PrepareForRegister template, and the three ExtractFrom* helpers. Each
remaining Filter (Config/Generic) now inlines rule-1 filtering and
(moduleName, abilityName) sort directly.
event_mgr now converts Profile→Generic via ProfileInfoFormat before
filtering and registering, matching the sys_event_receiver path.
ConvertFromExtractIntentInfo is completed to emit the same full
FunctionInfo (options schema, inputSchema, outputSchema) that the old
Profile path produced, so both registration paths yield identical
KVStore entries.
Net effect: ~50 lines removed, one conversion path, two self-contained
filters, and consistent FunctionInfo output across all callers.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Remove deviceId from the registered options schema, drop the
ResolveDeviceId parser step (deviceId stays at its default empty
string), and delete the DispatchDistributedIntent helper plus the
distributed branch in ExecuteIntentByFunctionCall. ignoreAbilityName
no longer considers deviceId. The intent now always dispatches
locally via ExecuteIntentCommon.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
ExecuteIntentByFunctionCall grew past 50 lines after adding the want
param cleanup. Pull wantParam cleanup + multi-candidate match +
paramParser.Build into PrepareFunctionCallParam so the entry function
stays focused on permission checks, dispatch routing, and common
handoff. Both functions are now under the 50-line cap.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
ResolveUserId now defaults to -1 (INVALID_USER_ID) instead of
callerUserId, so InsightIntentExecuteManager::CheckAndUpdateParam can
fall back to calling-UID-derived userId exactly like the ExecuteIntent
path. options.userId still overrides.
ExecuteIntentByFunctionCall now honors param->deviceId_: when non-empty
the function dispatches via DispatchDistributedIntent (flood attack
check, PERMISSION_EXECUTE_DISTRIBUTED_INTENT, GenerateWant,
dmsClient.StartRemoteIntent, SetRemoteIntentTimeout) instead of falling
through to ExecuteIntentCommon. ignoreAbilityName also becomes true when
deviceId is set, matching ExecuteIntent's existing behavior.
DispatchDistributedIntent is a new private helper so the distributed
dispatch body stays under the 50-line function cap.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[0%] 👌 AI Adopted[0%] 🧑 Human[100%]
sys_event_receiver's RegisterAllFunctions now collects every bundle's
FunctionInfo into one vector and calls CliToolMGRClient::BatchRegisterFunctions
in a single IPC instead of looping RegisterInsightIntentFunctions per
bundle. Cuts N bundle IPCs down to 1 on the boot/shutdown registration
path. New helper BatchRegisterInsightIntentFunctions in function_call_convert
covers convert + version stamping + batch call.
event_mgr path (per-module install) is untouched and still uses
RegisterInsightIntentFunctions. This commit depends on the pending
BatchRegisterFunctions API in cli_tool_framework.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
The field holds the candidate picked by the executor after rule-1
filtering and sort. 'matchedInfo' describes that purpose more directly
than 'representative' (which read as if the candidate were a spokesperson
for some group). Caller in ExecuteIntentByFunctionCall updated.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
IntentParamParser::Build now applies the same rule-1 filter and
(moduleName, abilityName) sort as IntentFilterUtil::FilterGeneric, then
picks the sorted vector's last element as the single representative.
All param fields come from that one representative (moduleName,
abilityName, executeMode, decoratorType), so registration and execution
end up choosing the same candidate for a given (bundleName, intentName).
wantParam.options overridess still apply on top of representative
fields. PickActiveCandidates and per-field Resolve* helpers are removed
since representative selection replaces them. FilterGeneric is reused
rather than duplicating rule-1 logic in the executor.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Re-introduce GetAllInsightIntentInfoForRegister on DbCache that returns
rule-1 filtered and (moduleName, abilityName) sorted data. sys_event_receiver
now calls this ForRegister variant and gets ready-to-register data.
RegisterInsightIntentFunctions drops its inline IntentFilterUtil call
back to pure convert+register semantics.
event_mgr (whose data comes from profile file parsing, not DbCache)
does explicit IntentFilterUtil.FilterProfile/FilterConfig before
Register, since it cannot use the ForRegister shortcut. Net effect:
each caller filters at its own data source instead of Register doing
all work, and the original GetAllInsightIntentInfo stays untouched.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Drop GetAllInsightIntentInfoForRegister and ApplyFilterPerBundle from
DbCache; rule 1 filter and (moduleName, abilityName) sort now live
inside RegisterInsightIntentFunctions where they belong as registration
business logic. DbCache reverts to pure CRUD.
Callers simplified: BackupAndScheduleRegister uses raw
GetAllInsightIntentInfo; event_mgr no longer constructs IntentFilterUtil
explicitly. Both paths converge on a single filter point inside
RegisterInsightIntentFunctions, ensuring consistent rule application.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Simplify rule 2 to "moduleName alphabetical first" without entry
preference. Removes entryModuleNames parameter from IntentFilterUtil
ctor, FilterCandidate.isEntryModule field, CandidateOrdering entry
dimension, DbCache GetAllInsightIntentInfoForRegister signature, and
bundleToEntryModules plumbing in sys_event_receiver/event_mgr. Callers
no longer need to extract entry modules from BundleInfo.
Also rename FilterAndDedup overloads to FilterProfile/FilterConfig/
FilterGeneric for explicit data-source semantics.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Wrap GetAllInsightIntentInfo + per-bundle IntentFilterUtil into a single
DbCache entry. sys_event_receiver's BackupAndScheduleRegister now reads
already-filtered data, removing the FilterAndDedup call from
RegisterAllFunctions. event_mgr still uses IntentFilterUtil directly
(its data comes from profile files, not DbCache).
Co-Authored-By: Agent
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
Move parameter parsing/assembly for ExecuteIntentByFunctionCall out of
AbilityManagerService anonymous helpers into a dedicated
InsightIntentParamParser class with explicit, unit-testable rules.
Expose multi-candidate matcher API (GetMatchedIntentInfos).
Drop SA-only check on ExecuteIntentByFunctionCall entry so function
calling agents can invoke intents directly.
Add IntentFilterUtil for CliTool registration path: callers preprocess
intent lists before RegisterInsightIntentFunctions to (1) drop intents
not bound to background UIAbility or ServiceExtension, (2) pick entry
module first when same intentName spans modules, (3) prefer UIAbility
over ServiceExtension when same module has multiple abilities.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
- Add uint32_t versionCode field to CliTool::FunctionInfo with full
Parcel/JSON serialization
- Pass versionCode through RegisterInsightIntentFunctions and assign
to each FunctionInfo before IPC registration
- Remove redundant bundle-level versionCode cache in InsightIntentDbCache
(HasFunctionByName/SaveFunctionVersion/DeleteFunctionVersion/
LoadFunctionVersionMap, functionVersionMap_, functionVersionMutex_,
and related RDB helpers)
- Simplify LoadInsightIntentInfos dedup to single rdbHas check
- Update function_info_test and thirteenth_test mock accordingly
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
- Add ExecuteIntentByFunctionCall with lightweight intent_client SO
- Pass caller bundleName as fallback when profile bundleName is empty
- Sort GetInsightIntentGenericInfoByName by moduleName then intentName
- Add UnregisterInsightIntentFunctions using UnregisterFunctionsByNamespace
- Add verify query after RegisterFunction with logging
- Wire FunctionCall cleanup into all three intent deletion paths
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[68%] 👌 AI Adopted[68%] 🧑 Human[32%]
Permission checks (CheckStaticCfgPermission,
CheckCallServiceExtensionPermission, CheckStartByCallPermission) used to
read SKILL_EXECUTE_PARAM_CALLER_TOKEN_ID straight out of the Want that
flows through GenerateAbilityRequest. Because Want is attacker
controlled on the public StartAbility paths, a forged callerTokenId
could route the skill-specific permission branches in
PermissionVerification (CheckSkillStartByCallPermission,
JudgeInvisibleAndBackground) and borrow another app's identity.
Add a dedicated AbilityRequest::skillCallerTokenId field populated
solely by the trusted skill entrypoints:
- ExecuteInAppSkill / ExecuteInAppSkillWithTokenId drop the
want.SetParam calls and pass callerTokenId through to
StartAbilityByCallWithSkill / StartExtensionAbilityWithSkill.
- Those two helpers (and StartExtensionAbilityInner via a new optional
parameter) set the AbilityRequest field after the request is
generated.
- The three permission checks now read abilityRequest.skillCallerTokenId
instead of the Want.
Forged Want params no longer influence permission decisions. Existing
callers of StartExtensionAbilityInner are unaffected via the default
parameter value.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
CheckSkillPermission previously only verified system-app status when
callerTokenId was 0, leaving the CliToolMgr-proxied path (non-zero
callerTokenId) without any verification. Add two layers of checks:
- Direct IPC caller must be a system ability (IsSACall)
- Indirect caller must hold every permission declared by the skill
(AccessTokenKit::VerifyAccessToken)
Also drop the callerTokenId=0 default and thread callerTokenId through
the ExecuteInAppSkill path so the direct-call variant is also covered.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.2) <ai@local>
Add a boolean isRestored_ flag to PendingWantRecord to indicate
recovery scenarios from WantAgent FromString. Only SEND_COMMON_EVENT
uses uid_ as publisherUid when isRestored_ is true, other operations
keep using callerUid_ unchanged. Extract ResolveWantSenderUid helper
to keep GetWantSenderByUserId under 50 lines.
Co-Authored-By: Agent
Signed-off-by: RuiChen_01 <chenrui193@huawei.com>
🤖 AI[100%] 👌 AI Adopted[100%] 🧑 Human[0%]
Co-authored-by: claude (glm-5.1) <ai@local>
Change-Id: I8f313b5fde2b870e28c19127432c5ebb49de7d68
openharmony_ci
