Jev Chat accumulated 1,298 GitHub stars in roughly 15 hours after its repository was created. By our source check a few hours later, the GitHub API reported 1,994 stars and 624 forks. That speed makes the project worth examining before its claims harden into reputation. The Android app watches visible conversations in WeChat, QQ, X and Feishu, asks models what the other person means, then places a suggested response in the input box. The unusual part is how much of Android's accessibility layer it uses to do that.
The project calls itself a conversation copilot, and the README draws a firm line at the send button. Jev can read the current chat, rate the situation, draft three replies and fill one into the composer. The user still decides whether to send it. That boundary limits one obvious risk, while the app's access to messages, screenshots and model endpoints creates several others that deserve equal attention.
The Android layer under the star count
Version 1.3 is a Kotlin app for Android 11 and later, released under the MIT license. The repository includes source, build instructions and a signed APK of about 25.8 MB rather than directing users to an app store. Its changelog says the package grew from about 12 MB after the addition of a bundled Chinese OCR model. The published limitations restrict the binary to arm64 devices and note that X has only been tested with a Chinese interface.
Once enabled, the service reacts to a new message from the other participant. The state builder puts the last 10 visible messages into a structured request for the judgment model. A separate reply client sends the same 10-message window to an OpenAI-compatible chat endpoint and asks for three short Chinese responses. Jev then ranks those candidates.
The code supports the promise that Jev does not press send. Its capture service writes the selected text with Android's ACTION_SET_TEXT operation and falls back to clipboard paste if that fails. Automatic analysis is debounced by 800 milliseconds, and it only starts when the latest captured message is marked as coming from the other person. The service logs message lengths and speaker sides, rather than the message text itself.
Feishu needs a different route because its message bodies are not exposed as ordinary accessibility nodes. Jev takes a screenshot and runs Google's bundled Chinese ML Kit recognizer on the device, according to the build configuration. Other unsupported apps can use a manual one-shot screen scan. A separate vision client can encode a screenshot as JPEG and send it to a configured vision model, but local ML Kit is the default OCR engine.
The WeChat workaround carries the widest permission
Jev's most consequential engineering choice is visible in its Android manifest. The accessibility service is registered as com.google.android.accessibility.selecttospeak.SelectToSpeakService. A source comment says this system-style class name is a disguise used to make WeChat 8.0.78 expose its full node tree. The accompanying service configuration requests all accessibility event types, access to interactive windows, permission to retrieve window content and permission to take screenshots. It also declares isAccessibilityTool="true".
That last flag has a defined policy meaning. Google Play's AccessibilityService rules say only apps designed to help people with disabilities may identify themselves as accessibility tools. The policy explicitly lists assistants among products that do not qualify. Other uses of the API are allowed, but they require a separate in-app disclosure, affirmative consent and a Play Console declaration. Jev currently distributes its APK through GitHub, so this does not establish how Google would review it. It does show that a Play release would need a different explanation or implementation.
The permission is broader than the supported-app list might suggest. Jev's preferences code leaves the conversation whitelist empty by default, which means every conversation in an adapted app is eligible. Automatic analysis also defaults to on. Unknown apps are not scanned automatically, and the overlay's manual OCR action is required there, as the capture service makes clear. Users can disable automatic analysis or create a whitelist, but the initial settings favor immediate operation.
Private storage ends at the model request
The app does make several defensible local-storage choices. The manifest disables Android backup. API credentials live in app-private SharedPreferences, the service avoids logging message content, and saved chat history is off by default. When a user enables history, the preferences and knowledge-store path keeps it in the app's private directory and provides a clear-all function. The repository also contains no intermediary Jev server for routing those chats.
Analysis still transfers conversation content off the phone. The judgment request contains up to 10 recent messages, the relationship description and any enabled notes or older history. The generation request sends that material to a second endpoint to draft replies, as shown in JevQuestions.kt and ReplyClient.kt. The default routes use OpenRouter and TypeSafe's Jev model, with DeepSeek selected for reply generation through an OpenAI-compatible route. Users can replace each provider.
The README's on-device privacy claim therefore applies to storage and the absence of a project-run relay. Current message text still reaches whichever model services a user configures. Jev's HTTP client places the user's API key in a bearer header and posts JSON directly to the chosen URL. The settings accept a custom full URL, and the client does not reject plain HTTP. Anyone testing the app should use an HTTPS endpoint they trust and read that provider's retention terms before opening a sensitive conversation.
The credentials themselves are private to the app but are stored as ordinary strings, not through Android Keystore-backed encryption. That distinction is visible in Prefs.kt, which uses Context.MODE_PRIVATE SharedPreferences and has no encryption layer. Android's sandbox blocks normal cross-app reads, and backup is disabled. A phone compromise, debug exposure or a malicious build remains a different threat model, especially for an app that holds model credentials and can inspect chat windows.
Intent scores need published evidence
Jev labels its outputs with phrases such as true intent, danger level and what the other person needs. Those labels can sound more certain than the repository's public evaluation supports. The project's acceptance document sets a target of at least 60 percent accuracy for two classification questions and less than one point of mean absolute error for the danger score across at least 20 labeled Chinese dialogue samples. The source tree contains 30 labeled fixtures, but it does not include the calibration report that the project plan says should record the results.
Device support also mixes verified and inferred cases. The README's support table says WeChat 8.0.78, QQ group chat, Chinese-language X direct messages and Feishu were tested on devices. QQ one-to-one chat is inferred from the group structure, X in English remains untested, and group conversations are analyzed as if there were one counterpart. Feishu speaker assignment relies on read status and can be reversed. These are unusually candid limits, and they matter more than the star count when deciding whether an inferred social warning deserves attention.
The repository's open issues are already asking for more app support and questioning how much history the model can see. That is useful demand evidence, not proof that the current judgments are right. The next release worth watching is one that publishes the calibration output promised by the acceptance criteria and makes its accessibility disclosure match the breadth of the permission. Until then, Jev's fast adoption shows that people want help inside existing chats. It does not reduce the trust required to let an APK read those chats.