Repository navigation
fix: report real app name and focused activity for android foreground app - #403
Conversation
… app GetForegroundApp assigned the package name to AppName, so every Android response echoed the package twice while iOS returned a real label. The label is already resolved by PackageLister.displayName on the agent side, so look the package up in that listing instead. When the agent is unavailable the lookup fails and callers still get the package name back rather than an error, matching the previous behaviour. Also parse the activity out of the mCurrentFocus component and expose it as an optional field, since dumpsys already reports it alongside the package.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (3)
Included review availability: 2 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 3 reviews per hour. 📝 WalkthroughWalkthroughAndroid foreground app detection now returns the focused package and activity. It resolves the application label through installed package data and falls back to the package name when lookup fails or the label is empty. ChangesAndroid foreground app detection
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to Android foreground reporting now returns resolved app labels with package-name fallbacks and optionally includes the focused activity. The updated behavior and fallback cases are covered, with no current merge-readiness risk identified. Sequence Diagram(s)sequenceDiagram
participant GetForegroundApp
participant getForegroundComponent
participant listAllPackages
GetForegroundApp->>getForegroundComponent: read focused window component
getForegroundComponent-->>GetForegroundApp: return package and activity
GetForegroundApp->>listAllPackages: resolve package label
listAllPackages-->>GetForegroundApp: return label or package fallback
GetForegroundApp-->>GetForegroundApp: populate ForegroundAppInfo
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
Problem
mobilecli apps foregroundon Android echoed the package name twice:{ "packageName": "com.mobilenext.playground", "appName": "com.mobilenext.playground", "version": "1.0" }GetForegroundAppassignedAppName: packageNamedirectly. iOS resolves a real label, so the two platforms disagreed.Fix
The label was already available.
PackageLister.displayNameon the agent side resolves it throughnonLocalizedLabeland then the package's own resources, andListAppsalready returns it. The foreground path just never asked, so it now looks the package up in that listing.No change was needed in
agents/android.When the on-device agent is unavailable the listing call fails and callers get the package name back rather than an error, so setups without the agent behave as before.
Also included: the activity is parsed out of the
mCurrentFocuscomponent and exposed as an optionalactivityfield, since dumpsys already reports it next to the package.Result
{ "packageName": "com.mobilenext.playground", "appName": "Playground", "version": "1.0", "activity": "com.mobilenext.playground.BasicUIActivity" }Test plan
go build ./...go vet ./devices/go test ./devices/passesappNameFor: label found, package absent from the listing, package present with an empty labelSummary by CodeRabbit