|
4644
|
Zero-Assist by @Tan-May | Stardance
|
Tan-May
|
0
|
229.35
|
0
|
[]
|
[{"post_id": 40727, "ts": "202 [{"post_id": 40727, "ts": "2026-08-04T13:20:13Z", "hours": 13.7692, "text": "Check this out !! so yesterday i finished with the MCP implementation of the app , i implemented 4 transport method (STDIO,,HTTP,SSE and the LOCALHOST_STDIO) so when i was testing out i found out that only one of them is working properly , (the http one ) to which i connected multiple apps , mcp’s etc everything was working fine but when i tested the other transport method , not even a single one was working because it all needed the desktop to run with the specific packages so unfortunately i was not able to use it and i also find out about the nasa mcp where they daily upload the images mars rover images etc so i tried to test it but the problem was that the mcp was not http instead it was the STDIO so i was sad cause i had to fix first the mcp issue then test it but when i was in school in break i was getting board and opened the app and i had an idea like cant we just convert the normal stdio into the http mcp using the termux ? after asking to claude it said definitely we can do this so then i setuped the env(i will add a screenshot below ) and made a proxy server which converts the normal stdio mcp to the http steamtable and i was then able to access it locally using my app (i will add the image of it too) and i managed to connect to the mcp and fetch the images , now everything is working completely fine just the remaining part is the remaining transport which i will fix it some how !! also i will add some images i fetched below"}, {"post_id": 39007, "ts": "2026-08-01T17:30:37Z", "hours": 3.4689, "text": "Update !!! new devlog here … so now after doing some more research on the mcps and the implementation plans etc etc now im finally going all on it , ive added a ui component of the MCP in the Connection/Plugin/MCP , where i added few premade mcp options like (GitHub , brave search , external postgre sql etc ..) also there i added the option of the add custom server in which use can add custom server where currently the transport options are (STDIO,HTTP,SSE,LOCALHOST_STDIO (where you can add local mcp servers using the apps like termux etc ) so now that the ui is completed now i will move on to the connection part of the ui to the backend rust engine via uniffi )"}, {"post_id": 38224, "ts": "2026-07-31T14:56:23Z", "hours": 2.8122, "text": "Devlog time :> so now I’m continuing with the implementation of the MCP in the app like i previously talked now when i did some tinkering with the rust code using the ai , i managed to get all the connected MCP tools into the config file of the ai the config is getting updated now but the problem is that the config is constantly keeps changing don’t know what’s happening i guess the the problem is in the toml config generator which is glitching out , so now im trying fixing it from lots of time now , i guess i might have to use the antigravity to fix this but i exhausted my weekly limit cause I’m on a free tier 😭😭.. ill catch up with yall later till then bye bye 🙆.."}, {"post_id": 38050, "ts": "2026-07-31T07:21:16Z", "hours": 3.8936, "text": "Hello Hello Hello new devlog here , so now i started with the implementation of the MCP believe me guys once the app gets the MCP the app will go to another level , like it will then support literally any app (any app) it can perform actions like the mcp does but in simpler way also when i started with implementation i hit the problem again the code is there in the zeroclaw engine but again the problem is that its meant to run on the desktop so now we again have to do some changes in code and make the mcp run natively on the phone , i also found out some resources to do it like ( https://github.com/modelcontextprotocol/kotlin-sdk ) which is good so now the idea is something similar like shown in the screenshot below taken from the chat gpt …."}, {"post_id": 37593, "ts": "2026-07-30T13:01:48Z", "hours": 7.1106, "text": "Devlog here , so now i added the new cool animation (thinking orb ) this animation was totally inspired from the ( https://orbs.jakubantalik.com/ ) but the problem was that the orb was written in the typescript which wont work in our app cause our app is written in the kotlin so what i did was i downloaded the zip file from the repo pasted it to the claude and told him to convert it into kotlin for me and surprisingly the results was amazing , i will share the video recording too , and the other part i worked on was i added a few voices for my apps from the hugging face so now the user can use the custom voices too and also if he wants to use some of the default voices , the option is there do download in the app, some voices ( https://huggingface.co/rhasspy/piper-voices/resolve/main/en/en_US/lessac/medium/en_US-lessac-medium.onnx , https://huggingface.co/rhasspy/piper-voices/resolve/main/en/en_US/lessac/medium/en_US-lessac-medium.onnx , https://huggingface.co/rhasspy/piper-voices/resolve/main/en/en_GB/alan/medium/en_GB-alan-medium.onnx ) for someone whose interested …"}, {"post_id": 34542, "ts": "2026-07-25T10:46:59Z", "hours": 5.4758, "text": "Devlog: Google Workspace Integration This week I worked on integrating Google Workspace into Zero-Assist , allowing the AI to securely access services like Gmail, Google Drive, Google Docs, and Google Sheets after the user grants permission. The ZeroClaw engine already supports Google Workspace CLI (GWS) , but it was originally built for desktop Linux and expects a desktop environment with GWS already installed. Since Zero-Assist runs inside an Alpine Linux sandbox on Android using PRoot , that approach doesn’t work directly. Instead of rewriting the integration, I kept the existing architecture and adapted it for Android. What I Implemented I modified the sandbox installation process so that GWS is installed automatically whenever the user installs the standard sandbox packages. This means users don’t need to manually install or configure the CLI. Inside the app, I added a new Google Workspace plugin under: Connections → Plugins → Installed → Google Workspace When the user signs in, the Android app completes the OAuth flow and generates the required Google Workspace configuration files. To bridge Android and the Linux sandbox, I use the existing Android ↔ PRoot bridge . The plan is: User Login ↓ Android creates GWS credentials ↓ Credentials copied into PRoot sandbox ↓ Sandbox GWS CLI uses the same credentials ↓ AI can access approved Google services This keeps authentication native while allowing the Linux CLI to work without requiring the user to touch the terminal. Google Cloud Setup I also created a dedicated Google Cloud Console project for Zero-Assist. The project uses a Web Application OAuth client , which is required by the Google Workspace CLI authentication flow. I enabled the necessary APIs, including: Gmail API Google Drive API Google Docs API Google Sheets API More APIs can be enabled as additional integrations are added. Current Problem The authentication flow itself works correctly, and users can successfully sign in. The issue is that the generated credential/configuration files are not being copied correctly into the Linux sandbox . Because of this, the sandboxed GWS CLI cannot find the required authentication files, causing every Google Workspace command to fail. The current challenge isn’t OAuth—it’s reliably synchronizing credentials between Android and the PRoot environment. Once this bridge is working, users will simply sign in once, choose which Google services they want to grant access to, and Zero-Assist will be able to securely interact with those services without any manual setup. note:This devlog is written with hands and then passed to the chatgpt to format it with the .md because im very lazy to play with those colons and #’s"}, {"post_id": 33937, "ts": "2026-07-24T08:09:07Z", "hours": 6.6875, "text": "Device Control Development Update Yesterday I worked on expanding the Device Control system in my AI assistant. The idea behind this feature is to allow the AI to perform real actions on an Android device using the Accessibility Service . When the user gives a command such as “Subscribe to MrBeast on YouTube” , the main AI analyzes the request and delegates it to the Device Control tool. Current Workflow Launch the required application using: PackageManager.getLaunchIntentForPackage() startActivity() Capture a compressed screenshot of the current screen. Analyze the screenshot to identify UI elements and their screen coordinates. Navigate the interface and perform actions through the Android Accessibility APIs. Current Features Open applications Tap at (x, y) Swipe gestures Type text These core primitives allow the AI to interact with almost any Android application through UI automation. Future Improvements My main goals are to improve both speed and accuracy . Instead of navigating through multiple screens for simple system operations, I plan to add native high-level commands directly into the Device Control tool, such as: flashlight_toggle wifi_toggle bluetooth_toggle mobile_data_toggle volume_set brightness_set take_screenshot lock_screen open_notifications open_quick_settings go_home go_back open_recents These commands will allow the AI to execute common Android actions instantly without relying on visual navigation. For more complex tasks—such as interacting with third-party applications—the tool will continue using the screenshot + coordinate-based navigation pipeline. Long-Term Vision The goal is to build a hybrid Device Control system: Native commands for common Android operations (fast, reliable, and efficient). Vision-guided UI automation for complex interactions within any application. This architecture will significantly reduce execution time, improve reliability, and make the assistant capable of handling virtually any task on an Android device."}, {"post_id": 33134, "ts": "2026-07-22T19:18:54Z", "hours": 15.1933, "text": "So i basically went through the whole device control system and hardened it. the planner was splitting compound goals like “open instagram and message rohit” into separate calls which broke everything. also fixed it so the loop doesn’t just bail on the first response - it actually executes the action first. scroll was crashing if the planner didn’t send a direction so now it defaults down. and exceptions in the callback handler were just silently killing the process so now everything is caught and logged properly. added loop detection so it doesn’t get stuck repeating the same thing, post-action screen verification, and 44 tests to cover it all. very happy that it worked , it took lots of time but eventually i think the results are very very good though this thing not works great on the local ai’s but with the cheap api like openrouter/free , this thing can give pretty good results"}, {"post_id": 32219, "ts": "2026-07-21T07:52:35Z", "hours": 20.9892, "text": "okay so after spending lots of time on this issue , im finally able to make this work again , the problem was that (bin/sh, ust/bin/env) never extracted because of one code issue where i accidently mentioned them as the read only memory in the apps storage so the distro was installing also getting extracted but becacuse of the read only type of file , the app was not able to perform any actions on it , so now after taking the help from the open code now the sandbox is fully functional and working on every devices , also ive added some default packages which will get installed during the setup of the sandbox such as (wget, git , python3, jq, py3-pip, nodejs ,lftp and the openssh-client) just using the single command (apk add –no-cache bash curl wget git jq python3 py3-pip nodejs openssh-client lftp rsync)"}, {"post_id": 30521, "ts": "2026-07-18T05:11:12Z", "hours": 13.5486, "text": "Hello guys, devlog here!I finally got the Linux sandbox in Zero-Assist working end-to-end! The sandbox runs Alpine Linux through PRoot directly on Android without requiring root.Getting it working was harder than expected, though. I ran into several Android-specific issues.Fixing the SandboxThe first problem was Alpine’s heavy use of BusyBox hardlinks. My TAR extractor used File.copyTo(), which didn’t preserve executable permissions, causing errors like:proot error: execve(“/bin/sh”): Permission denied I fixed this by preserving executable bits:linkTarget.copyTo(outFile, overwrite = true) if (linkTarget.canExecute()) { outFile.setExecutable(true, false) } Some hardlinks were also extracted before BusyBox itself, so I added a second repair pass after extraction to restore critical commands like /bin/sh, /bin/ls, and /bin/cat.Symlinks were another problem because Android can block their creation. I added a fallback that copies the target when creating the actual symlink fails:try { Files.createSymbolicLink(outFile.toPath(), Paths.get(linkName)) } catch (e: Exception) { fallback.copyTo(outFile, overwrite = true) } I also had problems directly executing PRoot because some Android app directories can be noexec. The solution was to launch PRoot through Android’s system linker:val args = arrayOf( “/system/bin/linker64”, prootPath, “–rootfs=$rootfsPath”, “/bin/sh”, “-c”, command ) I also added corrupted download detection and automatic Alpine mirror fallback, making the rootfs installation much more reliable.Giving the AI Linux ToolsAfter getting the sandbox stable, I added two AI tools:sandbox_execute — Executes commands inside Alpine and supports persistent shell state, working directories, environment variables, timeouts, and background processes.sandbox_manage_process — Lets the AI list, monitor, read logs from, and kill background processes.For example, the AI can execute:{ “command”: “python3 –version && uname -a”, “working_dir”: “/root” } Or start a background server:{ “command”: “python3 -m http.server 8000”, “background”: true } The execution pipeline now looks like:AI Agent ↓ Rust Tool Layer ↓ Authenticated Local HTTP Bridge ↓ Kotlin Sandbox Manager ↓ PRoot ↓ Alpine Linux The Rust runtime communicates with the Kotlin sandbox through a localhost bridge on 127.0.0.1:49481, protected by a randomly generated per-process bearer token.And now the sandbox is fully functional end-to-end!The AI can execute real Linux commands, install packages, maintain persistent shell sessions, run scripts, start background processes, inspect their logs, and manage them — all inside Alpine Linux running directly on Android without root.This was one of the hardest parts of Zero-Assist so far, but now the AI finally has its own real Linux environment to work with."}, {"post_id": 29333, "ts": "2026-07-16T06:39:51Z", "hours": 11.0894, "text": "Giving Zero-Assist Its Own Linux Sandbox A lot of features I want in Zero-Assist need actual Linux tools: shell commands, Python, Git, Node.js, CLI tools, etc. I didn’t want this to require root, so I built a local Alpine Linux sandbox using PRoot that runs entirely on-device. The architecture is basically: AI daemon → sandbox tool → HTTP bridge → Kotlin sandbox manager → PRoot → Alpine Getting PRoot running One annoying problem was Android’s noexec restrictions. PRoot is stored inside the app’s data/native library directory and can’t always be executed normally. The solution was launching it through Android’s dynamic linker: private fun buildProcessArgs ( command : String , workingDir : String ): Array < String > { val args = arrayOf ( prootPath , \"--rootfs=$rootfsPath\" , \"--bind=/dev\" , \"--bind=/proc\" , \"--bind=/sys\" , \"--bind=$homePath:/root\" , \"--bind=$tmpPath:/tmp\" , \"-0\" , \"-w\" , workingDir , \"/bin/sh\" , \"-c\" , command ) return if ( ANDROID_LINKER != null ) arrayOf ( ANDROID_LINKER , * args ) else args } So commands effectively go through: /system/bin/linker64 → PRoot → Alpine → command This lets the bundled PRoot code run despite the noexec restriction. Connecting Rust and Kotlin My AI daemon is written in Rust, while the sandbox is managed by Kotlin. I connected them using a small NanoHTTPD server running only on localhost. return when ( session . uri ) { \"/health\" -> handleHealth () \"/execute\" -> handleExecute ( session ) \"/manage_process\" -> handleManageProcess ( session ) else -> errorJson ( Response . Status . NOT_FOUND , \"Unknown path: ${session.uri}\" ) } The Rust daemon sends authenticated requests to 127.0.0.1:49481 . The AI currently gets two tools: sandbox_execute - run Linux commands sandbox_manage_process - manage background processes Persistent shell sessions I wanted the sandbox to behave like an actual terminal instead of starting from scratch for every command. If the AI runs: cd /root/project export TEST = hello the next tool call stays in /root/project and keeps the environment variable. Each conversation gets a separate persistent shell: Conversation A → Shell A Conversation B → Shell B This keeps cwd/environment state while preventing different conversations from affecting each other. Background commands are isolated differently. Each one gets a separate PRoot executor and is tracked by a process manager. The AI can start a long-running command, continue doing other things, then check its logs or kill it later. Installing Alpine The sandbox manager handles the full setup: Download Alpine → Extract → Fix hardlinks/permissions → apk update → Install tools → Ready The hardlink fix was needed because some Alpine tar entries reference files that haven’t been extracted yet, which caused extraction failures on Android. Right now the sandbox comes with Bash, Python + pip, Node.js, Git, curl, wget, jq, SSH, lftp and rsync. The main parts are: ProotExecutor - executes commands LinuxSandboxManager - lifecycle/setup SandboxBridgeServer - Rust ↔ Kotlin bridge SandboxProcessManager - background processes PersistentSandboxShell - per-conversation shell state There is still more I want to improve, especially filesystem sharing, networking and reliability for longer agent tasks. But the main system is finally working: Zero-Assist can now give an AI agent a real Linux userspace running locally inside an Android app without requiring root. This started with the idea of somehow giving the AI a tiny Linux computer inside the app. Now it actually has one."}, {"post_id": 28451, "ts": "2026-07-14T18:16:53Z", "hours": 4.185, "text": "Giving My Android AI App Its Own Linux Sandbox One of the biggest problems with my app was that a lot of the features I wanted to build actually needed a real desktop environment. Things like: Running shell commands Browser automation Using desktop CLI tools Installing packages on demand Running scripts ZeroClaw already supports these kinds of capabilities, but on Android I couldn’t really use them to their full potential. The app simply didn’t have an environment that could support everything properly. So I decided… Why not give the app its own minimal Linux desktop? The Initial Research Luckily, I already had some experience with Linux. I had previously played around with: Linux distros PRoot chroot Minimal desktop environments So I started looking at every possible approach. Option 1 — Android’s default shell At first I thought about using the shell that every Android app already gets. It looked simple. But after experimenting with it, I realized it was missing a lot of the commands and tools I actually needed. That completely defeated the purpose of having a proper sandbox. So I dropped that idea. Option 2 — chroot Next I started researching chroot. Honestly, from a technical point of view, chroot is amazing. It gets extremely close to a real Linux environment. Performance is great and it behaves much more like an actual desktop installation. There was only one problem. It requires a rooted device. That was an immediate deal breaker. I don’t want someone to root their phone just to use my app. So chroot was out too. Option 3 — PRoot After a lot of brainstorming, reading documentation, and trying different ideas, I finally settled on PRoot. It isn’t perfect. There are still some limitations compared to a real Linux installation, but I’ll talk about those another time. The important part is this: No root required Works on normal Android devices Can run a real Linux userspace Supports the tools my AI actually needs For what I’m trying to build, it was the best balance. Choosing the distro I wanted something lightweight. Really lightweight. So I picked Alpine Linux . The base image is around 5 MB . Yes… Literally 5 MB. After installing the packages I consider “essential” for the AI (things like Python, pip, curl, git, etc.), the whole environment comes to roughly 700 MB . That gives the AI a solid starting point without making users download multiple gigabytes on day one. If more tools are needed later, the AI can simply install them inside the sandbox. Current Progress I’ve finally started implementing everything. So far I’ve added: sandbox_client.rs sandbox_main.kt Configuration files for the sandbox Default package lists that will be installed automatically There’s still a lot left to build, but the foundation is finally there. This is probably one of the biggest architectural changes I’ve made to the app so far. Instead of trying to force Android to behave like a desktop, I’m giving the AI its own Linux environment that it can actually work inside. Still a long way to go !!! MAKE SURE TO FOLLOW THE PROJECT YES THE IMAGE IS AI GENETRATED , BUT I DIDNT KNOW WHAT TO DO FOR BETTER EXPLAINATION SO I DID IT :D"}, {"post_id": 25882, "ts": "2026-07-10T11:26:04Z", "hours": 11.9064, "text": "After long time … hello guys making this devlog after very long time , i had an issue ,when i was cleaning up my project , removing the dead code and optimizing the app where i was taking the help of the antigravity for this , i accidently deleted the hardware side in the zero claw (engine of zero assist) which was in beta i was just remaining to test it because i didn’t have any proper hardware to do it so it was remaining to test and unfortunately i didn’t even had the code pushed on the GitHub which made the situation worst so now I’ve nearly fixed it , the app is successfully building properly and now I’ve decided to push the code every day if possible on the GitHub to avoid this type of things and I’m writing this devlog because of the new rule i came by where only 10 hrs. will be counted MY BAD LUCK now my 12 hrs. are going to waste 😭😭because i was not uploading the devlog and the time increased so uploading this asap so that my next time will be counted !!"}, {"post_id": 12384, "ts": "2026-06-20T06:53:41Z", "hours": 26.2319, "text": "Devlog #8 — Zero-Assist I added a Skills Section to Zero-Assist, and it’s probably one of the more useful things we’ve shipped so far. What It Is Skills are installable modules built by the Zeroclaw community that extend what the app can do. Things like Doc Writer, Auto-Coder, and more — each one teaches the app how to handle a specific type of task better. Install one, and Zero-Assist reads it and starts applying it automatically. No setup, no configuration, just tap and it works. These aren’t shortcuts or preset prompts. The app actually understands the skill and uses it to make smarter decisions when you’re working. Always Growing The library isn’t static. The community keeps adding new skills and updating existing ones, so the app naturally gets more capable over time without needing a big update from our end. Whatever gets added is available to you immediately. Big thanks to everyone in the Zeroclaw community who built and contributed skills — this whole section runs on your work. What’s Next We’re making it easier for more people to submit skills, and we’re looking at adding ratings and changelogs so you can track what’s new and what’s worth installing. More soon."}, {"post_id": 9693, "ts": "2026-06-16T03:16:35Z", "hours": 2.8722, "text": "Devlog #7 — Multi-Agent Architecture & Custom Agent Builder Zero-Assist just got a major upgrade. What if instead of one AI assistant, you had an entire team of AI specialists working together? That’s exactly what I’ve built. Multiple Agent System Zero-Assist now supports multiple specialized agents, each optimized for a specific role and workflow. Master Agent The brain of the operation. Orchestrates all agents Assigns tasks intelligently Monitors progress Routes requests to the best agent Researcher Agent Your personal information hunter. Searches the web Collects and analyzes data Returns structured insights Filters noise and focuses on relevant information Coder Agent Built for developers. Writes code Reviews code Fixes bugs Assists with architecture and implementation Planner Agent Turns chaos into clarity. Breaks down goals Creates actionable roadmaps Generates timelines Organizes complex projects Custom Agent Builder The most exciting feature in this update. You can now create your own specialized AI agents with just a few clicks. Customize: System Prompt Temperature Tags & Capabilities LLM Model Agent Role & Personality Want an AI Startup Advisor? Create one. Want a Bug-Hunting Expert? Create one. Want a Cybersecurity Specialist? Create one. The possibilities are endless. Why This Matters Most AI applications rely on a single model trying to do everything. Zero-Assist takes a different approach. Instead of one assistant, you get an entire ecosystem of AI specialists that can collaborate, delegate tasks, and work together to solve problems more efficiently. Each agent has: Its own configuration Its own expertise Its own behavior Its own model settings This creates a more scalable and intelligent workflow compared to traditional AI assistants. Vision The long-term goal isn’t just to build another chatbot. It’s to build an AI Operating System where users can create, orchestrate, and manage teams of intelligent agents that work together to accomplish complex tasks. And this is only the beginning. Screenshot attached below."}, {"post_id": 9256, "ts": "2026-06-15T15:22:43Z", "hours": 22.2608, "text": "#Devlog 6 -Zero-Assist Shipped a big update today. The app can now handle complex tasks much more reliably, and tools run in parallel instead of sequentially — so heavy workloads finish noticeably faster without the app choking midway. The smarter behavior actually came from Trimming down the soul.md, longterm-memory.md, agents.md, and user.md files reduced token usage significantly, and the model started reasoning better almost immediately. I tested it across several complex tasks and the output quality genuinely caught me off guard — results I didn’t expected!!! Voice has been a pain point for a while. Dug into the Piper latency issues, restructured the integration, and the pipeline is much smoother now. Still sounds robotic — that’s a problem I haven’t cracked yet — but the lag that made it frustrating to use is mostly gone. Overall the app feels like a different version of itself. More capable, leaner, and faster. Dropping Demo vid of the test runs below so you can see what it’s actually doing now. here is demo video too : https://youtube.com/shorts/F8sLD21dcWo"}, {"post_id": 6943, "ts": "2026-06-11T17:21:14Z", "hours": 15.2497, "text": "Devlog 5 – Channel Integration and Tool Access Today I spent most of my time working on one of the biggest features of the project so far: Channel Integration . The channels system already supports multiple platforms such as Telegram, WhatsApp, Slack, Discord, and several others. My goal was to connect these channels with the assistant so that it can interact with users across different platforms while still having access to the tools and capabilities available on the phone. To achieve this, I worked on properly connecting the Rust bridge with the Kotlin application. Once the communication layer was working correctly, I was able to expose several powerful capabilities to the assistant, including: Access to phone storage and files Accessibility-based device control Web tools and online actions Composio integrations File management and manipulation Cross-platform channel communication Various assistant tools that were previously isolated from each other This was a fairly complex task because multiple systems needed to communicate reliably. I also used AI assistance throughout the development process to help debug issues, validate approaches, and speed up implementation. In total, this work took roughly 12 hours . At the moment, I have not pushed the code to the repository because the feature still requires extensive testing. Since it touches storage access, tool execution, and communication across multiple services, I want to ensure everything is stable before making it public. Once I complete the testing phase, I will push the implementation to the repository. This feature significantly expands what the application can do. Instead of being just a chatbot, it is evolving into a full assistant platform capable of interacting with external services, managing files, controlling parts of the device, and communicating through multiple messaging platforms. The long-term vision is to create a system where users can build highly capable personal assistants that can perform real tasks rather than simply generate text. There is still a lot more work ahead, but today’s progress was a major step toward that goal. Stay tuned—some very exciting features are currently in development."}, {"post_id": 5481, "ts": "2026-06-09T09:01:08Z", "hours": 12.9753, "text": "Zero-Assist Devlog #4 — The Phone Is Now a Personal Chat Server so Devlog 4 is here. The main thing i fixed this time is the channels section of the app. channels are basically how Zero-Assist can gets input or give output to other app — like Telegram, WhatsApp, and other messaging apps. once you connect them, the app starts listening. but whats different now that channels are working, the phone isn’t just an AI assistant anymore. it’s your personal home server that you can message like a real in-person. what this actually means in practice: say you’re away and you message your own Telegram bot: “water the plants” — Zero-Assist picks that up, figures out what you mean, and either goes with an MQTT signal to your smart home setup or directly talks to your microcontroller over USB or BLE , whichever is available. no extra apps, no cloud, just your phone doing the work. same idea works for your homelab. you can message “ping my website” and the app will run the actual shell command on your phone and report back. this does need a one-time manual connection to set up, but after that it just works. basically the phone becomes a chat-controlled home automation that you own fully here is no cloud included except the llm , which you can also use the local llm . what i’m planning to add next: i’m planning a live dashboard screen for this — not raw logs, but a simplified readable feed. something like: “message received via Telegram → running plant watering command → sent MQTT signal ✓” the idea is it’s useful for people who like seeing what’s happening here, but written in plain language instead of technical stuff for the normal users . the hard part this time was : most of the time on this devlog went into connecting the Rust backend (which handles all the channel logic) to the Kotlin front-end of the app , so getting them to work together cleanly took a lot of debugging and was honestly the most frustrating part of this whole update. got it working though. more soon."}, {"post_id": 4198, "ts": "2026-06-07T12:47:20Z", "hours": 7.8933, "text": "devlog -3 added a new shared folder option int the app so that the app can share the storage from phone , it can open files edit files , manipulate the files and do lots of stuff with it , added the screenshot below"}, {"post_id": 3507, "ts": "2026-06-06T14:09:20Z", "hours": 18.2539, "text": "Devlog #2 is here!! so after the piper TTS update in devlog #1, I’ve been working on something way bigger — I added Composio integration to Zero-Assist for those who don’t know what composio is — it’s basically a platform that connects AI agents to over 1,000 apps like Gmail, Slack, GitHub, Notion, Salesforce, Google Drive and a lot more. think of it as the bridge between your AI and the rest of the internet. so now Zero-Assist can actually do things for you like — → send and read messages (if you give it the right permissions) → make notes in Notion automatically → send mails on your behalf → store your files to Google Drive → and a lot more depending on which apps you connect the best part is this feature was already there inside ZeroClaw (which is what Zero-Assist is built on), so it wasn’t built from scratch — it was more about bringing it properly into the Android app and making it actually usable. check out the video ( https://drive.google.com/file/d/1ZO56Ekrq7fu205Epqx8fH-Vkt_E5xc16/view?usp=sharing ) for a small demo of how it works"}, {"post_id": 1568, "ts": "2026-06-03T17:45:24Z", "hours": 3.4811, "text": "ZERO-ASSIST devlog 1 IM working on Zero-Assist voice assistant app on which im already working from March , the app has lots of features , i completely vibe coded the app but now im working on the finishing part of the app so today i improve the voice assist mode , the voice was really slow on cheaper Android phones. When you spoke to it, you’d wait 10+ seconds before hearing the voice response. What I fixed today 1️⃣ Made It Stop Waiting So Long Before: App waited up to 2.5-5 seconds to make sure the TTS Engine was ready Now: Only waits 0.9-1.8 seconds Result: Faster feedback !! You can also check the app here ( https://github.com/Tanmay-1122/Zero-Assist )"}]...
|
Title: Zero-Assist by @Tan-May | Stardance
Devlog Title: Zero-Assist by @Tan-May | Stardance
Devlogs:
ZERO-ASSIST devlog 1 IM working on Zero-Assist voice assistant app on which im already working from March , the app has lots of features , i completely vibe coded the app but now im working on the finishing part of the app so today i improve the voice assist mode , the voice was really slow on cheaper Android phones. When you spoke to it, you’d wait 10+ seconds before hearing the voice response. What I fixed today 1️⃣ Made It Stop Waiting So Long Before: App waited up to 2.5-5 seconds to make sure the TTS Engine was ready Now: Only waits 0.9-1.8 seconds Result: Faster feedback !! You can also check the app here ( https://github.com/Tanmay-1122/Zero-Assist )
Devlog #2 is here!! so after the piper TTS update in devlog #1, I’ve been working on something way bigger — I added Composio integration to Zero-Assist for those who don’t know what composio is — it’s basically a platform that connects AI agents to over 1,000 apps like Gmail, Slack, GitHub, Notion, Salesforce, Google Drive and a lot more. think of it as the bridge between your AI and the rest of the internet. so now Zero-Assist can actually do things for you like — → send and read messages (if you give it the right permissions) → make notes in Notion automatically → send mails on your behalf → store your files to Google Drive → and a lot more depending on which apps you connect the best part is this feature was already there inside ZeroClaw (which is what Zero-Assist is built on), so it wasn’t built from scratch — it was more about bringing it properly into the Android app and making it actually usable. check out the video ( https://drive.google.com/file/d/1ZO56Ekrq7fu205Epqx8fH-Vkt_E5xc16/view?usp=sharing ) for a small demo of how it works
devlog -3 added a new shared folder option int the app so that the app can share the storage from phone , it can open files edit files , manipulate the files and do lots of stuff with it , added the screenshot below
Zero-Assist Devlog #4 — The Phone Is Now a Personal Chat Server so Devlog 4 is here. The main thing i fixed this time is the channels section of the app. channels are basically how Zero-Assist can gets input or give output to other app — like Telegram, WhatsApp, and other messaging apps. once you connect them, the app starts listening. but whats different now that channels are working, the phone isn’t just an AI assistant anymore. it’s your personal home server that you can message like a real in-person. what this actually means in practice: say you’re away and you message your own Telegram bot: “water the plants” — Zero-Assist picks that up, figures out what you mean, and either goes with an MQTT signal to your smart home setup or directly talks to your microcontroller over USB or BLE , whichever is available. no extra apps, no cloud, just your phone doing the work. same idea works for your homelab. you can message “ping my website” and the app will run the actual shell command on your phone and report back. this does need a one-time manual connection to set up, but after that it just works. basically the phone becomes a chat-controlled home automation that you own fully here is no cloud included except the llm , which you can also use the local llm . what i’m planning to add next: i’m planning a live dashboard screen for this — not raw logs, but a simplified readable feed. something like: “message received via Telegram → running plant watering command → sent MQTT signal ✓” the idea is it’s useful for people who like seeing what’s happening here, but written in plain language instead of technical stuff for the normal users . the hard part this time was : most of the time on this devlog went into connecting the Rust backend (which handles all the channel logic) to the Kotlin front-end of the app , so getting them to work together cleanly took a lot of debugging and was honestly the most frustrating part of this whole update. got it working though. more soon.
Devlog 5 – Channel Integration and Tool Access Today I spent most of my time working on one of the biggest features of the project so far: Channel Integration . The channels system already supports multiple platforms such as Telegram, WhatsApp, Slack, Discord, and several others. My goal was to connect these channels with the assistant so that it can interact with users across different platforms while still having access to the tools and capabilities available on the phone. To achieve this, I worked on properly connecting the Rust bridge with the Kotlin application. Once the communication layer was working correctly, I was able to expose several powerful capabilities to the assistant, including: Access to phone storage and files Accessibility-based device control Web tools and online actions Composio integrations File management and manipulation Cross-platform channel communication Various assistant tools that were previously isolated from each other This was a fairly complex task because multiple systems needed to communicate reliably. I also used AI assistance throughout the development process to help debug issues, validate approaches, and speed up implementation. In total, this work took roughly 12 hours . At the moment, I have not pushed the code to the repository because the feature still requires extensive testing. Since it touches storage access, tool execution, and communication across multiple services, I want to ensure everything is stable before making it public. Once I complete the testing phase, I will push the implementation to the repository. This feature significantly expands what the application can do. Instead of being just a chatbot, it is evolving into a full assistant platform capable of interacting with external services, managing files, controlling parts of the device, and communicating through multiple messaging platforms. The long-term vision is to create a system where users can build highly capable personal assistants that can perform real tasks rather than simply generate text. There is still a lot more work ahead, but today’s progress was a major step toward that goal. Stay tuned—some very exciting features are currently in development.
#Devlog 6 -Zero-Assist Shipped a big update today. The app can now handle complex tasks much more reliably, and tools run in parallel instead of sequentially — so heavy workloads finish noticeably faster without the app choking midway. The smarter behavior actually came from Trimming down the soul.md, longterm-memory.md, agents.md, and user.md files reduced token usage significantly, and the model started reasoning better almost immediately. I tested it across several complex tasks and the output quality genuinely caught me off guard — results I didn’t expected!!! Voice has been a pain point for a while. Dug into the Piper latency issues, restructured the integration, and the pipeline is much smoother now. Still sounds robotic — that’s a problem I haven’t cracked yet — but the lag that made it frustrating to use is mostly gone. Overall the app feels like a different version of itself. More capable, leaner, and faster. Dropping Demo vid of the test runs below so you can see what it’s actually doing now. here is demo video too : https://youtube.com/shorts/F8sLD21dcWo
Devlog #7 — Multi-Agent Architecture & Custom Agent Builder Zero-Assist just got a major upgrade. What if instead of one AI assistant, you had an entire team of AI specialists working together? That’s exactly what I’ve built. Multiple Agent System Zero-Assist now supports multiple specialized agents, each optimized for a specific role and workflow. Master Agent The brain of the operation. Orchestrates all agents Assigns tasks intelligently Monitors progress Routes requests to the best agent Researcher Agent Your personal information hunter. Searches the web Collects and analyzes data Returns structured insights Filters noise and focuses on relevant information Coder Agent Built for developers. Writes code Reviews code Fixes bugs Assists with architecture and implementation Planner Agent Turns chaos into clarity. Breaks down goals Creates actionable roadmaps Generates timelines Organizes complex projects Custom Agent Builder The most exciting feature in this update. You can now create your own specialized AI agents with just a few clicks. Customize: System Prompt Temperature Tags & Capabilities LLM Model Agent Role & Personality Want an AI Startup Advisor? Create one. Want a Bug-Hunting Expert? Create one. Want a Cybersecurity Specialist? Create one. The possibilities are endless. Why This Matters Most AI applications rely on a single model trying to do everything. Zero-Assist takes a different approach. Instead of one assistant, you get an entire ecosystem of AI specialists that can collaborate, delegate tasks, and work together to solve problems more efficiently. Each agent has: Its own configuration Its own expertise Its own behavior Its own model settings This creates a more scalable and intelligent workflow compared to traditional AI assistants. Vision The long-term goal isn’t just to build another chatbot. It’s to build an AI Operating System where users can create, orchestrate, and manage teams of intelligent agents that work together to accomplish complex tasks. And this is only the beginning. Screenshot attached below.
Devlog #8 — Zero-Assist I added a Skills Section to Zero-Assist, and it’s probably one of the more useful things we’ve shipped so far. What It Is Skills are installable modules built by the Zeroclaw community that extend what the app can do. Things like Doc Writer, Auto-Coder, and more — each one teaches the app how to handle a specific type of task better. Install one, and Zero-Assist reads it and starts applying it automatically. No setup, no configuration, just tap and it works. These aren’t shortcuts or preset prompts. The app actually understands the skill and uses it to make smarter decisions when you’re working. Always Growing The library isn’t static. The community keeps adding new skills and updating existing ones, so the app naturally gets more capable over time without needing a big update from our end. Whatever gets added is available to you immediately. Big thanks to everyone in the Zeroclaw community who built and contributed skills — this whole section runs on your work. What’s Next We’re making it easier for more people to submit skills, and we’re looking at adding ratings and changelogs so you can track what’s new and what’s worth installing. More soon.
After long time … hello guys making this devlog after very long time , i had an issue ,when i was cleaning up my project , removing the dead code and optimizing the app where i was taking the help of the antigravity for this , i accidently deleted the hardware side in the zero claw (engine of zero assist) which was in beta i was just remaining to test it because i didn’t have any proper hardware to do it so it was remaining to test and unfortunately i didn’t even had the code pushed on the GitHub which made the situation worst so now I’ve nearly fixed it , the app is successfully building properly and now I’ve decided to push the code every day if possible on the GitHub to avoid this type of things and I’m writing this devlog because of the new rule i came by where only 10 hrs. will be counted MY BAD LUCK now my 12 hrs. are going to waste 😭😭because i was not uploading the devlog and the time increased so uploading this asap so that my next time will be counted !!
Giving My Android AI App Its Own Linux Sandbox One of the biggest problems with my app was that a lot of the features I wanted to build actually needed a real desktop environment. Things like: Running shell commands Browser automation Using desktop CLI tools Installing packages on demand Running scripts ZeroClaw already supports these kinds of capabilities, but on Android I couldn’t really use them to their full potential. The app simply didn’t have an environment that could support everything properly. So I decided… Why not give the app its own minimal Linux desktop? The Initial Research Luckily, I already had some experience with Linux. I had previously played around with: Linux distros PRoot chroot Minimal desktop environments So I started looking at every possible approach. Option 1 — Android’s default shell At first I thought about using the shell that every Android app already gets. It looked simple. But after experimenting with it, I realized it was missing a lot of the commands and tools I actually needed. That completely defeated the purpose of having a proper sandbox. So I dropped that idea. Option 2 — chroot Next I started researching chroot. Honestly, from a technical point of view, chroot is amazing. It gets extremely close to a real Linux environment. Performance is great and it behaves much more like an actual desktop installation. There was only one problem. It requires a rooted device. That was an immediate deal breaker. I don’t want someone to root their phone just to use my app. So chroot was out too. Option 3 — PRoot After a lot of brainstorming, reading documentation, and trying different ideas, I finally settled on PRoot. It isn’t perfect. There are still some limitations compared to a real Linux installation, but I’ll talk about those another time. The important part is this: No root required Works on normal Android devices Can run a real Linux userspace Supports the tools my AI actually needs For what I’m trying to build, it was the best balance. Choosing the distro I wanted something lightweight. Really lightweight. So I picked Alpine Linux . The base image is around 5 MB . Yes… Literally 5 MB. After installing the packages I consider “essential” for the AI (things like Python, pip, curl, git, etc.), the whole environment comes to roughly 700 MB . That gives the AI a solid starting point without making users download multiple gigabytes on day one. If more tools are needed later, the AI can simply install them inside the sandbox. Current Progress I’ve finally started implementing everything. So far I’ve added: sandbox_client.rs sandbox_main.kt Configuration files for the sandbox Default package lists that will be installed automatically There’s still a lot left to build, but the foundation is finally there. This is probably one of the biggest architectural changes I’ve made to the app so far. Instead of trying to force Android to behave like a desktop, I’m giving the AI its own Linux environment that it can actually work inside. Still a long way to go !!! MAKE SURE TO FOLLOW THE PROJECT YES THE IMAGE IS AI GENETRATED , BUT I DIDNT KNOW WHAT TO DO FOR BETTER EXPLAINATION SO I DID IT :D
Giving Zero-Assist Its Own Linux Sandbox A lot of features I want in Zero-Assist need actual Linux tools: shell commands, Python, Git, Node.js, CLI tools, etc. I didn’t want this to require root, so I built a local Alpine Linux sandbox using PRoot that runs entirely on-device. The architecture is basically: AI daemon → sandbox tool → HTTP bridge → Kotlin sandbox manager → PRoot → Alpine Getting PRoot running One annoying problem was Android’s noexec restrictions. PRoot is stored inside the app’s data/native library directory and can’t always be executed normally. The solution was launching it through Android’s dynamic linker: private fun buildProcessArgs ( command : String , workingDir : String ): Array < String > { val args = arrayOf ( prootPath , "--rootfs=$rootfsPath" , "--bind=/dev" , "--bind=/proc" , "--bind=/sys" , "--bind=$homePath:/root" , "--bind=$tmpPath:/tmp" , "-0" , "-w" , workingDir , "/bin/sh" , "-c" , command ) return if ( ANDROID_LINKER != null ) arrayOf ( ANDROID_LINKER , * args ) else args } So commands effectively go through: /system/bin/linker64 → PRoot → Alpine → command This lets the bundled PRoot code run despite the noexec restriction. Connecting Rust and Kotlin My AI daemon is written in Rust, while the sandbox is managed by Kotlin. I connected them using a small NanoHTTPD server running only on localhost. return when ( session . uri ) { "/health" -> handleHealth () "/execute" -> handleExecute ( session ) "/manage_process" -> handleManageProcess ( session ) else -> errorJson ( Response . Status . NOT_FOUND , "Unknown path: ${session.uri}" ) } The Rust daemon sends authenticated requests to 127.0.0.1:49481 . The AI currently gets two tools: sandbox_execute - run Linux commands sandbox_manage_process - manage background processes Persistent shell sessions I wanted the sandbox to behave like an actual terminal instead of starting from scratch for every command. If the AI runs: cd /root/project export TEST = hello the next tool call stays in /root/project and keeps the environment variable. Each conversation gets a separate persistent shell: Conversation A → Shell A Conversation B → Shell B This keeps cwd/environment state while preventing different conversations from affecting each other. Background commands are isolated differently. Each one gets a separate PRoot executor and is tracked by a process manager. The AI can start a long-running command, continue doing other things, then check its logs or kill it later. Installing Alpine The sandbox manager handles the full setup: Download Alpine → Extract → Fix hardlinks/permissions → apk update → Install tools → Ready The hardlink fix was needed because some Alpine tar entries reference files that haven’t been extracted yet, which caused extraction failures on Android. Right now the sandbox comes with Bash, Python + pip, Node.js, Git, curl, wget, jq, SSH, lftp and rsync. The main parts are: ProotExecutor - executes commands LinuxSandboxManager - lifecycle/setup SandboxBridgeServer - Rust ↔ Kotlin bridge SandboxProcessManager - background processes PersistentSandboxShell - per-conversation shell state There is still more I want to improve, especially filesystem sharing, networking and reliability for longer agent tasks. But the main system is finally working: Zero-Assist can now give an AI agent a real Linux userspace running locally inside an Android app without requiring root. This started with the idea of somehow giving the AI a tiny Linux computer inside the app. Now it actually has one.
Hello guys, devlog here!I finally got the Linux sandbox in Zero-Assist working end-to-end! The sandbox runs Alpine Linux through PRoot directly on Android without requiring root.Getting it working was harder than expected, though. I ran into several Android-specific issues.Fixing the SandboxThe first problem was Alpine’s heavy use of BusyBox hardlinks. My TAR extractor used File.copyTo(), which didn’t preserve executable permissions, causing errors like:proot error: execve(“/bin/sh”): Permission denied I fixed this by preserving executable bits:linkTarget.copyTo(outFile, overwrite = true) if (linkTarget.canExecute()) { outFile.setExecutable(true, false) } Some hardlinks were also extracted before BusyBox itself, so I added a second repair pass after extraction to restore critical commands like /bin/sh, /bin/ls, and /bin/cat.Symlinks were another problem because Android can block their creation. I added a fallback that copies the target when creating the actual symlink fails:try { Files.createSymbolicLink(outFile.toPath(), Paths.get(linkName)) } catch (e: Exception) { fallback.copyTo(outFile, overwrite = true) } I also had problems directly executing PRoot because some Android app directories can be noexec. The solution was to launch PRoot through Android’s system linker:val args = arrayOf( “/system/bin/linker64”, prootPath, “–rootfs=$rootfsPath”, “/bin/sh”, “-c”, command ) I also added corrupted download detection and automatic Alpine mirror fallback, making the rootfs installation much more reliable.Giving the AI Linux ToolsAfter getting the sandbox stable, I added two AI tools:sandbox_execute — Executes commands inside Alpine and supports persistent shell state, working directories, environment variables, timeouts, and background processes.sandbox_manage_process — Lets the AI list, monitor, read logs from, and kill background processes.For example, the AI can execute:{ “command”: “python3 –version && uname -a”, “working_dir”: “/root” } Or start a background server:{ “command”: “python3 -m http.server 8000”, “background”: true } The execution pipeline now looks like:AI Agent ↓ Rust Tool Layer ↓ Authenticated Local HTTP Bridge ↓ Kotlin Sandbox Manager ↓ PRoot ↓ Alpine Linux The Rust runtime communicates with the Kotlin sandbox through a localhost bridge on 127.0.0.1:49481, protected by a randomly generated per-process bearer token.And now the sandbox is fully functional end-to-end!The AI can execute real Linux commands, install packages, maintain persistent shell sessions, run scripts, start background processes, inspect their logs, and manage them — all inside Alpine Linux running directly on Android without root.This was one of the hardest parts of Zero-Assist so far, but now the AI finally has its own real Linux environment to work with.
okay so after spending lots of time on this issue , im finally able to make this work again , the problem was that (bin/sh, ust/bin/env) never extracted because of one code issue where i accidently mentioned them as the read only memory in the apps storage so the distro was installing also getting extracted but becacuse of the read only type of file , the app was not able to perform any actions on it , so now after taking the help from the open code now the sandbox is fully functional and working on every devices , also ive added some default packages which will get installed during the setup of the sandbox such as (wget, git , python3, jq, py3-pip, nodejs ,lftp and the openssh-client) just using the single command (apk add –no-cache bash curl wget git jq python3 py3-pip nodejs openssh-client lftp rsync)
So i basically went through the whole device control system and hardened it. the planner was splitting compound goals like “open instagram and message rohit” into separate calls which broke everything. also fixed it so the loop doesn’t just bail on the first response - it actually executes the action first. scroll was crashing if the planner didn’t send a direction so now it defaults down. and exceptions in the callback handler were just silently killing the process so now everything is caught and logged properly. added loop detection so it doesn’t get stuck repeating the same thing, post-action screen verification, and 44 tests to cover it all. very happy that it worked , it took lots of time but eventually i think the results are very very good though this thing not works great on the local ai’s but with the cheap api like openrouter/free , this thing can give pretty good results
Device Control Development Update Yesterday I worked on expanding the Device Control system in my AI assistant. The idea behind this feature is to allow the AI to perform real actions on an Android device using the Accessibility Service . When the user gives a command such as “Subscribe to MrBeast on YouTube” , the main AI analyzes the request and delegates it to the Device Control tool. Current Workflow Launch the required application using: PackageManager.getLaunchIntentForPackage() startActivity() Capture a compressed screenshot of the current screen. Analyze the screenshot to identify UI elements and their screen coordinates. Navigate the interface and perform actions through the Android Accessibility APIs. Current Features Open applications Tap at (x, y) Swipe gestures Type text These core primitives allow the AI to interact with almost any Android application through UI automation. Future Improvements My main goals are to improve both speed and accuracy . Instead of navigating through multiple screens for simple system operations, I plan to add native high-level commands directly into the Device Control tool, such as: flashlight_toggle wifi_toggle bluetooth_toggle mobile_data_toggle volume_set brightness_set take_screenshot lock_screen open_notifications open_quick_settings go_home go_back open_recents These commands will allow the AI to execute common Android actions instantly without relying on visual navigation. For more complex tasks—such as interacting with third-party applications—the tool will continue using the screenshot + coordinate-based navigation pipeline. Long-Term Vision The goal is to build a hybrid Device Control system: Native commands for common Android operations (fast, reliable, and efficient). Vision-guided UI automation for complex interactions within any application. This architecture will significantly reduce execution time, improve reliability, and make the assistant capable of handling virtually any task on an Android device.
Devlog: Google Workspace Integration This week I worked on integrating Google Workspace into Zero-Assist , allowing the AI to securely access services like Gmail, Google Drive, Google Docs, and Google Sheets after the user grants permission. The ZeroClaw engine already supports Google Workspace CLI (GWS) , but it was originally built for desktop Linux and expects a desktop environment with GWS already installed. Since Zero-Assist runs inside an Alpine Linux sandbox on Android using PRoot , that approach doesn’t work directly. Instead of rewriting the integration, I kept the existing architecture and adapted it for Android. What I Implemented I modified the sandbox installation process so that GWS is installed automatically whenever the user installs the standard sandbox packages. This means users don’t need to manually install or configure the CLI. Inside the app, I added a new Google Workspace plugin under: Connections → Plugins → Installed → Google Workspace When the user signs in, the Android app completes the OAuth flow and generates the required Google Workspace configuration files. To bridge Android and the Linux sandbox, I use the existing Android ↔ PRoot bridge . The plan is: User Login ↓ Android creates GWS credentials ↓ Credentials copied into PRoot sandbox ↓ Sandbox GWS CLI uses the same credentials ↓ AI can access approved Google services This keeps authentication native while allowing the Linux CLI to work without requiring the user to touch the terminal. Google Cloud Setup I also created a dedicated Google Cloud Console project for Zero-Assist. The project uses a Web Application OAuth client , which is required by the Google Workspace CLI authentication flow. I enabled the necessary APIs, including: Gmail API Google Drive API Google Docs API Google Sheets API More APIs can be enabled as additional integrations are added. Current Problem The authentication flow itself works correctly, and users can successfully sign in. The issue is that the generated credential/configuration files are not being copied correctly into the Linux sandbox . Because of this, the sandboxed GWS CLI cannot find the required authentication files, causing every Google Workspace command to fail. The current challenge isn’t OAuth—it’s reliably synchronizing credentials between Android and the PRoot environment. Once this bridge is working, users will simply sign in once, choose which Google services they want to grant access to, and Zero-Assist will be able to securely interact with those services without any manual setup. note:This devlog is written with hands and then passed to the chatgpt to format it with the .md because im very lazy to play with those colons and #’s
Devlog here , so now i added the new cool animation (thinking orb ) this animation was totally inspired from the ( https://orbs.jakubantalik.com/ ) but the problem was that the orb was written in the typescript which wont work in our app cause our app is written in the kotlin so what i did was i downloaded the zip file from the repo pasted it to the claude and told him to convert it into kotlin for me and surprisingly the results was amazing , i will share the video recording too , and the other part i worked on was i added a few voices for my apps from the hugging face so now the user can use the custom voices too and also if he wants to use some of the default voices , the option is there do download in the app, some voices ( https://huggingface.co/rhasspy/piper-voices/resolve/main/en/en_US/lessac/medium/en_US-lessac-medium.onnx , https://huggingface.co/rhasspy/piper-voices/resolve/main/en/en_US/lessac/medium/en_US-lessac-medium.onnx , https://huggingface.co/rhasspy/piper-voices/resolve/main/en/en_GB/alan/medium/en_GB-alan-medium.onnx ) for someone whose interested …
Hello Hello Hello new devlog here , so now i started with the implementation of the MCP believe me guys once the app gets the MCP the app will go to another level , like it will then support literally any app (any app) it can perform actions like the mcp does but in simpler way also when i started with implementation i hit the problem again the code is there in the zeroclaw engine but again the problem is that its meant to run on the desktop so now we again have to do some changes in code and make the mcp run natively on the phone , i also found out some resources to do it like ( https://github.com/modelcontextprotocol/kotlin-sdk ) which is good so now the idea is something similar like shown in the screenshot below taken from the chat gpt ….
Devlog time :> so now I’m continuing with the implementation of the MCP in the app like i previously talked now when i did some tinkering with the rust code using the ai , i managed to get all the connected MCP tools into the config file of the ai the config is getting updated now but the problem is that the config is constantly keeps changing don’t know what’s happening i guess the the problem is in the toml config generator which is glitching out , so now im trying fixing it from lots of time now , i guess i might have to use the antigravity to fix this but i exhausted my weekly limit cause I’m on a free tier 😭😭.. ill catch up with yall later till then bye bye 🙆..
Update !!! new devlog here … so now after doing some more research on the mcps and the implementation plans etc etc now im finally going all on it , ive added a ui component of the MCP in the Connection/Plugin/MCP , where i added few premade mcp options like (GitHub , brave search , external postgre sql etc ..) also there i added the option of the add custom server in which use can add custom server where currently the transport options are (STDIO,HTTP,SSE,LOCALHOST_STDIO (where you can add local mcp servers using the apps like termux etc ) so now that the ui is completed now i will move on to the connection part of the ui to the backend rust engine via uniffi )
Check this out !! so yesterday i finished with the MCP implementation of the app , i implemented 4 transport method (STDIO,,HTTP,SSE and the LOCALHOST_STDIO) so when i was testing out i found out that only one of them is working properly , (the http one ) to which i connected multiple apps , mcp’s etc everything was working fine but when i tested the other transport method , not even a single one was working because it all needed the desktop to run with the specific packages so unfortunately i was not able to use it and i also find out about the nasa mcp where they daily upload the images mars rover images etc so i tried to test it but the problem was that the mcp was not http instead it was the STDIO so i was sad cause i had to fix first the mcp issue then test it but when i was in school in break i was getting board and opened the app and i had an idea like cant we just convert the normal stdio into the http mcp using the termux ? after asking to claude it said definitely we can do this so then i setuped the env(i will add a screenshot below ) and made a proxy server which converts the normal stdio mcp to the http steamtable and i was then able to access it locally using my app (i will add the image of it too) and i managed to connect to the mcp and fetch the images , now everything is working completely fine just the remaining part is the remaining transport which i will fix it some how !! also i will add some images i fetched below...
|
1792936462.8937538
|
1793800462.8937538
|