标签：#Android

Aptoide has brought its games store back to Google Play after more than a decade, as court-ordered changes open Android to competing app stores.

Following the latest twist in Google's legal battles with Epic, US Android users are now able to open Google's Play Store and download a third-party digital store with its own selection of apps. Aptoide, a store specializing in mobile games, is the first to become available. Third-party app stores have always been available on Android, […]

TCL’s hybrid tablet-digital notebook tries to be the best of both worlds, and it mostly succeeds.

I Turned an Android Phone Into a No-Root Cybersecurity Learning Workspace Most people don't look at an Android phone and think: "This could be a practical Linux, Python, networking, and cybersecurity learning environment." Usually, the assumption is that serious technical learning requires a laptop, a virtual machine, or dedicated hardware. I wanted to see how far I could push the opposite idea. What if the Android phone you already own could become a practical learning workspace without root access? That experiment eventually became DedSec . DedSec is a free and open-source project built around Android and Termux. Its goal is not simply to install a large collection of tools. The goal is to create an environment where someone can actually learn how the pieces fit together. Repository: https://github.com/dedsec1121fk/DedSec Official website: https://ded-sec.space/ Why Android? Android devices are incredibly capable machines. Even an older phone can provide: a Linux-like command-line environment through Termux Python Git package management networking utilities file manipulation scripting automation local development workflows And you can do a surprising amount without root access. The limitation isn't always the hardware. A bigger limitation is often knowing what to do with it. You can install dozens of packages, copy commands from tutorials, and still not understand what is actually happening underneath. That was one of the problems I wanted DedSec to address. More Than a Collection of Scripts There are plenty of repositories containing security scripts. That wasn't enough for what I wanted to build. Installing a tool doesn't automatically teach you: what problem the tool solves when you should use it what its output means what layer of the system is failing how networking concepts connect together why a command works why another command fails So DedSec gradually became an ecosystem rather than just a scripts directory. The project connects several things together:

I've always found reading hard. Long documents slide off my attention, and I lose my place constantly. What I really wanted was something that would read to me and show me the words as it went — so my eyes and ears stayed in sync. Nothing did exactly that, so I built it. It's called ReadAloud , it's on Google Play, and this post is the "why" and the interesting bits of the "how." The moment it became real The first person I showed a rough build to was my Sister, Praise . She'd come to town to officiate a Women's Premier League match at Auntie Aku Astro Turf Park, and I pulled out my phone between everything else. She watched a paragraph read itself aloud with each word lighting up and got genuinely excited — that was the push I needed. She became tester #1. My colleague Reggie became tester #2. Between them they found the rough edges I'd stopped seeing, and the app settled into something stable. What it is A text-to-speech reader for PDFs, EPUB, DOCX, plain text and web articles . It reads aloud in natural voices, highlights each word as it speaks , and auto-scrolls to follow along. There's offline listening, English/French/Spanish, speed-reading (RSVP), a vocabulary builder, and reading stats. The stack: Kotlin, Jetpack Compose + Material 3, MVVM + Clean Architecture, Hilt, Room, DataStore, WorkManager , minSdk 26 . Now the parts that were actually interesting to build. 1. Word-by-word highlighting This is the whole product, so it had to be right. On-device voices are easy — Android's TextToSpeech gives you onRangeStart (API 26+), which fires per spoken range: override fun onRangeStart ( utteranceId : String , start : Int , end : Int , frame : Int ) { // highlight the substring [start, end) in the reader _currentRange . value = start to end } The catch: the natural cloud voices people actually want don't emit onRangeStart . So for cloud synthesis I wrap each word in an SSML <mark> and ask Google Cloud TTS to return timepoints : <speak><mark name= "w0" /> Every <mar

A build note from Horizon Software , a one-person Android studio. WanderWallet is a travel budget app, and the whole thing runs on the phone: no account, no backend, no cloud. Here's how the parts that look like they need a server actually work without one. The one constraint that shaped everything WanderWallet has a single non-negotiable rule: it has to work with no signal. You're three countries into a trip, your phone's in airplane mode to dodge roaming charges, and you still need to know whether you're on budget. That one requirement quietly makes most of the architectural decisions for you — no login, no server round-trips, and every feature that would normally lean on a cloud API has to earn its keep another way. The stack is deliberately boring: .NET MAUI (Android-first), CommunityToolkit.Mvvm , sqlite-net-pcl for storage, and SkiaSharp for anything I draw myself. Everything the app records lives in a local SQLite database on the device and nowhere else. "Backup" is a file you export and keep — there's no server to back up to . The three features people assume need a backend turned out to be the most interesting to build, precisely because they don't. 1. Currency conversion that survives airplane mode A travel budget app that can't convert currencies offline is useless at exactly the moment you need it. So rates aren't fetched on demand. Whenever the app happens to have a connection it refreshes exchange rates for ~155 currencies and caches the whole table locally . From then on every conversion is local arithmetic — a connection only ever buys you a fresher table, never the ability to convert. The design decision that took me longest to get right: capture the conversion immutably, at entry time. Each expense stores the original amount, its original currency, the converted home-currency amount, and the exact rate used — and that rate is never recalculated: public class Expense { public double Amount { get ; set ; } // in OriginalCurrency public string Origina

Introduction: Moving Beyond Traditional XML Layouts Android development has evolved significantly. The days of managing complex XML layouts with findViewById or basic View Binding are fading fast. Modern Android development demands clean architecture, reactive state management, and declarative UI tools like Jetpack Compose. In this deep dive, we will explore how to structure scalable, maintainable, and testable native Android applications using the Model-View-ViewModel (MVVM) architecture alongside Jetpack Compose. Why MVVM with Jetpack Compose? The Model-View-ViewModel pattern provides a clean separation of concerns between your business logic and presentation layer: Model: Handles data sources (Local database via Room, Remote API calls via Retrofit). ViewModel: Preserves state during configuration changes, holds business logic, and exposes state observables. View (Compose): Declarative UI composables that automatically re-compose (re-render) when the underlying state changes. Using Jetpack Compose alongside MVVM eliminates UI boilerplate code, avoids memory leaks associated with traditional views, and simplifies dynamic UI state management. Layered Architecture Overview The Data Layer The data layer is responsible for retrieving and storing data from external or local sources. It uses the Repository Pattern to expose a clean API to the rest of the app: Kotlin interface UserRepository { suspend fun getUserProfile(userId: String): Result } class UserRepositoryImpl( private val apiService: ApiService, private val userDao: UserDao ) : UserRepository { override suspend fun getUserProfile(userId: String): Result { // Handle network requests, local caching, and fallback strategies } } The Domain Layer (Optional for Large Apps) Contains Use Cases (Interactors) that encapsulate single pieces of business logic. This ensures that ViewModels remain lightweight and focused strictly on managing UI state. The UI Layer (ViewModel + Composables) The UI layer reads state exposed by

Whether you’re charging overnight at home or on the go, these are the fastest, most dependable Android chargers we’ve tested.

Sunbird Messaging is back on the Google Play Store, offering Android users blue bubble privileges in iMessage complete with reactions and high quality videos for $2.99 a month. Apple and Google have made cross platform messaging better in recent years with support for RCS, but Android users can still cause issues in iMessage group chats, […]

Google Assistant's days have been numbered ever since Gemini arrived on the scene, and its time is now up. Google has announced that it will be removing access to Assistant on Android phones and tablets, along with paired devices like smartwatches or headphones, from September 4th. The announcement came in an email apparently sent to […]

The Silent Disruptor The silence in the room was absolute, broken only by the rhythmic scraping of pens on paper during a high-stakes meeting. Then, it happened. My pocket erupted into a frantic, brassy ringtone that seemed to last an eternity before I could fumble to silence it. My face turned crimson as the room’s focus shifted from the presentation to my vibrating trouser pocket. I had remembered to check my calendar, but I had completely forgotten to toggle my phone to silent mode. That moment of pure, concentrated embarrassment was the catalyst for me building Muffle. The Friction of Manual Control We live in an age of automation, yet our phones—the very devices meant to assist us—remain stubbornly manual when it comes to basic social etiquette. Every day, millions of people walk into mosques for prayer, classrooms for lectures, or medical offices for consultations, and every day, a percentage of them forget to silence their devices. This isn't just a minor annoyance; it is a persistent source of social friction. Before I started building Muffle, I looked for existing solutions. Most apps were either bloated with unnecessary permissions, required invasive cloud accounts, or simply failed to trigger at the right time. The fundamental problem wasn't just the lack of features like GPS-based prayer times or calendar-specific automation; it was the lack of reliability. If an automation app fails once, the user loses trust in it forever. If I am in a meeting, I cannot afford for the app to 'sleep' because the system decided to save battery at the expense of my configured routine. I needed something that could handle these state changes consistently, regardless of whether the phone was in my pocket, sitting on a desk, or buried in a bag. Architecting for Reliability When I began writing the core logic for Muffle, I immediately hit the wall that every Android developer eventually faces: Doze Mode. Android’s aggressive power management is designed to preserve battery by

PR #5421 adds RichTextComponent , a read-only component for formatted application text. It supports headings, inline styles, lists, links, and images without embedding a web view. 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 . A SpanLabel applies one style to wrapped text. A BrowserComponent renders a complete web page. RichTextComponent covers formatted document content between those two cases and participates in ordinary Codename One layout. Rich text inside a scrollable container A common screen mixes formatted text with buttons, images, forms, and other Codename One components inside one scrollable container. A BrowserComponent is a poor fit for that layout because it owns a rectangular native surface and its own page viewport. The browser's document height does not naturally become the height of a child inside the parent Codename One layout. RichTextComponent measures wrapped runs for the width it receives and reports the corresponding height. In the default SizeMode.SHRINK , it behaves like a SpanLabel : the parent container scrolls the rich text together with the surrounding components. SizeMode.SCROLL is available when the rich text should keep an assigned height and scroll its own content. The read-only view and editor agree on paragraph attributes, inline styles, links, image runs, and wrapping because they do not maintain competing renderers. Supply the format you already have HTML is not the only input: RichTextComponent view = new RichTextComponent (); view . setMarkdown ( "# Trip summary\n\n" + "Departs **09:40**, arrives *11:15*. " + "See the [itinerary](app://itinerary).\n\n" + "- Window seat\n" + "- Carry-on only" ); form . add ( view ); setContent(...) accepts RichTextFormat.HTML , MARKDOWN , ASCIIDOC , or RTF . The model covers headings, emphasis, inline code, links, images, lists, quotes, literal blocks, p

PR #5386 adds a pure Codename One text-editing path. EditField , RichTextArea , and CodeEditor can now keep their document, selection, and painting inside the lightweight UI while each port supplies keyboard and input-method events. 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 . Text input must handle virtual keyboards, hardware keys, autocorrect, dictation, marked text from an input method editor, bidirectional text, selection, clipboard formats, and accessibility geometry. Codename One traditionally delegates that work to a native platform field placed over the lightweight component during editing. The overlay remains the default for TextField and TextArea . It can create a small visual jump, and it cannot participate in lightweight painting for syntax highlights, rich runs, masks, inline images, or a custom selection model. The port sends text operations instead of key codes A soft keyboard does not type keys. It commits words, replaces a marked composition range, deletes text around the caret, and changes selection. Dictation may insert a sentence without producing one key event. The new TextInputClient contract models those operations: commitText(...) inserts final text. setComposingText(...) replaces the active marked-text range. finishComposing() accepts that range. deleteSurroundingText(...) implements virtual-keyboard deletion. onKeyCommand(...) carries navigation, selection, clipboard, undo, and redo. Geometry queries locate the caret and selection for candidate windows and accessibility. All offsets use UTF-16 indices. That matches Java String , Android Editable , and Apple string APIs. The document normalizes line endings before it updates selection, undo history, formatting runs, or the state returned to the platform. The port still owns the keyboard session. Codename One owns the document and what appears on scr

Building Three Privacy-First Mini Apps That Feel Like Standalone Products PureHub is an open-source collection of 22 free, ad-free mini apps. This release focuses on a simple product question: can a mini app inside a hub still feel dependable, focused, and complete? QR Studio The web scanner now supports a live camera and uploaded images through local decoding. Scan history stays in local storage, URL results receive basic safety checks, and supported cameras expose a torch control. Android uses CameraX and ML Kit with explicit scanner cleanup, duplicate-result protection, and copy, open, and share actions. Zen Pomodoro A one-second decrement loop drifts when a tab sleeps. The new timer stores a target time and recalculates the remaining duration, so switching tabs or waking a device no longer quietly extends a session. Weekly sessions and focused minutes remain on-device. Android uses a monotonic clock for the same reason. Zen Breath The breathing guide now includes Calm 4-6, Box 4-4-4-4, and Relax 4-7-8 patterns, controlled sessions, cycle totals, and accessible motion behavior. Nothing requires an account. Standalone safety for all 22 tools Each mini app now has a runtime contract describing its local storage namespace, offline behavior, and device capabilities. A per-tool error boundary prevents one failure from taking down the rest of PureHub. The three flagship tools also load as independent chunks and are available as PWA and Android launcher shortcuts. What happens next The Command Center will compare 14 days of anonymous aggregate opens, helpful votes, and shares. The strongest useful-use signal - not raw views - will choose the next deep-polish target. Try the release at PureHub or inspect the source on GitHub .

It happened during a medical appointment. I was sitting in the quiet waiting room, my thoughts occupied by the upcoming consultation, when my phone erupted with a loud, aggressive ringtone. The entire room turned to look at me, and I fumbled to silence it, accidentally hitting the volume up button instead of the mute toggle in my panic. I felt that specific, burning embarrassment that comes from being the person who disrupts a quiet space. I realized then that I had spent years writing code for others, yet I couldn't solve my own basic problem of managing my phone's profile. We live in a world of constant notifications and persistent demands on our attention. The real friction isn't just that phones ring; it's that we are expected to remember to manually toggle settings in a dozen different contexts every single day. Whether it is a classroom, a house of worship, or a professional meeting, the human element of remembering to flip a switch is the point of failure. I wanted an app that handled this silently, without me having to open an interface or even think about the current state of my device. I needed a system that functioned as an extension of my environment rather than an additional task. Building Muffle required me to confront the reality of modern Android background execution. Initially, I thought a simple BroadcastReceiver listening for time changes or geofence triggers would suffice. I was wrong. As soon as the phone entered Doze mode—the power-saving state introduced in Android 6.0—my triggers would either be delayed significantly or killed entirely by the system’s restrictive task scheduler. I had to architect a solution that could survive these aggressive optimizations while remaining battery-efficient. The core of the application resides in a ForegroundService that maintains a persistent notification. While many developers avoid these because of the UI footprint, it is the only way to signal to the OS that your process is performing an essential, user-v

Every design team eventually ships a beautiful off-white, off-blue, or off-anything background… and then opens the app on a $120 phone and watches it turn dirty gray . Same hex, same build. This post explains why, and gives you a small formula to convert any tint you've chosen into one that survives budget panels. Why subtle tints die on cheap screens Four panel-level failure modes, all common in the budget tier: 1. Weak gamut coverage. Entry-level LCDs cover only a fraction of sRGB — independent panel measurements routinely land in the 55–70% range, with large per-color error. A low-chroma tint simply doesn't have the budget to survive that compression. 2. Cold white points. sRGB assumes a D65 white (6500K). Budget modules commonly ship visibly cooler — high-6000s to 9000K+ — because blue-ish whites look "brighter" in a store. That blue cast is spread across the entire grayscale, and its magnitude is comparable to a subtle warm tint. Net result: the panel can cancel your background color outright. 3. Stretched gamuts on budget AMOLED. The opposite failure: "vivid" default modes stretch sRGB content across the panel's wider native gamut. Your quiet tint renders at roughly double saturation and suddenly has an opinion. 4. Banding. Many cheap panels are 6-bit + FRC. Soft near-white gradients develop visible steps, which makes barely-different surface colors look like rendering bugs. The 4% rule You don't need a colorimeter to know if you're at risk. Use channel spread — the distance between your highest and lowest RGB channel — as a chroma proxy: spread = max(R, G, B) − min(R, G, B) If spread is under ~10 of 255 (≈4%) , your tint is inside a cheap panel's error bar. It may render as intended, as gray, or as tinted the other direction — you don't get a vote. (Quick check on any hex: two outer pairs of digits within ~0x0A of each other = you're in the danger zone.) Why 4%? Because that's the same order of magnitude as the grayscale tint produced by a few-hundred-kelvin

We just bumped four dependencies in the app. Here's what each one brings. implementation 'androidx.constraintlayout:constraintlayout:2.2.2' implementation platform ( 'com.google.firebase:firebase-bom:34.17.0' ) implementation 'io.intercom.android:intercom-sdk:18.6.0' implementation 'com.auth0.android:auth0:4.0.1' ConstraintLayout 2.2.2 The library's in maintenance mode now — Google's steering everyone toward Compose for new UI — so releases here are small, focused patches. This one carries forward a binary compatibility fix in constraintlayout-core that landed in the 2.2.x line. Firebase BoM 34.17.0 The BoM pins compatible versions across every Firebase library you pull in. This release lands close behind: Firebase AI Logic (17.14.0) — new factory methods exposing thoughtSignature / isThought on response parts, plus automatic function calling for LiveGenerativeModel Authentication (24.2.0) — fixed an auth timeout on dual-stack Wi-Fi, where long IPv6 timeouts were blocking IPv4 fallback Cloud Firestore (26.4.1) — now caches documents over 1MB by chunk-reading from local SQLite; fixed a debug-logging OOM caused by large payloads Cloud Messaging (25.1.1) — fixed a re-registration bug tied to Firebase installation ID changes Crashlytics (20.1.0) — on API 37+, fatal event reports now carry OOM/anomaly context from the ProfilingManager API Firebase Installations (19.1.2) — internal storage moved from SharedPreferences to DataStore Performance Monitoring (22.0.6) — fixed _app_start traces getting incorrectly suppressed on API 34+ SQL Connect (17.3.2) — several fixes to realtime query subscriptions around auth-token refresh and expiry Intercom Android SDK 18.6.0 Pinch-to-zoom, double-tap-to-zoom, and pan on full-screen image attachments Fixed an ANR during Intercom.initialize() caused by Keystore and persisted-identity reads blocking the calling thread Fixed the keyboard covering form fields in Canvas Kit sheets — IME insets are now handled correctly Fixed a crash from a nu

I compiled the rules engine of a shipped Android game to the browser. Same Java, two compilers. Then I checked whether the two agreed. They did not — and the test I already had for exactly this had been green the whole time. The same command twice: green against the current engine, then against the committed recording of the broken build. Play it as a terminal session if you want to select the text. The setup The rules live in one module with no Android on its classpath, which is what let me compile them a second time with TeaVM and run the same logic on a canvas in a browser tab. A seeded run should be reproducible. Give the engine seed 42 and a fixed sequence of inputs, and you should get the same game every time — that is what makes a run replayable and two builds comparable. Here is what I actually got, same seed, same inputs: JVM browser first obstacle x, frame 60 405.426 304.426 still alive at frame 360 yes no final score 9 6 Not a rounding difference. A different game. The cause is boring. The test failure is not. GameEngine used java.util.Random . Its algorithm is specified down to the constants — you can read the exact linear congruential generator in the Javadoc. So a seed ought to name exactly one sequence. But my code was not running that algorithm. It was running whichever implementation the runtime supplied , and TeaVM's is not the JVM's. The specification describes what java.util.Random does; it does not force a foreign runtime's reimplementation to match. The fix took ten minutes: write the LCG out longhand so both builds execute the same arithmetic instead of trusting that they will. The interesting part is the test. The test that could not have caught it I had a test called theSameSeedProducesTheSameRun . It ran the engine twice, with the same seed, and asserted the results matched. It passed on every commit, including every commit during which the browser build was playing a different game. It had to pass. It runs the engine twice in the same runt

If you’re looking to cut back on screen time and get a little more active, here’s a roundup of the apps that might help.