标签：#Android

Google's June Android feature drop includes more scam detection, more AirDrop, and yes, more AI.

As people increasingly refuse to answer calls from unknown numbers, scammers are shifting their tactics by spoofing trusted phone numbers and using AI deepfake technology to sound like authority figures, family members, or employers.

Google is launching a new feature for its Phone app that aims to protect you from AI impersonation scams. Now, when you receive a call from a scammer that appears to be coming from the same number as one of your contacts, Phone by Google will flag the call as suspicious so you can hang […]

All tests run on an 8-year-old MacBook Air. You're transferring a batch of large files over MTP. The first one flies at 45 MB/s. Then the second file starts — and you're at 30 MB/s. The third is slower still. Nothing changed. Same cable, same device, same app. So what's happening? The Cause Is in the Protocol Itself Between every file, MTP requires a full negotiation cycle — SendObjectInfo followed by SendObject . This isn't an implementation detail you can optimize away. It's how MTP works. During that gap, a few things happen in sequence: The Android device's flash controller is still committing the previous file to storage The USB pipe is flushed and re-established for the next object The device's MTP stack is processing metadata before it's ready to receive data again The result is a speed dip at every file boundary. The longer the previous file, the longer the device needs to catch up. What I Tried Building HiyokoMTP, I went through the obvious candidates: Tokio thread pool exhaustion — sync Read/Write calls blocking async threads were a real issue. Fixing it improved overall stability, but didn't eliminate the inter-file dip. Chunk size tuning — adjusting the USB bulk transfer buffer (up to 4 MB per chunk) helped peak throughput, but not the boundary behavior. Intentional cooldown between files — adding a short pause actually helped in some cases, giving the device's flash controller time to breathe before the next transfer starts. Why It Can't Be Fully Fixed The inter-file overhead is structural. MTP was designed as a stateful, command-response protocol — not a streaming pipeline. Every file is a discrete transaction with its own negotiation. There's no mechanism to pre-stage the next file while the current one is still writing. Non-async bulk transfer pipelining (similar to io_uring or Zero Copy USB) could theoretically reduce this, but it would require deep nusb-level changes and device-side support that most Android MTP stacks don't expose. MTP vs ADB: A F

Most QR scanner libraries for React Native share the same problems — they're unmaintained, they don't support the New Architecture, or they pull in a full camera SDK for what is a single-feature module. I wanted something lean, production-grade, and built the right way. So I built it. This is react-native-qr-camera-pro — a QR and barcode scanner for React Native built entirely with native code. No JavaScript frame processing. No unnecessary dependencies. Swift on iOS, Kotlin on Android, TurboModules and Fabric throughout. Why Native-Only? The common alternative is running frame analysis in JavaScript — grabbing frames via a JS-accessible camera API and running a WASM or JS barcode decoder on them. It works, but it puts real pressure on the JS thread and limits your frame rate. With native-only processing: iOS uses AVCaptureMetadataOutput — Apple's own pipeline for detecting machine-readable codes. Frames are never copied to user space; the kernel hands off a reference to the same buffer. Android uses CameraX ImageAnalysis + ML Kit — Google's on-device barcode scanner backed by hardware-accelerated inference where available. The JS bridge is touched at most once every 500ms to deliver a result. Everything else stays native. Architecture The module is three layers: Architecture The module is three layers, each with a single responsibility: Layer What it does JavaScript / TypeScript Public API — QrCameraProView , startScanning() , stopScanning() , toggleTorch() , useBarcodeScanner() , useCameraError() Native Bridge (TurboModules + Fabric) Type-safe JSI communication between JS and native. Codegen spec drives both the iOS C++ adapter and the Android Kotlin stub. Native Platform (iOS + Android) All camera and barcode logic. AVFoundation on iOS, CameraX + ML Kit on Android. Zero JS involvement in frame processing. iOS (Swift) Class Responsibility QrCameraProSwift Owns the AVCaptureSession lifecycle BarcodeThrottler Throttle + dedup logic BarcodeTypeMapper Maps AVMetadataO

If you’ve been doing Android development for a while, you know the drill. You start a new project,...

Motorola says that recently discovered behavior, which saw some of its phones sending users to an affiliate tracking website before opening the Amazon app, was "unintended" and has been "promptly corrected." The company didn't explain how the error was introduced in the first place. "Recently, Motorola acted quickly to resolve an issue that was identified, […]