What happened
The GitHub release page says wangzan101 published Mika v0.1.33 on November 1. Mika is an open-source Android agent; the supplied project description says it can operate apps and the web on a hidden background screen. The release page focuses on changes to configuration, task continuity, subtasks, screen behavior, compatibility feedback, and APK packaging.
Users can now configure an HTTP or SOCKS proxy under Settings › Network proxy. The release says this proxy is used for model requests, account sign-in, update checks and downloads, the built-in browser, and the sandbox, without requiring a system-wide VPN. Local models on the same LAN connect directly. Mika reports separately when the proxy cannot be reached or its credentials are wrong, and a proxy previously configured for the sandbox is carried over.
The scope matters because the setting is presented as one route for several parts of the application rather than as a browser-only option. It covers traffic involved in using a model, signing in, retrieving updates, browsing, and running the sandbox. At the same time, the release distinguishes local models on the LAN, which are described as connecting directly. The page does not specify proxy authentication methods beyond reporting bad credentials, nor does it describe network-policy controls beyond the stated HTTP and SOCKS options.
The release also changes how a conversation can resume work. When the user says “Continue,” Mika can look back at material gathered in earlier runs within that same chat rather than gathering it again from scratch. Subtasks that Mika delegates can be given more steps and longer results when needed. The release does not specify numerical limits for either setting, how the retained material is selected, or whether the mechanism applies across separate chats.
During a task, the screen remains on, but the system can dim it when the user is not interacting with the phone. A self-check that sometimes incorrectly reported screen-reading failure when a device displayed button text in all caps has been fixed. For environments without developer options and wireless debugging, setup now explains that phone control is unavailable; chat, web, and files remain usable, and the self-check reports the limitation. This is a clearer split between the app’s general functions and its ability to operate the device.
The release offers a new arm64-only APK of about 79 MB, described as suitable for almost any recent Android phone, alongside a universal APK of about 92 MB that installs on every phone. Both have the same features and can be installed over one another. The app’s About › Check for updates option automatically selects the appropriate package. Installing over an older version retains chats and settings.
What the archive adds
This is a new release on a known story, not a first report about Mika. The earlier Field Note on Mika’s 1,100 stars covered the hidden-background-screen approach and early adoption. Our note on v0.1.13 covered USB startup, interaction pacing, and OpenAI Responses providers. Version 0.1.33 adds day-to-day configuration and continuity details rather than changing the product’s basic premise.
Trend signal
This release weakly supports agent-ready software exposes capabilities: Mika exposes a configurable network proxy and separates usable chat, web, and file functions from device-control capability when prerequisites are absent. The release does not establish a broader industry shift, but it illustrates why explicit capability boundaries matter in a mobile agent.
Why now
The immediate timing is a versioned release published on November 1, following earlier Mika notes from October 31. The supplied material does not identify an external trigger, customer deadline, or platform-policy change behind the update. What it does show is a product moving from a basic mobile-agent demonstration toward operational details: routing traffic, preserving context within a chat, sizing delegated work, and reporting missing device-control prerequisites before a user expects automation to work.
Connections to other events
Mika’s current release follows the earlier v0.1.13 update, which added USB startup, interaction pacing controls, and OpenAI Responses providers. That sequence connects setup and model-provider work with the newer networking and continuation mechanics. It also follows the earlier note documenting Mika’s rapid early star growth and hidden-background-screen design. The available archive does not establish that these releases share a broader technical dependency with other products; the connection is the project’s own progression from access and interaction controls to runtime configuration.
Why it matters
Mobile agents encounter constraints that desktop-oriented demos can hide: network routing, device permissions, screen state, and the cost of repeating work. Mika’s proxy setting makes it easier to test the agent in environments that route model or browser traffic through a proxy, while leaving LAN models on a direct path. Its separate proxy errors can help distinguish a connectivity problem from an agent or model failure.
Continuation across runs may reduce repeated browsing or app inspection within a conversation, and configurable subtasks give builders more room for longer tasks. The practical consequence is not simply that a model can issue phone actions. A team must be able to determine whether a failure came from network access, an unavailable permission, a screen-reading condition, or the task itself. Mika’s release note describes a few mechanisms for making those distinctions visible.
These are useful mechanics, but they are not evidence that the agent reliably completes workflows. Teams evaluating phone-use agents should test permissions and failure states on actual target devices, not infer broad compatibility from a release note. They should also decide whether their network routing requirements permit model, browser, update, and sandbox traffic to share the proxy path described by the project.
What happens next
- Mika will likely continue releasing operational controls around setup, execution, and compatibility rather than only adding demonstration tasks (3 months, 65%). Watch for: version notes that add explicit task controls or device-state reporting.
- Builders evaluating Mika will need device-specific validation before treating its phone-control capability as deployable (6 months, 75%). Watch for: published supported-device matrices, reliability results, or reproducible task evaluations.
Limits and uncertainty
The release page does not provide reliability measurements, task-success rates, supported-device lists, or comparative performance data. It does not quantify how many steps or how much longer subtask results may be, nor how much time or network traffic continuation saves. The page says Mika can look back at information from earlier runs in the same chat, but it does not describe retention duration, isolation, or the boundaries of that lookup.
The proxy description names the traffic categories that use it but does not establish security properties or behavior under every network configuration. The release also does not show that environments lacking developer options and wireless debugging can control the phone; it explicitly says those environments retain chat, web, and file functionality instead. The supplied material gives a star count for the repository but does not make popularity a measure of task reliability or safety.
Skill to build now
Create a small device-readiness test for any mobile-agent experiment this week. On one target Android device, record whether developer options and wireless debugging are available, whether the agent’s self-check passes, and whether its required network traffic works through the organization’s HTTP or SOCKS proxy. Then run the same bounded task twice in one chat and observe whether “Continue” reuses relevant findings rather than repeating collection. Keep the result as a device-and-network compatibility record, not as a general claim about Android support.
Reader takeaway
Mika 0.1.33 is a practical iteration for teams evaluating Android agents: proxy routing, within-chat continuity, adjustable subtasks, and clearer capability reporting make experiments easier to configure. Its value is in making an evaluation environment more observable and repeatable, not in proving that phone automation is dependable. Validate network behavior and device-control prerequisites on the specific phones your workflow needs to support.
Open question
Can Mika demonstrate repeatable task-success rates across named Android devices and network configurations, especially where device-control permissions are unavailable or constrained?