Frameo as HASS Wall Mounted Dashboard

Share your Projects!
1

Repurposing a Pastigio / Frameo M15R4 as a Home Assistant Wall Panel (I heavily relied on AI to get here, and had the AI generate the instructions)

I recently converted a Pastigio/Frameo digital picture frame into a reasonably responsive Home Assistant wall display. These devices are going for about $40 on Amazon.

The device is a Pastigio M15R4, based on a Rockchip RK3326, running Android 8.1 with roughly 1 GB RAM.

The biggest discovery was that the old Android version itself was not really the main problem. The stock Android System WebView was version 61, which is far too old for a modern Home Assistant frontend. Once WebView was upgraded, the frame became surprisingly usable.

The final setup is:

  • Android 8.1
  • WebView 106.0.5249.126
  • kiFOSSk as the Android Home launcher
  • Home Assistant dashboard
  • VirtualSoftKeys for Back/Home
  • Text Launcher as a maintenance launcher
  • Via as an optional lightweight general browser

Quick Version

If you have a similar rooted Frameo device:

  1. Enable ADB and verify root with su -c.
  2. Check the installed Android System WebView.
  3. If it is an old version such as v61, replace it with LineageOS Android System WebView 106.0.5249.126, Android 6.0+ compatible, with armeabi-v7a support.
  4. Install kiFOSSk and make it the default Android Home launcher.
  5. Point kiFOSSk at your Home Assistant dashboard.
  6. Disable the original Frameo app.
  7. Install VirtualSoftKeys so Back/Home remain accessible without ADB.
  8. Install Text Launcher as a lightweight maintenance/recovery launcher.
  9. Optionally install Via as a lightweight general-purpose browser.
  10. Optionally disable vendor OTA services if you do not want the customized /system changed later.
  11. Test a full cold boot and maintenance functions with ADB disconnected before wall mounting.

The critical step is the WebView upgrade.

Immich Kiosk documents WebView 106 as the upgrade path for older Frameo devices:

The WebView build I used was:

Hardware and Software

My frame reports:

Model: Pastigio M15R4
SoC: Rockchip RK3326
Android: 8.1.0
API level: 27
RAM: ~1 GB
Userspace ABI: armeabi-v7a / armeabi
Treble: enabled
Partition layout: A-only / legacy

The RK3326 CPU is 64-bit capable, but this particular Android installation is using 32-bit ARM userspace.

ADB was available through the Frameo developer/beta settings.

A useful first check was:

adb shell su -c id

On this frame it returned root:

uid=0(root)

That made replacing the system WebView possible.

1. Check the Existing WebView

Run:

adb shell dumpsys webviewupdate

My frame was running:

com.android.webview
61.0.3163.98

Immich Kiosk recommends checking WebView first and says that if the device is already on WebView 101 or newer, replacement may not be necessary.

You can also find the installed APK path with:

adb shell pm path com.android.webview

On mine it was:

/system/app/webview/webview.apk

2. Download a Compatible WebView

The exact build I used was:

Android System WebView 106.0.5249.126
Version code: 524912603
Package: com.android.webview
Architecture: arm64-v8a + armeabi-v7a
Minimum Android: Android 6.0 / API 23

This was important because the frame is running Android 8.1 with 32-bit ARM userspace.

Sources:

Immich Kiosk Frameo guide:

LineageOS WebView 106.0.5249.126:

I deliberately did not choose the newest WebView available. Version 106 was the known-compatible Frameo path and was modern enough for Home Assistant.

3. Replace the Stock WebView

Push the replacement APK:

adb push webview.apk /sdcard/webview.apk

Remount /system read/write:

adb shell su -c "mount -o remount,rw /system"

Back up the original WebView:

adb shell su -c "cp /system/app/webview/webview.apk /system/app/webview/webview.apk.bak"

Remove the old compiled WebView files:

adb shell su -c "rm -rf /system/app/webview/oat"

Copy the new APK into place:

adb shell su -c "cp /sdcard/webview.apk /system/app/webview/webview.apk"

Fix ownership and permissions:

adb shell su -c "chown root:root /system/app/webview/webview.apk"
adb shell su -c "chmod 644 /system/app/webview/webview.apk"

Remount /system read-only:

adb shell su -c "mount -o remount,ro /system"

Reboot:

adb reboot

After reboot, verify:

adb shell dumpsys webviewupdate

Mine reported:

Current WebView package:
com.android.webview, 106.0.5249.126

This was the single biggest improvement in the entire project.

4. Install kiFOSSk

For the final kiosk frontend, I used kiFOSSk.

Project:

Package:

com.shinydiscoballsdev.kifossk

After installing it, configure the Home Assistant URL and select Set as Home Launcher.

Verify the default Home activity:

adb shell cmd package resolve-activity --brief -a android.intent.action.MAIN -c android.intent.category.HOME

Mine returned:

com.shinydiscoballsdev.kifossk/.MainActivity

The normal boot path is then:

Android
  ↓
kiFOSSk
  ↓
Home Assistant

No separate autostart utility is required.

5. Optional: Via as a Lightweight General Browser

I also kept Via Browser installed.

Via is not required for the Home Assistant kiosk. I use it as a general-purpose fallback browser because it is much lighter than Firefox on this hardware and uses the Android system WebView.

Package:

mark.via.gp

It can be launched with:

adb shell monkey -p mark.via.gp -c android.intent.category.LAUNCHER 1

With WebView 106 installed, Via performed surprisingly well. Even embedded video was usable.

To stop it without uninstalling it:

adb shell am force-stop mark.via.gp

That frees its RAM while leaving it available.

6. Disable the Original Frameo App

Once kiFOSSk was working as the Home launcher, I disabled Frameo rather than deleting it.

adb shell pm disable-user --user 0 net.frameo.frame

To restore it:

adb shell pm enable net.frameo.frame

I prefer disabling over deleting because it leaves an easy recovery path.

7. Install a Maintenance Launcher

Because the tablet will eventually be mounted on a wall without ADB attached, I wanted a minimal alternate launcher that could expose Android Settings, Via, and other utilities.

I first tried KISS Launcher, but it failed on this particular ROM.

I then installed Text Launcher from F-Droid:

It is extremely simple and just shows installed application names in a list.

On this frame it displays things such as:

kiFOSSk
Settings
Sound Recorder
Via

kiFOSSk remains the normal Home launcher. Text Launcher is only there for maintenance/recovery.

8. Add Back/Home Navigation

This frame does not have physical Android navigation buttons, and kiFOSSk intentionally runs in immersive fullscreen mode.

ADB confirmed that Android navigation itself works:

Back:

adb shell input keyevent 4

Home:

adb shell input keyevent 3

I checked Android’s global immersive/navigation settings:

adb shell settings get global policy_control
adb shell settings get secure navigation_mode
adb shell settings get system navigationbar_hide_bar_enabled
adb shell settings get global navigationbar_hide_bar_enabled

Those were all unset or null.

dumpsys window showed that kiFOSSk itself was requesting immersive UI flags.

Rather than modifying SystemUI, I installed VirtualSoftKeys from F-Droid:

After enabling its Accessibility Service and configuring the gesture region, Back/Home worked correctly.

This means the tablet can now be maintained entirely from the touchscreen after ADB is disconnected.

9. Optional: Disable Vendor OTA Services

The running process list showed these vendor update services:

android.rockchip.update.service
com.muxintu.app.mxota

These appear to be device/firmware OTA infrastructure rather than only Frameo app updating.

Because I deliberately modified /system, I did not want an unexpected OEM firmware update undoing those changes.

Disable the Rockchip update service:

adb shell pm disable-user --user 0 android.rockchip.update.service

The other vendor OTA client can also be disabled:

adb shell pm disable-user --user 0 com.muxintu.app.mxota

To restore them:

adb shell pm enable android.rockchip.update.service
adb shell pm enable com.muxintu.app.mxota

This step is optional.

Final Software Layout

Pastigio / Frameo M15R4
Android 8.1
RK3326
~1 GB RAM
        |
        +-- Android System WebView 106.0.5249.126
        |
        +-- kiFOSSk
        |     +-- default Android Home launcher
        |     +-- Home Assistant dashboard
        |
        +-- VirtualSoftKeys
        |     +-- Back / Home navigation
        |
        +-- Text Launcher
        |     +-- maintenance / recovery launcher
        |
        +-- Via
        |     +-- optional lightweight browser
        |
        +-- Android Settings

Disabled or removed:

Frameo: disabled
Rockchip OTA service: disabled
Fully Kiosk: removed
Firefox: removed
Home Assistant Companion: removed
KISS Launcher: removed

Things I Tried That Did Not Work

Replacing Android 8.1

My first thought was to replace the old OS with Android 9, LineageOS, or a Treble GSI.

The device looked promising on paper:

Treble enabled
A-only
ARMv8 CPU
separate /system and /vendor

The problem was getting a safe flashing path.

Fastboot

adb reboot bootloader

did not result in a usable Fastboot device.

fastboot devices

showed nothing.

Rockchip Loader Mode

I tried:

adb reboot loader

as well as various button/USB combinations.

RKDevTool never saw a usable Loader-mode device.

Recovery

The stock recovery displayed the dead Android / “No command” screen.

ADB in recovery was unauthorized, and I could not expose a useful recovery menu with the physical controls.

Without a reliable recovery or flashing method, replacing Android carried too much brick risk.

Once WebView 106 worked, replacing Android no longer seemed worthwhile anyway.

Attempting Raw Partition Backups

I explored dumping boot/system partitions with dd.

From a normal ADB shell, raw partition reads produced:

Permission denied

Later I discovered that normal Android had working root via:

adb shell su -c ...

but by then the inability to reliably enter Fastboot/Loader/recovery had already made OS replacement unattractive.

Home Assistant Companion App

I tried the Home Assistant Android Companion app.

It got through login, password, and MFA, and then crashed.

The logs showed that it was trying to initialize Bluetooth/Improv functionality.

On this hardware:

adb shell svc bluetooth enable

returned:

Got a null BluetoothAdapter, is the system running?

The app subsequently tried to use the Bluetooth LE scanner on a null adapter and crashed.

So the current Home Assistant Companion app was not a good fit for this particular frame/ROM.

The WebView approach was much more reliable.

Fully Kiosk Browser

Fully Kiosk was another obvious candidate.

On this frame it caused SystemUI instability and was not reliable enough to use.

I removed it.

Simpler WebView wrappers worked much better.

Firefox

Firefox technically ran, but on this roughly 1 GB device it was:

  • slow
  • memory-heavy
  • prone to crashing

Via was much more responsive.

Via as the Primary Kiosk

Via actually worked well and was the first successful Home Assistant frontend.

This was not really a failure.

The reasons it was not the final kiosk solution were architectural:

  • it is a general browser
  • it is not itself the Android Home launcher
  • it contains browser UI/features that are not needed for a wall panel

Once kiFOSSk worked, it made more sense to use kiFOSSk as the dedicated Home Assistant interface and retain Via only as an optional general browser.

Custom Init-Script Autostart

Before settling on a Home-launcher-based solution, I experimented with starting Via through Android init.

I created files along the lines of:

/system/etc/init/via-autostart.rc
/system/bin/start-via.sh

The first issue was Windows CRLF endings causing ^M problems.

After correcting that, the shell script itself could launch Via manually.

The harder problem was Android init. This vendor ROM did not dynamically register the new .rc service as expected.

I even experimented with adding the service stanza to the existing bootstat.rc, but the service still did not reliably register/start.

I restored the original init configuration and abandoned this approach.

Once kiFOSSk became the Android Home launcher, custom boot scripting was unnecessary anyway.

KISS Launcher

I wanted a very lightweight fallback launcher.

KISS installed, but failed when selected as Home on this particular ROM.

Rather than spend time debugging an optional component, I replaced it with Text Launcher, which worked immediately.

Trying to Restore Android’s Normal Navigation Bar

At first I thought the missing navigation controls were caused by a global Android immersive-mode setting.

They were not.

The relevant Android settings were unset, and dumpsys window showed that kiFOSSk itself was requesting immersive fullscreen.

Rather than modifying SystemUI or framework files, VirtualSoftKeys provided the missing Back/Home controls with much less risk.

Main Takeaway

The biggest lesson from this project was that Android 8.1 itself was not what made the frame unusable.

The real problem was:

Android System WebView 61

Once that became:

Android System WebView 106.0.5249.126

the original Android installation became capable of running a modern Home Assistant dashboard quite well.

So rather than:

replace Android
    ↓
fight Rockchip bootloader
    ↓
risk bricking the frame

the successful approach was:

keep Android 8.1
    ↓
upgrade WebView
    ↓
install a lightweight WebView kiosk
    ↓
make it the Home launcher
    ↓
add simple navigation/recovery utilities

For this particular device, upgrading WebView was by far the highest-value change.