DEV Community: Phone Operator Team

Building an on-device AI journal that does not confuse the prompt with the user's voice

Phone Operator Team — Mon, 03 Aug 2026 15:59:12 +0000

A journaling assistant has a deceptively hard job: it must respond to a person's meaning, not simply react to emotional keywords.

While building Rixin Mind Journal, a private Android journal with on-device AI, I learned that a small local model can sound fluent while still making a basic semantic mistake: treating the system's daily question as if the user had asked it.

For example:

System prompt: "When did you feel most peaceful today?"

User answer: "After everyone went to sleep, I worked alone."

A shallow pipeline may focus on "worked alone" and immediately warn about overwork. A better response first notices what solitude provided: uninterrupted attention, autonomy, relief from social pressure, or simply a quiet room.

That distinction changed the architecture.

1. Keep the system prompt and user answer in separate fields

Do not concatenate everything into an undifferentiated paragraph and hope the model infers the roles.

The analysis input explicitly labels:

Question asked by the app
Answer written by the user
Optional free-form diary text
Prior patterns, when generating a weekly or monthly report

The instruction also states that the question is context, not a claim or request made by the user.

This sounds obvious, but it eliminated an entire class of confidently wrong responses.

2. Analyze the whole entry before generating prose

Keyword matching is useful as a safety net, but it is not understanding.

"Lazy" can mean shame, fatigue, avoidance, rebellion, depression, humor, or a temporary loss of routine. "Fine" can mean genuine calm or emotional shutdown. "Alone" can mean loneliness or freedom.

The pipeline therefore separates analysis from writing:

Identify the concrete situation.
Estimate emotional valence and intensity.
Look for mixed emotions and negation.
Infer the likely need or tension.
Select one relevant psychological frame.
Generate one small, behaviorally specific next step.
Write the final response in a warm voice.

The final prose is not allowed to expose the internal labels or repeat large pieces of the diary.

3. Receive emotion before offering advice

Advice given too early feels like correction.

The response order is deliberately constrained:

Recognition: show that the experience was understood.
Insight: name one useful pattern, conflict, or need.
Action: suggest one small step that could survive an ordinary day.
Closing line: end with warmth, not another question the user cannot answer.

This matters for positive emotion too. A reflection engine should not treat every joyful entry as hidden pathology. Relief, pride, affection, playfulness, gratitude, and calm are information about what supports the person.

4. Use expert rules as guardrails, not as the final writer

Early versions relied too heavily on templates. They were safe, but different diary entries produced suspiciously similar responses.

The current approach uses expert rules to control:

role separation
emotion-negation checks
crisis language
medical boundaries
response order
repetition limits
banned meta phrases such as "the user answered..."
action specificity

The local model is still responsible for most of the wording. Rules shape the lane; they do not write every sentence.

5. Evaluate semantic fit, not only grammatical quality

A fluent answer can still be useless.

Our test cases cover different ages, jobs, relationships and emotional states. Each output is reviewed against questions such as:

Did it identify the actual situation?
Did it preserve positive emotion instead of turning it negative?
Did it acknowledge mixed feelings?
Is the advice concrete enough to attempt?
Could the same response be pasted under a different diary entry?
Does it sound like a person, or like a classification report?

The most valuable failure metric is replaceability. If an insight could fit twenty unrelated entries, it is too generic.

6. Privacy is part of the product behavior

On-device processing is not only an infrastructure decision. It changes what users are willing to write.

Rixin keeps diary writing local-first and performs AI reflection on the device. It supports guided questions, free-form journaling, daily insights, and longer weekly/monthly letters. The app is for self-reflection, not diagnosis or therapy.

The tradeoff is real: a small local model has less raw capability than a large cloud model. The way forward is not to pretend otherwise, but to narrow the task, provide expert structure, test diverse failure cases, and make the output earn its place.

If you are building any AI product that handles personal writing, I would recommend testing role confusion, negation, mixed emotion, positive emotion, and generic-response reuse before polishing the UI.

Rixin Mind Journal on Google Play:

https://play.google.com/store/apps/details?id=com.rixin.app

I would especially value feedback from Android and local-AI developers on the balance between privacy, model size, and semantic accuracy.

Designing Reliable No-Root Android Tap and Swipe Automation

Phone Operator Team — Mon, 03 Aug 2026 11:19:59 +0000

Repeated taps look simple until you try to automate them reliably across real Android devices. A gesture that works in a test screen can miss its target inside another app, drift after rotation, stop when the display sleeps, or become impossible to cancel when an overlay loses state.

I am building Phone Operator, a no-root Android automation utility, and these are the design rules that made the biggest difference. The goal here is not to automate purchases, CAPTCHA solving, fake engagement, or game-rule bypasses. It is to make user-configured, local gesture sequences predictable for repetitive personal workflows and testing.

1. Separate the control plane from the execution plane

A robust automation app has two different jobs:

The control plane lets a user create actions, change intervals, move markers, save scripts, and start or pause a run.
The execution plane validates the script, resolves coordinates, dispatches gestures, tracks cancellation, and reports progress.

Mixing both jobs inside an overlay service creates subtle failures. Dragging the floating menu can mutate gesture state. Rebuilding the overlay can cancel a scheduled action. A configuration edit can race with the currently executing action.

A safer model is to compile the editable script into an immutable runtime plan before execution. The runner reads that snapshot only. Later edits affect the next run, not the current one.

2. Make touch geometry visible and honest

If the UI says a tap has a 50 px random range, the marker should show that same range. Users should not have to imagine an invisible sampling area.

The useful model is:

marker center = configured target
visible radius = configured random radius
generated point = always inside that circle
final point = clamped to the usable display bounds

Uniform random sampling inside a circle needs area correction. If u and v are random values in [0, 1), use:

radius = maxRadius * sqrt(u)
angle = 2 * PI * v
x = centerX + radius * cos(angle)
y = centerY + radius * sin(angle)

Without the square root, points cluster near the center. If you sample X and Y independently in a square, some points fall outside the circle the UI promised.

The marker itself should not intercept the gesture. On Android overlays, visual layers and touchable control layers should be separated deliberately. A common cause of taps landing above the marker is subtracting the status-bar inset twice or mixing screen coordinates with window coordinates.

3. Treat every action as its own configuration

A real script is not “choose one global gesture and repeat it.” Each step needs its own data:

action type: tap, double tap, or directional swipe
start point and optional end point
random range
fixed or randomized interval
delay before the next action
repeat count, with unlimited as a first-class value

This lets a sequence combine tap, left swipe, another tap, and an upward swipe without inheriting accidental settings from a previous step.

For swipes, the overlay should display direction and configured distance, but the indicator should not animate along the swipe path. Moving the marker while a script is running makes users think the configured start point changed and can also trigger layout updates at the worst time.

4. Cancellation is part of the gesture protocol

“Pause” should not just change a button label. It should invalidate every scheduled continuation.

One practical approach is a monotonically increasing run token:

start: token += 1; runner receives token
pause: token += 1
before every delay or dispatch: stop if local token != current token

That makes stale callbacks harmless. It also prevents the classic bug where an old timer restarts the script after the user has already paused it.

Android gesture dispatch is asynchronous, so every action also needs a completion path, a cancellation path, and a timeout fallback. The queue must advance exactly once. Put that guarantee in one scheduler component instead of duplicating it across tap and swipe implementations.

5. Keep overlays stable across apps and rotations

The floating control surface has to survive app switches without becoming a fragile second activity.

Important details include:

use the appropriate application overlay window type
keep window updates on the main thread
clamp dragged controls to the current display bounds
recalculate bounds after rotation or configuration changes
persist only the final drag position, not every movement event
catch invalid window-token and already-removed-view states

Dragging should update only the menu window. Gesture markers should keep their configured coordinates unless the user explicitly moves them.

Opacity is also a usability feature. Markers need enough contrast to identify “tap,” “double tap,” or swipe direction, but they cannot cover the content users are trying to target. A global opacity setting with a readable minimum works better than fully opaque controls.

6. Plan for Android power management

Gesture automation does not automatically guarantee that the display remains awake. Device vendors also apply different battery and background restrictions.

The app should explain this before a long run, not after it stops. Depending on the use case, a user may need to adjust screen timeout, battery optimization, background activity, or vendor-specific autostart settings. The app should link users into the closest relevant system settings page while leaving the final change under user control.

A foreground service can keep a user-visible task alive, but it is not a license to run invisibly. The notification should clearly state that an automation session is active and provide a stop action.

7. Design permission disclosure as product UI

A no-root solution typically relies on Android AccessibilityService for gesture dispatch and overlay permission for controls above other apps. These are sensitive capabilities.

A good permission flow explains, before opening system settings:

what capability is requested
why the feature cannot work without it
what data is and is not collected
how to disable the capability later

The service should execute only actions the user configured and explicitly started. Script data can remain local. The app should also make prohibited or risky uses clear instead of presenting automation as unlimited.

8. Debug failures with a deterministic checklist

When an action misses or stops, log the inputs that explain the result:

compiled action ID and type
raw configured coordinates
window insets and display size
final sampled and clamped coordinates
dispatch start, callback, cancellation, and timeout
current run token
AccessibilityService and overlay state

That turns “the tap did nothing” into a reproducible geometry or lifecycle problem.

Further practical checklists

Two device-level issues deserve their own checklists because they are easy to miss during implementation:

Both guides are based on the same implementation work behind Phone Operator, and they keep the safety and disclosure constraints explicit.

Closing thought

Reliable Android automation is less about dispatching gestures quickly and more about keeping configuration, geometry, lifecycle, and user trust consistent. The best default is still the simplest one: one fixed tap, unlimited repeats, and an obvious stop control. Advanced mixed scripts should build on that model without making the first run harder.

I am applying these ideas in Phone Operator on Google Play. I also published practical guides for no-root setup and why auto clickers stop. Feedback about device-specific edge cases is welcome.