fix(activity): detect Android device at runtime for view selection#903
Conversation
VUE_APP_ON_ANDROID is set at build time and only covers the embedded
Android webui. When a desktop browser views an Android device's data,
the default views always show desktop views (Top Window Titles etc.)
instead of the Android summary view.
Fix by replacing the mapState('views') with an explicit computed that
checks bucketsStore.available(host).android at runtime. If the host has
Android buckets but no window buckets, return androidViews regardless
of build env.
Greptile SummaryThis PR switches activity views to choose Android layouts from runtime bucket data.
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (2): Last reviewed commit: "fix(activity): apply Android view detect..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| // VUE_APP_ON_ANDROID is a build-time flag that only applies when the webui | ||
| // is embedded in the Android app itself. When browsing Android device data | ||
| // from a desktop browser we need a runtime check instead. |
There was a problem hiding this comment.
When a desktop build views an Android-only host, this branch returns androidViews for the parent tabs and route fallback, but the routed ActivityView component still resolves the selected view from viewsStore.views. The user can see the Android-only Summary tab while the child renders the stored desktop summary definition, so desktop-only elements such as top window titles can still appear on the Android page.
There was a problem hiding this comment.
Good catch — this was a real gap. ActivityView.vue was mapped directly to viewsStore.views (the desktop views), so even when Activity.vue correctly showed the Android tabs the child was still resolving its elements from the stored desktop view definition.
Fixed in the latest commit (317a7f5): ActivityView.vue now runs the same runtime bucket check (available.android && !available.window) using $route.params.host, and returns androidViews when the host is an Android device. The stored views (and all edit/save operations) remain unaffected for desktop hosts.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #903 +/- ##
==========================================
- Coverage 38.63% 38.55% -0.08%
==========================================
Files 42 42
Lines 2226 2233 +7
Branches 443 420 -23
==========================================
+ Hits 860 861 +1
- Misses 1288 1351 +63
+ Partials 78 21 -57 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…ponent The parent Activity.vue now returns androidViews for the tab list when the host is an Android device, but ActivityView.vue was still resolving the current view from viewsStore.views (desktop views). This caused the child to render desktop-view elements (e.g. Top Window Titles) even when the Android Summary tab was selected. Fix: replicate the same runtime bucket check (available.android && !available.window) in ActivityView.vue, reading the host from $route.params.host. Android hosts now get androidViews elements; desktop hosts and the build-time VUE_APP_ON_ANDROID path are unchanged.
|
@greptileai review |
| // Use Android views when the current host is an Android device. | ||
| // Mirrors the same runtime check in Activity.vue so the child view | ||
| // resolves its elements from the correct view list instead of always | ||
| // falling back to the stored desktop views. |
There was a problem hiding this comment.
What? So now users cant edit/persist the views? "stored desktop views" shouldn't exist in a clean install, the android views should be persisted as the defaults for that device or however it works (I guess views aren't per-device? thus not a separate "android" view being persisted?).
Related to https://github.com/ActivityWatch/aw-webui/pull/903/changes#r3566418786
useViewsStore() should handle it, not complicate views computed's
There was a problem hiding this comment.
Good call. Pushed a refactor in 48f1fed that moves the detection into the store:
- Added
viewsForHost(host: string): View[]action onuseViewsStorethat does theavailable.android && !available.windowcheck internally. - Both
Activity.vueandActivityView.vuenow just callviewsStore.viewsForHost(this.host)— no directandroidViewsimport, no duplicated bucket logic, nobucketsStorein component data.
On persistence: you're right that views are not per-device today, so for an Android host viewsForHost returns the hardcoded androidViews (not stored/customizable). The "Restore defaults" button remains wired to the store's defaultViews for the stored (desktop) views. Making views per-device so Android defaults persist separately would be a follow-up — that seems out of scope here, and the store is now the right place to put that logic when it happens.
|
CI-green and mergeable (Greptile 5/5) — waiting only on a maintainer click. This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted. |
|
@TimeToBuildBob No it isn't, see #903 (comment) and #903 (comment) |
…re action Remove duplicated bucket-check computed properties from Activity.vue and ActivityView.vue. Instead add a viewsForHost(host) action on useViewsStore that centralises the runtime android-vs-desktop detection. Components now call viewsStore.viewsForHost(host) — a single call into the store — rather than importing androidViews and useBucketsStore directly.
… table The Hostname is already displayed prominently in each device card's header. Showing it again as a column inside the per-device table is redundant and squeezes the table on phone screens. Remove it and redistribute the column widths (id: 45%→65%, last_updated: 15%→20%, actions: 15% unchanged).
|
Fair point — I shouldn't have posted "CI-green and mergeable" while your To be clear about what What Two options I see:
I won't push more changes without your direction here. Which scope do you want? |
|
@TimeToBuildBob |
|
"Per-devicetype views" is the better framing — updated the tracking issue title accordingly. Opened #904 to track the follow-up: per-devicetype views set, analogous to category sets, with |
) The mobile icon was imported but never used — all devices showed the desktop icon regardless of type. Use bucketsStore.available().android (same detection as Activity.vue after #903) to select mobile vs desktop.
2 participants
Problem
VUE_APP_ON_ANDROIDis set at build time and only covers the case where aw-webui is embedded inside the Android app itself. When a desktop browser views data from an Android device, the flag is alwaysfalse, so the default views (desktopViews) are used — showing "Top Window Titles" and other desktop-only elements instead of the Android summary view.This was noted in a
FIXMEcomment inviews.ts:The symptom: browsing to an Android device in aw-webui from a desktop shows "Top Window Titles" and a desktop device icon instead of the Android summary.
Fix
Replace
...mapState(useViewsStore, ['views'])inActivity.vuewith an explicit computed property that checksbucketsStore.available(host).androidat runtime. If the host has Android buckets but no window buckets (i.e. it is an Android-only device), returnandroidViewsrather than the stored default.This also exports
androidViewsfromviews.tsso it can be imported inActivity.vue.Behaviour
Note on hostname spaces
This also indirectly helps with OEM hostnames that contain spaces (e.g.
"Poco F8 Ultra"fromBuild.MODEL). ThebucketsAndroiddetection inbuckets.tsalready handles the hostname comparison correctly — the primary issue was the view selection using build-time env rather than runtime bucket detection.