# adb Published articles for adb. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introducing Fast and Reliable Wireless Debugging with Android Debug Bridge (ADB) Wi-Fi 2.0 DevFeed: [Introducing Fast and Reliable Wireless Debugging with Android Debug Bridge (ADB) Wi-Fi 2.0]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-09-09T16:00:00Z Content type: release Language: en Sources: [Android Developers Blog]() Topics: [ADB Wi-Fi 2.0](), [Wireless Debugging](), [Android](), [Android Studio](), [Wi-Fi](), [SDK]() Tags: [adb](), [adb-wi-fi-2-0](), [android](), [android-studio](), [debugging](), [network](), [sdk](), [wi-fi](), [wireless-debugging]() ### AI overview Android introduces ADB Wi-Fi 2.0, a wireless debugging update that reworks the adb server, adbd daemon, and Android Studio integration. It adds a new mDNS-based server stack, smarter handling of untrusted networks, and improved device discoverability. The article reports a 32% improvement in auto-connection success rates and a 66% increase in connection speeds for 90% of connections. ### Source excerpt Posted by Steven Jenkins, Product Manager, Sherif Eid, Senior Software Engineer, and Fabien Sanglard, Staff Software Engineer, Android Studio Wireless debugging on Android is now faster, more reliable, and easier to set up than ever. With ADB Wi-Fi 2.0, we've introduced a new server stack and smarter network handling to directly address developer feedback around usability gaps. How ADB Wi-Fi 2.0 Improves Wireless Debugging To ensure ADB Wi-Fi 2.0 is even more reliable, we reworked all three core components of the stack: the adb server, the adbd daemon, and Android Studio. Here are the new features: A new server stack (adb): Previously, wireless device connections would sever when network configurations changed or devices were turned off. This meant that connections would drop for common occurrences. With our new mDNS stack, we've replaced both Bonjour and legacy mDNS so that your wireless devices more reliably stay connected as you go about your day. Smarter network handling (adbd): Previously, the workstation's mDNS client would sporadically drop services. Now, the daemon automatically turns off ADB Wi-Fi when it detects an untrusted network and re-enables itself once running on a user-allowed network. Improved discoverability in Android Studio: Previously, Wi-Fi pairing was difficult to find. Now, you simply enable wireless debugging on your phone and it will show in Android Studio's Device Manager. With ADB Wi-Fi 2.0, auto-connection success rates improved by 32% and connection speeds increased by 66% for 90% of connections. Getting Started You can use ADB Wi-Fi 2.0 on your phone, tablet, Wear OS, and TV. Here's how to get started: Update to Android 17, Android SDK Platform-Tools 37.0.0, and Android Studio Quail 3 or later. Ensure your workstation and your Android device are connected to the same Wi-Fi network. On your device, navigate to Developer Options and enable Wireless debugging. Open the Android Studio Device Manager and click the pair over Wi-Fi icon. Sc ## Emulator control for adaptive app development DevFeed: [Emulator control for adaptive app development]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-31T16:00:00Z Content type: tutorial Language: en Sources: [Android Developers Blog]() Topics: [Android](), [Emulator](), [Command-line interface](), [Large Screen](), [Android Studio](), [Terminal](), [Development]() Tags: [adaptive](), [adb](), [android](), [android-studio](), [app-development](), [command-line](), [commands](), [console](), [development](), [devices](), [emulator](), [layout](), [verify](), [workflow]() ### AI overview A tutorial on using Android Emulator console commands through adb emu to test adaptive app behavior. It covers folding and unfolding devices, rotating them, simulating physical postures, and resizing displays from the terminal. ### Source excerpt Posted by Rob Orgiu, Developer Relations Engineer, Adaptive Apps, Android Adaptive app development is fundamental on Android, but making sure everything looks good and every feature works the way it should require multiple tests on multiple devices. Or does it? Well, yes... and no! While Android Studio is bundled with the Resizable Emulator to let you test layouts manually, there's a faster, more streamlined way to control form factors directly from your terminal. By leveraging fire-and-forget console commands using the adb emu shortcut, you can execute commands that immediately return control to your invoking shell. If you have multiple emulators running at the same time, you can target a specific virtual device by passing in the shortcut's serial: adb -s emu First things first: Fold and unfold To test foldable-specific user journeys and layout configurations, you can fold and unfold your emulated device programmatically. adb emu fold If your foldable emulator is unfolded, you can fold it to display its smaller screen configuration, powering on the (virtual) external display. To unfold the emulator and power on the internal display, simply run: adb emu unfold Now, you can instantly verify that your app preserves its state and that layouts appear exactly as they should on different display sizes. Rotation, rotation, rotation Correctly handling orientation changes is a cornerstone of adaptive app development. You can trigger device rotations programmatically to test how well your app handles configuration changes, including state restoration. The following command rotates the device 90° clockwise: adb emu rotate Simulating postures using sensors What about placing the emulator into a specific physical posture, like tabletop mode? The easiest approach is querying for the number of available positions with . First, list all available sensors and their current status: adb emu posture This returns a list of positions similar to the following: ## Preparing your app for broader memory limits DevFeed: [Preparing your app for broader memory limits]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-19T19:00:00Z Content type: tutorial Language: en Sources: [Android Developers Blog]() Topics: [Android](), [Optimization](), [User Experience](), [Memory Leaks](), [memory price increases]() Tags: [adb](), [android](), [memory-leaks](), [memory-optimization](), [optimization](), [user-experience](), [vitals]() ### AI overview This Android Developers article explains how Android 17 per-app memory limits are expanding beyond Pixel devices across a range of RAM configurations. It describes the effects of exceeding memory budgets, including zRAM swapping, CPU overhead, UI jank, throttling, and possible process termination, and outlines ways to measure and optimize app memory usage. ### Source excerpt Posted by Blair Harmon, Director of Product Management, Android Platform A great user experience is central to Android's mission, and delivering on that promise requires keeping devices fast, responsive, and reliable. This is why memory optimization is more critical than ever. Across the ecosystem, new devices are maintaining or even decreasing their physical memory capacity in response to memory price increases, yet users continue to expect the same seamless, high-performance app experience. In Android 17, we introduced per-app memory limits, starting with Pixel devices, to help protect the overall user experience from applications using excess memory and causing system-wide slowdowns. Over the coming year, an increasing number of manufacturers will leverage the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices. If your app exceeds these limits, it will be slowed down and may be terminated. Optimizing your app's memory footprint is essential to preventing OS throttling and maintaining a seamless user experience. In this post, we'll explore how these limits work under the hood, how to measure your memory footprint using new Android vitals metrics, and actionable steps to optimize your app or game. Understanding Memory Limits When your app exceeds its memory budget, Android takes progressive action to protect device responsiveness: zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM (compressed RAM). While zRAM prevents immediate eviction, compressing and decompressing pages adds CPU overhead, which can result in noticeable UI jank and experience slowdowns. Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system. To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo. If the system applied a limit, the ## Android Journey Tests with Gemini: CI Setup & 11-Week Review DevFeed: [Android Journey Tests with Gemini: CI Setup & 11-Week Review]() Original publisher: [Read original article]() Author: Swapnil Gupta Published: 2026-06-19T03:27:13Z Content type: opinion Language: en Sources: [REA Group]() Topics: [Android](), [Artificial Intelligence](), [ui-testing](), [CI/CD](), [Android Studio](), [adb]() Tags: [adb](), [android](), [android-studio](), [ci](), [firebase](), [gemini](), [qa-engineer](), [quality](), [tech](), [tests]() ### AI overview An 11-week experiment evaluated Android Journeys powered by Gemini for AI-driven UI testing in REA Group's production Android app and CI infrastructure. The tests generally remained resilient through UI changes, but CI setup took eight weeks, Firebase Test Lab was unsupported, and manual QA hours did not decrease. The team rated the experience 8.75 out of 10 and voted to continue. ### Source excerpt Writing AI-powered UI tests took minutes. Getting them on CI took eight weeks. Here's what we learned after 11 weeks with Android Journeys and Gemini. ## Give Your Screenshots a Sound -- a Stream Deck Button That Dings When the Image Is on the Clipboard DevFeed: [Give Your Screenshots a Sound -- a Stream Deck Button That Dings When the Image Is on the Clipboard]() Original publisher: [Read original article]() Author: Ivan Morgillo Published: 2026-06-17T12:30:00Z Content type: tutorial Language: en Sources: [Ivan Morgillo]() Topics: [Large Screen](), [Wireless Debugging](), [Google]() Tags: [adb](), [display](), [screenshot](), [sound]() ### AI overview The article describes a Stream Deck workflow that captures Android phone screenshots to the clipboard and plays a sound when the pipeline completes. It explains that foldable phones can emit display-selection warnings into the image stream, corrupting the PNG, and discusses capturing the active display instead of hardcoding a display ID. ### Source excerpt A Stream Deck button that plays a ding the instant a phone screenshot lands in the clipboard -- no more counting to three. Plus a foldable multi-display gotcha (and the fix), with a hat tip to Roberto Orgiu. ## Android ❤ Gemini CLI - tech debt detection Code Maat skill DevFeed: [Android ❤ Gemini CLI - tech debt detection Code Maat skill]() Original publisher: [Read original article]() Published: 2026-03-08T00:00:00Z Content type: tutorial Language: en Sources: [maiatoday]() Topics: [Android](), [Tech Debt](), [Agent Skill](), [Command-line interface](), [Artificial Intelligence](), [Code](), [Git](), [Android Studio]() Tags: [adb](), [agent-skill](), [ai](), [android](), [cli](), [code](), [code-maat](), [command-line](), [gemini](), [gemini-cli](), [git](), [tech-debt]() ### AI overview This tutorial explores using Gemini CLI and an agent skill with Code Maat to identify technical-debt hotspots in the Habitica Android codebase. It describes using Git history to analyze file churn and logical coupling, and compares the approach with the Gemini Agent in Android Studio. ### Source excerpt Introduction What AI tools work for building Android apps? I am exploring some variations. In this post I will look at Gemini CLI, tech debt detection with a skill using Code Maat and how this compares with the Agent of Gemini in Android Studio. I am not starting with a new project. What if you have an existing codebase and you want to find the best place to tackle some tech debt that will make a difference for everyone. The sample codebase is the Habitica app, which had its first commit in 2015. Rather than poking at the code in a random or an "intuitive" way or asking the AI questions, let's look at a more deterministic way to answer this question. Or rather, let's teach the agent to use some scripts to answer this question. The benefit of packaging this functionality in a skill is that you can create this specialisation and script usage in a skill that will be loaded lazily only when you need it. The theory - Code as Crime scene Adam Tornhill wrote a book, Your Code as a Crime Scene, that uses your git history and applies forensic science to figure out where the hotspots, logical coupling, churn and more can be found in your code base. He has a java tool called Code Maat that you can use to analyse this information. The problem is, it is a bit finicky to setup and run and I can never remember all the command line parameters for git or for the tool. The theory TLDR is if you can see which large files change often or which files always change together, you can see which parts of your code are brittle or are coupled. The added benefit is that this analysis is language neutral. So if you build an agent skill for this, it can be used on any codebase. Creating the Code Maat Skill What do we need the link to Code Maat optionally download the code-maat standalone jar and put it in ~/tools/code-maat.jar to speed up the first run Gemini CLI + authentication and API key if you have it the skill-creator skill - this is part of the Gemini CLI install the Habitica Android app ## Compose Stability Analyzer 0.7.0: Recomposition Cascade and Live Heatmap DevFeed: [Compose Stability Analyzer 0.7.0: Recomposition Cascade and Live Heatmap]() Original publisher: [Read original article]() Author: Jaewoong Eum Published: 2026-02-15T00:08:14Z Content type: tutorial Language: en Sources: [Stories by Jaewoong Eum on Medium]() Topics: [Jetpack Compose](), [Android Studio](), [Gradle](), [Code]() Tags: [adb](), [android](), [android-studio](), [compose](), [compose-stability](), [gradle](), [gradle-plugin](), [jetpack-compose](), [kotlin-multiplatform](), [monitoring](), [recomposition]() ### AI overview This article introduces Compose Stability Analyzer 0.7.0, focusing on its Recomposition Cascade Visualizer and Live Recomposition Heatmap. It explains how the heatmap uses ADB-connected device events to display runtime recomposition counts in Android Studio. ### Source excerpt Jetpack Compose's stability system determines whether a composable function can be skipped during recomposition. When all parameters are stable, Compose can compare them and skip the function entirely if nothing changed. When even one parameter is unstable, the composable must re-execute every time its parent recomposes. Understanding which composables are stable and which are not is the first step toward optimizing Compose performance, but it's not the whole picture. Compose Stability Analyzer has been providing real-time stability analysis directly in Android Studio through gutter icons, hover tooltips, inline hints, and code inspections. These features answer the question "is this composable stable?" at a glance. Version 0.7.0 goes further by answering two additional questions that static analysis alone cannot address: "what happens downstream when this composable recomposes?" and "which composables are actually recomposing the most on a real device?" In this article, you'll explore the two new features introduced in version 0.7.0: the Recomposition Cascade Visualizer and the Live Recomposition Heatmap. Live Recomposition Heatmap Static analysis tells you which composables could recompose unnecessarily. The Live Recomposition Heatmap tells you which ones actually are. It bridges runtime behavior with your IDE by reading @TraceRecomposition events from a connected device via ADB and displaying live recomposition counts directly above composable functions in the editor. To use the heatmap, you need the Compose Stability Analyzer Gradle plugin applied to your project, composable functions annotated with @TraceRecomposition, and logging enabled via ComposeStabilityAnalyzer.setEnabled(true) in your Application class. With those in place, open the Compose Stability Analyzer tool window and click the Start/Stop button in the title bar. If one device is connected, monitoring begins immediately. If multiple devices are connected, a picker popup lets you choose which one t ## Closing the AI Loop in Software Development DevFeed: [Closing the AI Loop in Software Development]() Original publisher: [Read original article]() Published: 2025-10-22T00:00:00Z Content type: opinion Language: en Sources: [Antonio Leiva]() Topics: [Artificial Intelligence](), [AI Development](), [Development](), [API](), [Code](), [Persistence](), [ui](), [adb](), [Chrome](), [MCP](), [Playwright](), [Prisma]() Tags: [adb](), [agent](), [ai](), [api](), [chrome](), [code](), [development](), [interface](), [openapi](), [persistence](), [playwright](), [schema](), [software](), [software-development]() ### AI overview The article argues that AI coding agents become more capable when they can access and interact with the full development environment. It recommends controlled access to the codebase, database, backend APIs, and user interface so agents can inspect data, verify API responses, test interfaces, and diagnose or fix issues. ### Source excerpt Everything Android, Kotlin and other random topics ## Maestro's Architecture for Simplifying Mobile Test Automation DevFeed: [Maestro's Architecture for Simplifying Mobile Test Automation]() Original publisher: [Read original article]() Author: Leland Takamine Published: 2025-09-25T00:00:00Z Content type: article Language: en Sources: [mobile.dev - Medium]() Topics: [Mobile](), [Testing](), [Test automation](), [YAML](), [Accessibility](), [Open Source](), [Command-line interface](), [Android]() Tags: [accessibility](), [adb](), [android](), [flutter](), [ionic](), [maestro](), [mobile](), [mobile-test-automation](), [open-source](), [react-native](), [test-automation](), [yaml]() ### AI overview The article explains Maestro's architecture for mobile test automation. It describes one-line installation without separate dependencies, drivers, or SDKs; a Kotlin implementation of the ADB protocol called dadb; self-installing mobile drivers; and support for native, React Native, Flutter, and Ionic applications through the device accessibility layer. ### Source excerpt Discover how Maestro is revolutionizing mobile test automation with zero setup, universal compatibility, and human-readable YAML syntax. ## Ready Layer One: Intro to the Model Context Protocol DevFeed: [Ready Layer One: Intro to the Model Context Protocol]() Original publisher: [Read original article]() Author: Matt McKenna Published: 2025-07-23T15:17:12Z Content type: tutorial Language: en Sources: [Matt McKenna]() Topics: [Model Context Protocol (MCP)](), [adb](), [Android](), [Kotlin](), [Artificial Intelligence](), [SDK]() Tags: [adb](), [agent](), [ai](), [android](), [code](), [kotlin](), [llm](), [mcp](), [mcp-server](), [model-context-protocol](), [permissions](), [sdk](), [tool]() ### AI overview A video introduction to the Model Context Protocol using the Kotlin SDK, with a demonstration of an AI agent controlling Android devices through ADB. It also covers building an ADB tool and automating device-permission tasks. ### Source excerpt Discover how the Model Context Protocol (MCP) connects AI to the real world. We'll explore the Model Context Protocol using the Kotlin SDK letting an Agent control Android devices with ADB! We'll live code a new ADB tool and demo how AI Agents and th... ## How to Input Unicode Characters in Maestro Android Tests: A Complete Workaround Guide DevFeed: [How to Input Unicode Characters in Maestro Android Tests: A Complete Workaround Guide]() Original publisher: [Read original article]() Author: Ishan Khanna Published: 2025-07-11T00:17:46Z Content type: tutorial Language: en Sources: [Ishan Khanna]() Topics: [Android](), [adb](), [HTTP](), [Flask]() Tags: [adb](), [android](), [automation](), [guide](), [javascript](), [maestro](), [mobile-test-automation](), [open-source](), [ui-testing]() ### AI overview A tutorial describing a workaround for Unicode text input in Maestro Android tests. It uses Maestro JavaScript, a local HTTP server, and ADB Keyboard to send Unicode text through Android broadcast intents. ### Source excerpt Learn how to overcome Maestro's Unicode input limitations on Android by building a custom HTTP server solution with ADB Keyboard. Complete implementation guide with code examples. ## Selectively running Android UI tests DevFeed: [Selectively running Android UI tests]() Original publisher: [Read original article]() Author: Segun Famisa Published: 2024-12-14T00:00:00Z Content type: tutorial Language: en Sources: [Segun Famisa]() Topics: [Android](), [Instrumentation](), [Gradle](), [Command-line interface]() Tags: [adb](), [android](), [ci](), [flag](), [gradle](), [instrumentation](), [junit](), [property](), [pull-request](), [test-lab](), [tests]() ### AI overview This tutorial explains how to selectively run additional checks in Android UI tests. It uses a custom annotation and AndroidJUnitRunner filters to target specific tests, then passes arguments through adb or Gradle so the checks can be enabled only under chosen conditions, such as CI runs. ### Source excerpt Intro This is really a note for my future self. Recently, I had a situation where I wanted to perform some extra checks after a test has been run. These additional checks are done after each test is run via a Junit rule SpecialRule which is applied to a test suite. For the purpose of illustration, let's say our SpecialRule looks like this: class SpecialRule : TestRule { override fun apply(statement: Statement, desc: Description): Statement { return object : Statement() { override fun evaluate() { try { // Run the test. statement.evaluate() } finally { // Perform extra checks after the test. Log.d("SpecialRule", "performing extra checks") } } } } } However, we were concerned about the run duration of the tests being extended significantly by the extra checks, so we wanted a bit more control. That led to some constraints. We wanted to: be able to selectively perform those checks on specific tests perform those checks only under certain conditions. Constraint #1 - Selectively perform additional checks on specific tests The immediate approach that came to mind was to use a custom annotation - @SpecialTest, and then somehow find a way to target the tests that are annotated with this. Luckily, the AndroidJunitRunner provides various filters to target specific annotations. For example, to run all the tests annotated with @SpecialTest , we will use something like: adb shell am instrument -w -e annotation com.mypackage.SpecialTest com.android.foo/androidx.test.runner.AndroidJUnitRunner If you use Flank to run your tests on Firebase Test Lab, then you can use: --test-targets: "annotation com.mypackage.SpecialTest" Now that we can selectively target the tests, we need to extend our test rule to only perform these checks if the test is annotated with @SpecialTest annotation. Our SpecialRule then becomes something like: class SpecialRule : TestRule { override fun apply(statement: Statement, desc: Description): Statement { return object : Statement() { override fun evaluate() { t ## Demystifying Maestro's UI Testing Implementation DevFeed: [Demystifying Maestro's UI Testing Implementation]() Original publisher: [Read original article]() Author: Sam Edwards Published: 2024-11-18T13:59:04Z Content type: article Language: en Sources: [Handstand Sam]() Topics: [Testing](), [ui-testing](), [Android](), [Code](), [Git]() Tags: [adb](), [android](), [android-testing](), [code](), [format](), [git](), [library](), [maestro](), [on-device](), [open-source](), [server](), [testing](), [ui](), [ui-testing](), [uiautomator](), [updates](), [xml]() ### AI overview This technical post examines how Maestro implements UI testing. It describes its YAML-based test commands, CLI-installed APKs, an on-device Netty gRPC server, UiAutomator view-hierarchy access, XML serialization, and UI interactions. ### Source excerpt I first heard about Maestro when it was released in 2022, but I haven't played with it until now. I'm doing some work with Espresso and UiAutomator for Android testing and was curious how Maestro worked under the hood, so I cloned their git repo and dove into the code. This quick post shares what [...] ## How to debug Android apps over the Internet DevFeed: [How to debug Android apps over the Internet]() Original publisher: [Read original article]() Author: Dmitry Samoylenko Published: 2024-06-26T00:00:00Z Content type: tutorial Language: en Sources: [Dmitry Samoylenko - Android Developer Blog]() Topics: [adb](), [Android](), [Wireless Debugging](), [debug](), [Internet]() Tags: [adb](), [android](), [android-apps](), [debug](), [internet](), [remote](), [server]() ### AI overview A tutorial about debugging Android apps over the Internet when the developer and target device are in different locations or the app runs on a remote machine. It outlines connecting the phone to one machine with adb and checking the connection from the remote machine. ### Source excerpt How to debug Android apps over the Internet ## Coppercomm -- One interface to unite them all DevFeed: [Coppercomm -- One interface to unite them all]() Original publisher: [Read original article]() Author: Kenneth Karlsson Published: 2024-05-27T06:54:56Z Content type: tutorial Language: en Sources: [Volvo Cars Engineering - Medium]() Topics: [interfaces](), [Testing](), [Python](), [Library](), [ssh](), [Wireless Debugging]() Tags: [adb](), [bridge](), [communication](), [interfaces](), [libraries](), [open-source](), [python](), [ssh](), [test](), [testing]() ### AI overview The article introduces Coppercomm, a Python-based bridge intended to let teams share and rerun the same test cases across organizations. It maps logical or physical interfaces to communication methods such as SSH, serial, and Android Debug Bridge, hiding interface-specific details from test cases through configuration. ### Source excerpt Coppercomm -- One interface to unite them allHow to share test cases across organizations and companiesBackgroundInterface overview Have you ever faced the challenge of reusing test cases when testing the same Device Under Test (DUT) across different organizations and companies? You are not alone. One of the main problems is the different libraries used. And it is not at all unusual for an organization to use different libraries for the same purpose. It could be that one team is not aware of the existence of a library, and decides to create a new one. Suddenly, there are two libraries doing the same thing! It's like having two different keys to the same lock. The problem grows when there is a need to share the same test cases between different companies and organizations. You might want to run a specific test case before delivering to a customer, and then after the customer has applied some changes, they might want to re-run the same test case again to make sure that it still works. You would want to run the same test case, the same way. This is where Coppercomm comes into play. It is written in Python and functions as a bridge between the host and DUT, for different types of communication interfaces, like SSH, serial, and Android Debug Bridge (ADB). This enables us to run the same test case at different departments without modifying the test case, as long as the test case is using Coppercomm and the Coppercomm library is available on the host. How Coppercomm worksCoppercomm overview Coppercomm is pretty basic. You create a configuration file that maps the different interfaces to a logical or physical interface. The configuration file is then used under the hood by Coppercomm. This hides the mapping from the user, and the test cases only need to specify what type of interface they want to use. Voilà! The host communicates with the DUT, without any specifics in the test case. Open sourcing Coppercomm"Given enough eyeballs, all bugs are shallow" - Linus Torvalds Sharin ## Stressing the JVM GC on Android DevFeed: [Stressing the JVM GC on Android]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2024-03-10T08:49:55Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [Android](), [Java](), [Code](), [now-in-android]() Tags: [adb](), [android](), [android-vitals](), [anr](), [fragmentation](), [gc](), [java](), [leak](), [memory](), [memory-leak](), [mobile](), [mobile-performance](), [now-in-android](), [outofmemory](), [performance](), [stress](), [stresstest]() ### AI overview This tutorial describes GCStress, a Java application that deliberately creates garbage-collection pressure through repeated random byte-array allocations and cache removals. It explains how to integrate it into Google's Now in Android app, trigger it with an Android broadcast and adb, and observe effects such as skipped UI frames, possible ANRs, and potential out-of-memory errors. ### Source excerpt This post talks about a way to stress Java garbage collector. ## Introducing Device Streaming in Android Studio in Open Alpha DevFeed: [Introducing Device Streaming in Android Studio in Open Alpha]() Original publisher: [Read original article]() Author: Orlandria Campbell; Stephanie Saade; Jake Ouellette Published: 2024-02-13T00:00:00Z Content type: release Language: en Sources: [Firebase Blog]() Topics: [Android Studio](), [Firebase](), [Testing](), [ide]() Tags: [adb](), [android](), [android-studio](), [firebase](), [ide](), [ssl](), [test-lab](), [testing]() ### AI overview Firebase introduces Device Streaming in Android Studio as an Open Alpha service for testing and debugging apps on real remote devices hosted in Google's secure data centers. The article explains supported use cases, device interaction, setup, and access through Android Studio and Firebase Test Lab. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Extend an ADB Device Chooser to Display Phone Models DevFeed: [Extend an ADB Device Chooser to Display Phone Models]() Original publisher: [Read original article]() Author: Zarah Dominguez Published: 2024-02-02T00:00:00Z Content type: tutorial Language: en Sources: [Zarah Dominguez]() Topics: [Script](), [Development]() Tags: [adb](), [android](), [devices](), [github](), [script]() ### AI overview This tutorial extends an ADB script that presents a chooser when multiple devices are attached. It adds each device's model name to help distinguish test and personal phones. ### Source excerpt Last year, I wrote about an extended adb script. The idea of the script is to make it really easy to issue an adb command even if there are multiple devices attached by presenting a chooser. For example, if I have two physical devices and an emulator and I want to use my deeplink alias, I get presented with a device chooser: ➜ ~ deeplink https://zarah.dev Multiple devices found: 1 - R5CR7039LBJ 2 - 39030FDJH01460 3 - emulator-5554 Select device: ## Farewell from the Reproducible Builds Summit 2023! DevFeed: [Farewell from the Reproducible Builds Summit 2023!]() Original publisher: [Read original article]() Published: 2023-11-02T00:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [reproducibility](), [builds](), [Embedded Systems]() Tags: [adb](), [apache](), [buildroot](), [builds](), [coreboot](), [debian](), [dockerignore-usage](), [fedora](), [germany](), [github](), [linux](), [maven](), [openwrt](), [org](), [reproducibility](), [reproducible-builds](), [security](), [summit](), [systemd](), [ubuntu]() ### AI overview A recap of the seventh Reproducible Builds summit in Hamburg, Germany, covering project updates, reproducibility practices, verification services, filesystem images and containers, package reproducibility, SBOMs, and related discussions. ### Source excerpt Farewell from the Reproducible Builds summit, which just took place in Hamburg, Germany: This year, we were thrilled to host the seventh edition of this exciting event. Topics covered this year included: Project updates from openSUSE, Fedora, Debian, ElectroBSD, Reproducible Central and NixOS Mapping the "big picture" Towards a snapshot service Understanding user-facing needs and personas Language-specific package managers Defining our definitions Creating a "Ten Commandments" of reproducibility Embedded systems Next steps in GNU Guix' reproducibility Signature storage and sharing Public verification services Verification use cases Web site audiences Enabling new projects to be "born reproducible" Collecting reproducibility success stories Reproducibility's relationship to SBOMs SBOMs for RPM-based distributions Filtering diffoscope output Reproducibility of filesystem images, filesystems and containers Using verification data A deep-dive on Fedora and Arch Linux package reproducibility Debian rebuild archive service discussion ... as well as countless informal discussions and hacking sessions into the night. Projects represented at the venue included: Debian, openSUSE, QubesOS, GNU Guix, Arch Linux, phosh, Mobian, PureOS, JustBuild, LibreOffice, Warpforge, OpenWrt, F-Droid, NixOS, ElectroBSD, Apache Security, Buildroot, Systemd, Apache Maven, Fedora, Privoxy, CHAINS (KTH Royal Institute of Technology), coreboot, GitHub, Tor Project, Ubuntu, rebuilderd, repro-env, spytrap-adb, arch-repro-status, etc. A huge thanks to our sponsors and partners for making the event possible: Event facilitation Platinum sponsor If you weren't able to make it this year, don't worry; just look out for an announcement in 2024 for the next event. ## New ways to inject system CA certificates in Android 14 DevFeed: [New ways to inject system CA certificates in Android 14]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2023-09-21T12:00:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [Android](), [HTTP](), [Emulator]() Tags: [adb](), [android](), [article](), [certificates](), [interception](), [tls]() ### AI overview This article explains that Android 14 blocks the previous direct method of installing system-level CA certificates, including on rooted devices, but describes newer practical approaches for rooted Android 14+ devices. It also distinguishes system-level certificate injection from enterprise-managed and user-installed certificates, and mentions HTTP Toolkit's ADB-based automatic setup. ### Source excerpt A couple of weeks ago I published a post about changes in Android 14 that fundamentally break existing approaches to installing system-level CA certificates, even with root access. This has triggered some fascinating discussion! I highly recommend a skim through the debate on Mastodon and Hacker News. Since that was posted, quite a few people have talked to me about possible solutions, going beyond the previous approaches with new mechanisms that make it practical to do this in Android 14+, and there are some good options here. While direct root access to change these certificates by simply writing to a directory is indeed no longer possible, root is root, and so with a bit of work there are still some practical & effective ways to dig down into the internals of Android and seize control of these certs once more. Choose your own adventure: If you just want to intercept an Android 14+ device right now, stop reading this, download the latest HTTP Toolkit, connect your device to ADB, click the 'Android Device via ADB' interception option for automatic setup, and dive into your traffic. If you just want to know the steps to manually do system certificate injection on Android 14 for yourself, jump down to How to install system CA certificates in Android 14. If you want the full background, so you can understand how & why this all works, read on: Clearing up confusion Before digging into this, I do want to explicitly clear up a few misunderstandings that I've seen repeatedly pop up from the previous article: These changes don't affect installation of CAs in other scenarios. As far as I'm aware, CA installation for fully managed enterprise-provisioned devices and the limited user-installed (as opposed to system-level) CA certificates will continue functioning as before. If you're not using root access to inject system-level CA certificates into a rooted device or emulator, you don't need to worry about this. Similarly, it is still possible to soft-remove system CA certific ## Extending an Interactive ADB 🔀 DevFeed: [Extending an Interactive ADB 🔀]() Original publisher: [Read original article]() Author: Zarah Dominguez Published: 2023-09-21T00:00:00Z Content type: tutorial Language: en Sources: [Zarah Dominguez]() Topics: [Development](), [Script](), [Scalability]() Tags: [adb](), [android](), [commands](), [devices](), [emulator](), [parameter](), [scalability](), [script](), [usb]() ### AI overview This tutorial extends an interactive ADB script that helps choose among multiple attached devices when running commands. It addresses counting unauthorized devices and explores passing command stubs as arguments or making the script retrieve a serial number for reuse across commands. ### Source excerpt A few weeks ago, I wrote about a script for making adb a little bit more interactive. The script makes the process of running an adb command much smoother if there are multiple devices attached by presenting a chooser. For example, when sending a deeplink: ➜ ~ deeplink https://zarah.dev Multiple devices found: 1 - R5CR7039LBJ 2 - emulator-5554 3 - emulator-5556 Select device: ## Using a script to select an Android device for ADB deeplink commands DevFeed: [Using a script to select an Android device for ADB deeplink commands]() Original publisher: [Read original article]() Author: Zarah Dominguez Published: 2023-08-30T00:00:00Z Content type: tutorial Language: en Sources: [Zarah Dominguez]() Topics: [Android](), [Script](), [Emulator]() Tags: [adb](), [android](), [debug](), [deeplinks](), [emulator](), [regex](), [script](), [syntax]() ### AI overview This tutorial explains a script that makes Android Debug Bridge deeplink testing easier when multiple devices or emulators are attached. It lists available devices, prompts for a target when necessary, and sends the command to the selected device. ### Source excerpt Android has a lot of tools for developers and one that has been around for as long as I can remember is Android Debug Bridge (adb). It allows you to issue commands to an attached device, such as installing an app or starting an Activity. ## Fixing Android's 3-minute screen recording limitation DevFeed: [Fixing Android's 3-minute screen recording limitation]() Original publisher: [Read original article]() Author: Leland Takamine Published: 2023-08-24T07:00:00Z Content type: tutorial Language: en Sources: [mobile.dev - Medium]() Topics: [Android](), [aosp](), [Code](), [Command-line interface](), [FFmpeg (Fast Forward Moving Picture Experts Group)]() Tags: [adb](), [android](), [aosp](), [code](), [ffmpeg](), [tool](), [video]() ### AI overview The article explains how Maestro addressed Android ADB screen recording's 180-second limit for Maestro Cloud. After evaluating repeated recordings, source modification, scrcpy, and static linking, the team used binary rewriting to change the hardcoded maximum duration in the screenrecord binary. ### Source excerpt How we used binary rewriting to remove the 3-minute screen recording limitation on Maestro Cloud ## Simpleperf case study: Fast initialization of TFLite's Memory Arena DevFeed: [Simpleperf case study: Fast initialization of TFLite's Memory Arena]() Original publisher: [Read original article]() Author: TensorFlow Blog (noreply@blogger.com) Published: 2023-08-09T16:00:00Z Content type: tutorial Language: en Sources: [The TensorFlow Blog]() Topics: [TensorFlow Lite](), [Optimization](), [Machine learning](), [Android](), [Development](), [Code]() Tags: [adb](), [cache](), [display](), [models](), [performance](), [performance-optimization](), [profiling](), [reduce](), [tensorflow-lite](), [visualization]() ### AI overview This developer article presents a case study on optimizing TensorFlow Lite memory arena initialization. It explains how to profile an on-device machine-learning pipeline with Simpleperf, generate profile data, visualize it with pprof, and identify runtime bottlenecks such as ArenaPlanner::ExecuteAllocations. ### Source excerpt Posted by Alan Kelly, Software Engineer One of our previous articles, Optimizing TensorFlow Lite Runtime Memory, discusses how TFLite's memory arena minimizes memory usage by sharing buffers between tensors. This means we can run models on even smaller edge devices. In today's article, I will describe the performance optimization of the memory arena initialization so that our users get the benefit of low memory usage with little additional overhead. ML is normally deployed on-device as part of a larger pipeline. TFLite is used because it's fast and lightweight, but the rest of the pipeline must also be fast. Profiling on the target device with representative data lets us identify the slowest parts of the pipeline so that we can optimize the most important part of the code. In this article, I will describe the profiling and optimization of TFLite's memory arena with instructions on how to use Simpleperf and visualize the results. Sample commands are given. It is assumed that the Android NDK is installed and that you have a development device that you can connect to using adb. Simpleperf Simpleperf comes with some scripts to make it easier to use. run_simpleperf_on_device.py pushes simpleperf to the device and runs your binary with the given arguments. /usr/lib/android-ndk/simpleperf/run_simpleperf_on_device.py record -call-graph fp /data/local/tmp/my_binary arg0 arg1 ... This will generate the output file perf.data which you must then copy back to your computer. adb pull /data/local/tmp/perf.data You then generate the binary cache which contains all the information needed later to generate a useful profile. /usr/lib/android-ndk/simpleperf/binary_cache_builder.py -lib /your/binarys/folder -i perf.data And generate the proto buffer used for visualization: /usr/lib/android-ndk/simpleperf/pprof_proto_generator.py --ndk_path=/path/to/android-ndk -i perf.data -o profile.proto You can then display the results this using pprof: pprof -http :8888 profile.proto And open localhos [Next page]()