The room was dark and filled with a beam of light coming from a single window. The air, filled with the smell of old books, felt thick. Each step produced a small distant echo as Doug approached the only thing in the room — the desk and its occupant.
“What brings you down here?” said Xander breaking the silence.
“I’m looking for a record, a very old one” said Doug trying to hide his excitement. “How far do our records go?”
“Well, sometime around the middle of 21 century. Who are you looking for?”
“Let me take a look” said…
I don’t know how code review is implemented in Google for the changes (f0c7198 and 50307d9) that will be reviewed here. I also can’t see the issue tracker for the particular problem that was being fixed. But since I’m affected by this change, I can only make this a public thing and hope for the best. If you don’t like to discuss or know about problems, read no further.
Disclaimer: I am in no way attacking Google or its employees. Everything expressed below are my personal opinions.
In this post, I’ll introduce you to adam: a kotlin-based replacement for developer-to-android-device interaction.
Most of the current tools for interaction with ADB server use ddmlib: a Java-based library that is supposed to help tool developers.
The following diagram illustrates the flow of interaction:
If we’re talking about a laptop, then leaving it alone for a couple of years would do little damage: your battery will be dead, but you can quickly charge it. Unfortunately, it doesn’t work the same for a musical instrument such as a piano.
In August 2019, I found an old piano that seemed to be forgotten about. A bit of context here, my primary role at work is as a Principal Software Engineer (Keyword Software). I like to explore other topics in-depth with my hobbies. This piano restoration project is one of them.
Tuning 8 Jack springs…
Hello. It’s currently 2019 and testing open source Android projects is extremely hard. The reason for this is the state of Android Emulator and it’s dependencies.
I am going to focus on the official Android Emulator images provided via the Android SDK
Before Android 26 we had:
By hardware acceleration I’m referring to the HAXM/Hypervisor.framework on MacOS, KVM on Linux and HAXM/WHPX on Windows
This status quo changed when Google stopped building arm…
Working with any build system is fun and games until you reach a point where almost every single person complains about the performance of builds. As with any problem, it requires tools in order to be solved.
For the past week or so, I’ve tried to understand if it’s possible to get visibility into gradle builds without the help of Gradle Enterprise, a proprietary solution developed by Gradle.
In this chapter, I’ll explain how Marathon test runner is implemented and what are the basic concepts that are used.
For the previous chapter see Chapter 1.
Marathon test runner is written in Kotlin with extensive use of coroutines. Test runner consists of several Gradle modules. The main execution logic can be visualised as the following diagram:
So you’ve scaled up your mobile infrastructure to support the ever-growing number of tests for your application, and you think everything will be fast, right?… Wrong! In the next several minutes I’ll teach you why scaling infrastructure doesn’t necessarily lead to faster test execution and how you can address this.
The approaches and test runner described in this article have been battle tested by several companies and executed millions of UI tests. All the source code is available on GitHub. I humbly ask you to star, share and spread the word.
A story of color correcting the TV that started with adjusting some settings with remote, then escalated to doing vector multiplications by hand and ended up with small modifications to the firmware of the TV. Read on if you’re interested in color and embedded Android Linux.
It doesn’t take much to produce color from any screen now, but it takes a lot to produce accurate colors. What does the term accurate colors actually mean?
There is an assumption that all humans perceive the color in the same way (or at least we’re targeting an average person) and the first quantifiable…
or, the story of making Nexus OSS Highly Available.
Sooner or later, every team needs artifact storage, e.g.: Maven, npm, docker, etc.; preferably with caching support. Having in-house storage can dramatically improve performance. For example: cold builds of Android applications or APK installs in Alpine can be sped up by tens of minutes, depending on how slow your internet connection is.
The problem comes when you want to have SLAs set for artifact storage system: e.g., you need 99.9% uptime. This is where High Availability (or HA) comes in. …
Software engineer & IT conference speaker; Landscape photographer + occasional portraits; Music teacher: piano guitar violin; Bike traveller, gymkhana