标签：#Android

Meet unzstd - a pure Java Zstandard (zstd) decoder for Android and the JVM. What looked like a simple dependency turned into a surprisingly difficult problem. I needed to decompress zstd-compressed datasets in an Android app. Existing options all had major trade-offs: aircompressor 2.x depends on "sun.misc.Unsafe", which crashes on Android ART. aircompressor 3.x moved to "java.lang.foreign", which Android doesn't support. zstd-jni works well, but requires native ".so" files, ABI-specific packaging, and brings additional complexity with newer Android memory page requirements. I had to build a pure Java alternative so I ported aircompressor's decoder The result: ✅ No native code ✅ No "Unsafe" ✅ No "java.lang.foreign" ✅ Android API 26+ ✅ JVM 9+ ✅ Zero "Unsafe" references in the compiled bytecode (verified) To make sure it was actually correct, I differentially tested it against libzstd across compression levels 1-22, covering one-shot decompression, streaming, fuzzing, and corruption-boundary tests. It's decode-only, Apache 2.0 licensed, and completely open source. If you're building Android or Java applications that consume zstd-compressed data, I hope this saves you a few days of debugging. implementation("com.qyntrax:unzstd:0.1.0") GitHub: https://github.com/mbobiosio/unzstd Feedback, bug reports, and contributions are always welcome. Android #Java #Kotlin #OpenSource #JVM #Zstd #Compression

X says the rebuilt version of its Android app is now available globally.

A consumer health app isn't one product. It's eleven products stitched together into a single...

To learn how to analyze an error, we are going to use the error below as an example: nx run mobile : android ✔ 7 / 7 dependent project tasks succeeded [ 6 read from cache ] Hint : you can run the command with -- verbose to see the full dependent project outputs ————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————— > nx run mobile : android > npx expo run : android › Opening emulator Medium_Phone › Building app ... Starting a Gradle Daemon ( subsequent builds will be faster ) Configuration on demand is an incubating feature . > Configure project : [ ExpoRootProject ] Using the following versions : - buildTools : 36.0 . 0 - minSdk : 24 - compileSdk : 36 - targetSdk : 36 - ndk : 27.1 . 12297006 - kotlin : 2.1 . 20 - ksp : 2.1 . 20 - 2.0 . 1 > Configure project : app ℹ️ Applying gradle plugin ' expo-max-sdk-override-plugin ' [ expo - max - sdk - override - plugin ] This plugin will find all permissions declared with `android:maxSdkVersion` . If there exists a declaration with the `android:maxSdkVer sion` annotation and another one without , the plugin will remove the annotation from the final merged manifest . In order to see a log with the changes run a clean build of the app . ℹ️ Applying gradle plugin ' expo-dev-launcher-gradle-plugin ' > Configure project : react - native - firebase_app : react - native - firebase_app package . json found at / home / user / projects / my - app / node_modules / @ react - native - firebase / app / package . json : react - native - firebase_app : firebase . bom using default value : 34.10 . 0 dencies of : app : debugRuntimeClasspath > : react - native - firebas : react - native - firebase_app : play . play - services - auth using default value : 21.5 . 0 : react - native - firebase_app package . json found at / home / user / projects / my - app / node_modules / @ react - native - firebase / app / package . json : react - native - firebase_app : version set from

If you are like me, then you have also tried to change a specific thing in your workout plan that your app of choice didn't support. Well I'm trying to fix that issue with a workout app in which you'll be able to customize pretty much everything (WIP). Building the thing in Flutter to have mobile (starting with Android) and web. The web app is live! If you work out and have tried similar apps before, your feedback would be gold. But really any feedback is appreciated. I also found that finding the required 12 people with an Android phone for closed testing on Google Play Console was more difficult than anticipated. So if you'd be interested in that, hit me up at dev@notes.fitness ! Gym Notes — A Customizable Workout Logbook for Strength Training A free, customizable workout logbook that tracks exercises, sets, reps, and weights. Built-in training plans with automatic progression. gym.notes.fitness

Why We Built This As developers and builders at Smart Tech Devs , we love analyzing data trends. But when it comes to trading charts—whether it's crypto, stocks, or forex—reading technical signals manually requires hours of screen time. Beginners struggle with complex patterns, and experienced traders often want a quick sanity check on their thesis. We asked ourselves: Can we leverage Vision LLMs to turn static chart screenshots into professional-grade technical analysis reports in seconds? That question led us to build and launch Realtime Chart Analyzer (ChartAI Pro) , now live on the Google Play Store! ⚡ Key Architectural Features We designed ChartAI Pro to act as a seamless, secure second pair of eyes for market charting. Here is a breakdown of what the application delivers right out of the box: 🧠 1. Multi-Modal AI Chart Analysis Instant Processing: Upload or snap a screenshot from platforms like TradingView, Binance, Zerodha, Groww, Upstox, or MT4/MT5. Signal Detection: The core engine evaluates market structures to return clear Bullish or Bearish indicators alongside an AI confidence score. Plain-English Summaries: No overly dense academic jargon—you receive an intelligible breakdown of current market conditions. 🎯 2. Automated Key Price Levels & Patterns Support & Resistance: The system instantly flags primary macro price horizons. Risk Mitigation: Calculates approximate entry zones, mathematical target price targets, and clear Risk/Reward ratios. Geometric Processing: Detects complex shapes including Head & Shoulders, Double Tops/Bottoms, Triangles, Wedges, Flags, and specialized candlesticks (Doji, Engulfing lines). 📊 3. Native Live Market Infrastructure Live Scanners: Includes a built-in terminal tracking real-time crypto, forex, and stock prices (NSE & BSE). Interactive Tooling: Features built-in interactive TradingView frames directly in the layout, allowing you to scan Top Gainers and Losers without hopping between apps. 🔒 Privacy & Security First When d

OnePlus promises to continue supporting the phones it has already released.

Most Android media apps solve only one part of the problem. A video player plays videos. A music player handles songs. A PDF reader displays documents. A text-to-speech app reads text. A vault hides private files. But real media libraries are not separated that neatly. My phone may contain downloaded movies, music, lecture notes, ebooks, PDFs, recordings, subtitles, and files I do not want exposed in the normal gallery. Constantly moving between different apps creates friction and breaks playback or reading continuity. That is why I built Nexo Player : an offline-first Android media app that brings local playback, document reading, audiobook generation, text-to-speech, and private storage into one experience. What Nexo Player does Nexo Player currently supports: Local video and audio playback PDF and EPUB reading PDF, EPUB, and text narration Background audiobook generation MP3, M4B, and ZIP export Multiple narrator voices Resume playback and reading progress Equalizer, sleep timer, subtitles, and playback-speed controls Picture-in-Picture Secure Vault protected with PIN or biometrics The app is built natively for Android using Kotlin , Jetpack Compose , and Android Media3 . The main product idea: local-first media The core rule behind the app is simple: A local file should remain local unless the user explicitly chooses otherwise. This rule influenced the entire product. Opening a downloaded video should not require an account. Reading a PDF should not require uploading it to a server. Listening to a generated audiobook should remain possible without a permanent internet connection. Private files should not leak into normal galleries, thumbnails, or recent-history screens. Offline-first is not only about caching data. It means the main workflow must remain useful, understandable, and recoverable without depending on the network. Building the playback layer For video and audio playback, I used Android Media3 as the foundation. The visible player looks simple, but a

A patient opens their prescription and sees 500mg instead of 50mg. A lab report displays "Normal"...

Commerce is the easiest feature in this release to misunderstand, so the first sentence has to be blunt: What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . Commerce does not replace IAP and never will. Purchases still go through Apple, Google, or the payment processor you chose. Codename One does not process the payment, does not touch the money, and does not take a percentage. PR #5300 adds infrastructure around the annoying backend work that comes after a purchase: validation, entitlement checks, subscription lifecycle, webhooks, and reporting. That backend work is real. Anyone who has shipped subscriptions knows the trap. Buying a SKU is not the same as knowing whether the user has the right to a feature right now. Renewals, grace periods, refunds, billing retry, product changes, trials, family sharing and store server notifications all show up later. The device has one view. The store has another. Your backend usually needs a third. Commerce is the optional service that turns that mess into an entitlement. Entitlements Instead Of SKU Branches Your app should not need to know every SKU that grants pro . It should ask for pro . CommerceManager cm = CommerceManager . getInstance (); cm . setAppUserId ( accountId ); if ( cm . isEntitled ( "pro" )) { unlockProFeatures (); } Purchases are still delegated to the existing Purchase API: cm . subscribe ( "pro_monthly" ); // or cm . purchase ( "remove_ads" ); After a purchase, or when the app starts, refresh off the EDT: new Thread (() -> { CommerceManager cm = CommerceManager . getInstance (); cm . refresh (); CN . callSerially (() -> { if ( cm . isEntitled ( "pro" )) { unlockProFeatures (); } }); }). start (); refresh() validates the current receipts with the cloud when the build has a build_key and commerce is enabled. In a local build or simulator, it safely falls back to the normal

Opening hook It happened during a quiet afternoon in the library. I was deep in a documentation sprint, and the only sound was the rhythmic tapping of my mechanical keyboard. Suddenly, my phone erupted into a high-pitched, aggressive ringtone that seemed to echo off every wall. Every head in the room turned toward me in unison. My face burned as I scrambled to silence the device, fumbling with the volume buttons while the caller—a telemarketer, of all people—continued to interrupt the silence. It was a humiliating, avoidable moment of pure friction. The problem We live in an age where our phones are supposedly "smart," yet they consistently fail at the most basic context-aware tasks. I found myself constantly needing to switch my phone to silent or vibrate, but the human error component was 100 percent. I would enter a meeting, forget to silence, and pray I didn’t get a call. I would leave a prayer or a lecture, forget to unmute, and then miss urgent calls for the rest of the afternoon. Existing solutions felt heavy-handed. Many automation apps relied on massive, bloated frameworks that kept the CPU awake, draining my battery just to check if I was near a specific building. I didn't want a system that required constant polling or cloud-based synchronization just to realize I was at work or at the gym. I needed something that felt native, lightweight, and, above all, respectful of the hardware's limited power budget. I wanted a way to define boundaries where my phone would simply handle itself, without me having to remember a single toggle. The technical decision / implementation When I started building Muffle, the biggest challenge was the Geofencing API. The temptation is to use LocationManager and track the device's coordinates in real-time, but that’s an immediate death sentence for battery life. Instead, I opted for the GeofencingClient within the Google Play Services library. This is a crucial distinction: LocationManager gives you raw data that you have to pro

Local LLM inference has an expensive habit: It recomputes prefixes it has already seen. A system prompt. A reused RAG document. A few-shot block. A long static context. If the prefix is identical, why pay the prefill cost again? That's the problem I explored with EdgeSync-LLM. The idea The mechanism is simple: Prompt = shared prefix + new suffix On the first request, EdgeSync prefills the prefix and captures its KV cache state. On the next request sharing that exact prefix, it restores the state and decodes only the new suffix. No llama.cpp fork. No patch. The current validated path uses the public: llama_state_seq_get_data and llama_state_seq_set_data APIs. Measured on a real Android ARM64 phone Model: Qwen2.5-0.5B-Instruct Q4_K_M Shared prefix: 123 tokens 40 requests. 4 threads. Release build. Path Mean TTFT p50 p95 Cold 4828 ms 4752 ms 5297 ms KV state reuse 486 ms 476 ms 569 ms 9.9× lower TTFT on cache hits. The warm path was approximately: 363 ms to decode the 10-token suffix 123 ms to restore the state blob Fragment size: 1.64 MB I also measured the same mechanism on x86-64. Cold mean TTFT: 1395 ms Warm mean TTFT: 185 ms That's 7.5× on cache hits. But I almost published a fake 8.8× speedup This was the most important part of the project. My first implementation directly copied raw K/V tensors. It was fast. Very fast. The benchmark reported an 8.8× speedup. There was one problem. It was wrong. llama.cpp tracks more than the K/V tensor values. Cache cells also have position and sequence metadata used to construct the attention mask. Copying tensor values without restoring that bookkeeping produced an inert fragment. The model skipped prefix computation... ...but attention could not actually see the restored prefix. 14 of 24 cache hits reproduced, token for token, the output of a generation with no prefix at all. The “speedup” was dropped context. So I discarded it. Timing is not enough A broken cache can be fast. That's why EdgeSync now runs two correctness chec

Whether it’s through Google Maps or Emergency SOS, there are plenty of ways to quickly let your loved ones know where you are.

In Tutorial 1 Duke dashed for coffee with arcade physics. Now he sets the cup down for a calmer contest: Duke Jack , a game of blackjack. A card game has none of that arcade motion — cards sit on the felt and the rules decide who wins. This tutorial shows how the same Game Builder pattern (visual data + an onUpdate companion) handles a card game, where your code reads the cards and runs the table instead of simulating movement. We'll build a felt table, deal a real hand, and wire up the complete blackjack rules: hit, stand, the dealer's draw, and the win/lose decision. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . If you haven't set up a project yet, the project setup in Tutorial 1 applies verbatim — only the mode changes (board mode isn't the default, so the -Dmode=board flag is required here): mvn cn1:create-game-scene -DclassName = com.example.dukejack.DukeJack -Dmode = board mvn cn1:gamebuilder Why board mode for cards? Board mode is the Game Builder's grid mode: you place elements on a flat board of cells instead of a free-scrolling world. That's a natural fit for a card table — the felt is a tile layer, and each card is an element you position by hand, carrying its own rank , suit and faceUp data. There's no physics and no camera to chase; the layout is the game state, and your rules read it. (Board mode can also tilt the grid into an isometric view through IsoProjection for tabletop games — for cards we keep it flat and top-down.) Step 1 — A card-table scene Pick New scene → Board . You get a Board (tile) layer for the table surface and a Pieces (entity) layer for the cards. Keeping the felt and the cards on separate layers matters: the felt is static grid data, while the cards are objects your rules deal, flip, and clear. A small grid (here 8×5) is all a card table needs. Step 2 — Lay the felt Select the Board layer,

In this article, I describe the challenges and the design of a React Native real-time mobile beat-aligned playback system for iOS and Android. The system combines personalization with low-latency, and seamless navigation and was the result of careful analysis and experimentation to address strict mobile and network constraints as well as meet user expectations. By Vladyslav Melnychenko

Android Bench is evolving, and developers can help guide that process.

The help button is the most important button in your delivery app that your QA team almost never...

Google's new phones could feature glowing LEDs and higher price tags.

"It works on my test input" is the most dangerous sentence in on-device AI development. I typed that sentence - or some version of it - a dozen times while building Redacto, our on-device PII redaction app running Gemma 4 E2B on a Samsung Galaxy S25 Ultra. The model would redact a patient name from a clinical note, I would nod, and I would move on. Then I would hand the phone to a teammate, they would type a police report, and the model would redact the suspect description instead of the victim name. The problem is not the model. The problem is that manual spot-checking is not validation. You are testing a single input against your own expectations, with all the confirmation bias that entails. When you have five domain modes (HIPAA, Financial, Tactical, Journalism, Field Service), three difficulty levels, and two candidate models, you need something systematic. You need a benchmark suite. This post covers how I built one - from dataset curation to scoring methodology to on-device infrastructure - for a hackathon app running entirely on a phone. No cloud. No API calls. No data leaving the device. Why Not Use an Existing Framework? The LLM evaluation space has mature tools. EleutherAI's lm-eval-harness is the community standard for evaluating language models against academic benchmarks like MMLU, HellaSwag, and ARC. Stanford's HELM (Holistic Evaluation of Language Models) provides a multi-metric evaluation framework with standardized scenarios. Google's BIG-bench offers hundreds of tasks for probing specific capabilities. These frameworks are excellent for what they do. They are also completely wrong for this problem, for three reasons. First, they assume server-side inference. lm-eval-harness expects to call a model through an API or load it in PyTorch on a GPU server. Redacto's model runs on a Qualcomm Hexagon NPU inside a phone. There is no Python runtime, no HuggingFace tokenizer at evaluation time, no way to hook into the framework's inference loop. Second, their

I fine-tuned Gemma 4 E2B. The adapter merged cleanly. The export to .litertlm completed without errors. I pushed the model to my phone, initialized the engine, and everything looked green. Then I tried to create a conversation and got this: Failed to apply template: unknown method: map has no method named get (in template:238) No model loading failure. No quantization error. The model initialized, the tokenizer loaded, and then the runtime choked on a Jinja template feature it does not support. This failure only surfaces when you actually try to run inference, not when you load the model. If you are demoing at a hackathon, this is the worst possible time to discover a compatibility issue. I hit this exact bug while building Redacto, a zero-trust PII redaction app that runs Gemma 4 E2B entirely on-device. This post walks through the full fine-tune-to-deploy pipeline: how to QLoRA a model on Colab, export it for LiteRT-LM, and avoid the undocumented template trap that will block your deployment. The Full Pipeline Here is what the fine-tune-to-deploy pipeline looks like end to end: HuggingFace base weights -> QLoRA fine-tune (Colab) -> Merge adapter into base -> Patch chat template <-- the step nobody tells you about -> Quantize + export to .litertlm -> Push to device Each stage has its own failure modes. The template patch step is the one that was undocumented at the time, and it is the one that will cost you hours if you do not know it exists. A note on framing before we dig in: this was an under-resourced fine-tune. I trained on 3,000 of the 400,000 samples in the ai4privacy/pii-masking-400k dataset for a single epoch, and the label format did not fully match what Redacto expected downstream. The point of this post is not the fine-tune's accuracy - it is the deployment mechanics I had to work through to get any fine-tuned model onto the device at all. Step 1: QLoRA Fine-Tuning on Colab QLoRA (Quantized Low-Rank Adaptation) lets you fine-tune a quantized model by tra