Android APS, the hacker mindset, and finding a system that worked for my life.

In 1990, at age five, I was diagnosed with type 1 diabetes. So, when I was eight years old, I had a simple question for my doctor:

“Why can’t I have a watch that shows my blood sugar in real time?”

By that age, I was already tired of having to prick my fingers. Checking my blood sugar meant making myself bleed. I knew that same blood was flowing just under my skin, so why couldn’t something on my wrist tell me what was happening?

The idea seemed simple to me. Making it work was another matter.

Decades later, continuous glucose monitoring and a connected watch finally gave me what childhood me had wanted.

But having the information was only part of the picture. The next question was what I could do with it.

And that meant thinking about pumps again.

My first pump experience was a nightmare

In my teens, I had an insulin pump forced on me before I was comfortable with the idea.

The pump I used had a massive insertion needle. I dreaded changing the site, so I’d leave the infusion set in longer than I should have. That contributed to scarring and fatty buildup.

Then there was the delivery itself.

Sites would clog—or “occlude.” Tubing would catch on doors and drawers, ripping the site out or damaging the tubing. I never felt confident that the insulin the pump said it was delivering was actually getting into me.

Before the pump, DKA—diabetic ketoacidosis—hadn’t been a concern in my life. At all. On the pump, it became a recurring concern.

Shortly after getting it, I made three trips to the hospital in a single week and was eventually admitted for a week and diagnosed with acute pancreatitis. Fun!

Going back to injections wasn’t me rejecting technology. It was returning to a way of managing my diabetes that I felt more comfortable relying on. I was delivering the injections myself, without tubing or an infusion site leaving me wondering whether the dose had reached me.

For roughly two decades, I carried needles and vials, made adjustments, and adapted. Simplicity and reliability ruled the day.

When I considered a pump again, “newer” wasn’t enough. I needed to know what had changed—and whether those changes addressed what had made my first experience so difficult.

I was already doing the forecasting

Since my teens, I’d been very familiar with how different blood sugars felt.

When I compared those sensations with a finger-prick reading, I could reliably estimate my glucose within about 20–40 mg/dL. I relied heavily on that awareness and tested infrequently despite my doctors annoyance.

My A1C was generally around 6.5–8%, and I rarely experienced lows. That was my experience, not an approach I’m recommending – it worked for me, but it is definitely not the norm which is what annoyed my doctors. But at the time, it was how I managed: one daily injection of long-acting insulin, with several injections of short-acting insulin as ongoing adjustments for meals and other variables.

Looking back, what interests me is how much forecasting was involved.

What had I eaten? How much insulin had I taken already, and when? Was I active? What did I feel happening, and what was likely to happen next?

Without calling it forecasting, I was practicing it every day.

Diabetes isn’t a tidy equation. The same inputs don’t always produce the same result. But I was learning relationships, anticipating changes, and adjusting to the trend when my prediction didn’t match reality.

Those are ideas I recognize in forecasting and data science. I’d been working with them long before I had those names for them.

Finally, the number on my wrist

Around 2015, I began losing some of my sensitivity to feeling highs and lows.

Later, when insurance coverage made continuous glucose monitoring accessible to me, I started using a Dexcom G6.

Instead of relying so heavily on physical sensations, I had a consistent stream of readings showing what my glucose was doing—and which direction it was heading.

I could see patterns in how my glucose responded after food or insulin, instead of relying so heavily on how I felt. That gave me better feedback for the decisions I was making.

I bought a Garmin fitness tracker and got that information onto my wrist. Childhood me would be ecstatic.

I’ve since moved to the G7, but getting that first continuous feed of glucose information was the important change. I could see things unfolding instead of relying so heavily on how they felt.

That brought me to another question:

If I could use that information to make adjustments, couldn’t software help with some of those adjustments too?

I had to start thinking seriously about pumps again.

DASH got my attention

The Omnipod DASH addressed several things that mattered to me.

It was tubeless and relatively low-profile. After my earlier experience, tubing wasn’t a minor detail. Removing it meant removing something that had caught on doors, broken, and contributed to my uncertainty about insulin delivery.

A tubeless pump doesn’t eliminate delivery failures. But it removed a specific set of problems I already knew I didn’t want back.

DASH also communicated over Bluetooth. As I researched it, I learned about Android APS, or AAPS: an open-source Android application that can use glucose data and a compatible pump to automate insulin delivery.

This was before Omnipod’s newer automated system was available to me. DASH didn’t provide automated insulin delivery on its own, but paired with a compatible CGM and Android APS, it could become part of a system that did.

Once I heard open source, Android, and DASH, I had to pull the trigger.

I made an appointment with my diabetes educator and started using DASH. Its separate controller/PDM went straight back into its box, never to be seen again. I immediately started using DASH with Android APS on my Samsung Galaxy phone instead.

I’d spent decades waiting for a system that made sense for me—not just another individual tool.

Once I found it, I took direct action.

What Android APS actually does

At a high level, the pieces are straightforward.

The CGM provides glucose readings. The pump delivers insulin. Android APS supplies the software connecting that information to decisions about insulin delivery.

It uses glucose readings and trends, information about insulin already delivered, recorded carbohydrate intake, and configured settings to calculate adjustments and send commands to a supported pump.

This creates a feedback loop: observe what’s happening, account for previous actions, predict what comes next, and adjust.

I recognized a familiar pattern: observe, orient, decide, act. The OODA loop was a useful way for me to think about the process—not a description of how every part of the algorithm worked.

The basic idea made sense to me. The implementation is considerably more complicated.

Insulin doesn’t act instantly. Glucose readings aren’t perfect. Carbs don’t all digest at the same rate. Food, activity, illness, and plenty of other factors affect the result.

Getting two devices to communicate makes automation possible. It doesn’t, by itself, make the decisions easy or appropriate.

That’s where the algorithm, settings, safeguards, and understanding of the system matter.

Android APS didn’t mean I could stop managing my diabetes. It changed how I managed it—and how much of the ongoing adjustment the system could help with.

Learning was part of the system

Android APS didn’t hand me every advanced feature at once.

I worked through its objectives. As I progressed, more capabilities became available.

The objectives weren’t just boxes to check. They helped explain how the system worked and checked my understanding before I moved further.

It trusted the user, but also verified the user’s understanding of the concepts.

I was learning to use a highly customizable system that could adjust insulin delivery around the clock. Incorrect insulin delivery can be fatal. Understanding what the system was doing wasn’t optional.

When I had questions, I asked in the Android APS Facebook group. Documentation and conversations with other users helped me understand what I was seeing and gradually fine-tune my settings.

That learning wasn’t separate from making the system useful. It was part of it.

First I felt better. Then I saw why.

The first meaningful result wasn’t a perfect graph.

It was feeling better—physically, and because I wasn’t thinking about my diabetes non-stop.

That happened early on. The numbers reflected a difference I was already experiencing.

The data mattered because it connected to my life. It wasn’t just a target on a screen.

As I learned more and fine-tuned my settings, I eventually achieved a day with 100% of my CGM readings between 70 and 180 mg/dL—the range I use to report my time in range.

Then came stretches of multiple days.

Those were milestones under favorable conditions—not a claim that every day looked like that, or a standard everyone else should expect to meet. For me, they demonstrated what I could achieve with that setup.

After years of managing diabetes, seeing those results was extremely satisfying.

So was experiencing a system that could take on some of the ongoing adjustment I’d spent years doing myself.

The pieces weren’t just connected. They were doing something useful together.

The same mindset, different stakes

In my previous article, I Bought the Bike. Why Can’t I Choose the Software?, I wrote about using QZ to connect my exercise bike to applications it didn’t natively support.

The appeal wasn’t simply getting around a restriction. It was making equipment work better for what I wanted to do.

Android APS fits that theme, but the stakes are very different.

An exercise bike and an insulin pump aren’t interchangeable technology projects. A missed resistance change and an incorrect insulin adjustment have very different consequences.

The connection is the mindset: asking what becomes possible when devices work together, then learning enough to use those possibilities responsibly.

It’s also the community.

With QZ, I asked questions, shared logs, provided feedback, and eventually helped moderate the community. With Android APS, I found another welcoming community where people shared what they knew. Those conversations helped me understand the technology, use it, and eventually share what I’d learned with others.

Open source isn’t just about being able to read code. It’s also about people making their experience available to the next person.

That doesn’t remove my responsibility for the system I use. It means I don’t have to learn everything alone.

We can share knowledge, question decisions, and hold each other accountable without tearing each other down.

That’s what I value about these communities: people using what they know to make someone else’s life better.

To me, that’s kindness in action.

Not a cure, but a meaningful change

Since around 2000, I’ve periodically asked my endocrinologist, who worked in diabetes research, how far away a cure is.

“Five years,” he’d say with a little smirk.

It didn’t take me long to pick up on that pattern and begin laughing too.

“Five years” has become a running joke for many of us living with diabetes. It can start to feel like a deadline that moves along with you.

Android APS isn’t a biological cure. I still need insulin, supplies, working devices, and an understanding of what the system is doing.

But when I imagined a better way to live with diabetes, this was a large part of what I wanted: useful information, appropriate adjustments, and less of my attention consumed by managing the connection between them.

I’m interested in future treatments. I’m also interested in what can make life better now.

For me, this did.

This time, I chose it

My first pump experience left me with good reasons to be reluctant. DASH addressed some of the practical problems. My CGM provided ongoing glucose information. Android APS connected those pieces into a system that worked for me.

And this time, I chose it.

This isn’t an argument that everyone should use my setup. It’s an account of what became possible when I found technology that fit my needs.

Childhood me wouldn’t be shocked that I can see my glucose on a watch. That was the point—I wanted it because I could imagine why it would be useful.

Connecting that information to insulin delivery followed the same logic. I didn’t know all the engineering it would take, but I could see the possibility.

I wasn’t waiting to discover that technology could help.

I was waiting for the pieces to connect.