Android 17 Went Canary-Only, So I Gave My Agent the Silence Rules First

Keep only the intersecting lines, and express silence as an exit code

The next step compares a list of changes against that inventory. The important part is that the conclusion travels in the exit code, not in the prose. The agent does not have to interpret a paragraph to decide what to do next.

#!/usr/bin/env python3
"""Keep only the change lines that touch this project.
 
    python3 relevance_filter.py inventory.tsv changes.txt
 
Exit codes (the agent branches on these):
    0  ... nothing relevant changed (do not report)
    10 ... something relevant changed (report)
    2  ... input unreadable (a misconfiguration; never silently return 0)
"""
import re
import sys
from pathlib import Path
 
# Fragments that collide with ordinary English are never used as standalone keys.
# This was the single largest source of false positives.
GENERIC = {
    "internet", "wake_lock", "vibrate", "camera", "storage",
    "notification", "notifications", "service", "activity", "manager",
}
 
 
def keys_for(symbol: str) -> set:
    """android.app.WallpaperManager -> full / app.wallpapermanager / wallpapermanager"""
    parts = [p for p in re.split(r"[.\s]", symbol) if p]
    out = {symbol.lower()}
    if parts:
        last = parts[-1].lower()
        if last not in GENERIC and len(last) > 3:
            out.add(last)
    if len(parts) >= 2:
        out.add(f"{parts[-2]}.{parts[-1]}".lower())
    return out
 
 
def load_inventory(path: Path) -> dict:
    table = {}
    for line in path.read_text(encoding="utf-8").splitlines():
        if not line.strip():
            continue
        kind, _, symbol = line.partition("\t")
        if not symbol:
            continue
        for key in keys_for(symbol):
            if len(key) > 3:
                table.setdefault(key, f"{kind}:{symbol}")
    return table
 
 
def main() -> int:
    if len(sys.argv) != 3:
        print(__doc__, file=sys.stderr)
        return 2
    inv_path, changes_path = Path(sys.argv[1]), Path(sys.argv[2])
    if not inv_path.is_file() or not changes_path.is_file():
        print(f"cannot read input: {inv_path} / {changes_path}", file=sys.stderr)
        return 2
 
    table = load_inventory(inv_path)
    if not table:
        print("inventory is empty; the extractor is probably broken.", file=sys.stderr)
        return 2
 
    hits = []
    for lineno, raw in enumerate(changes_path.read_text(encoding="utf-8").splitlines(), 1):
        low = raw.lower()
        why = sorted({w for key, w in table.items() if key in low})
        if why:
            hits.append((lineno, raw.strip(), why))
 
    if not hits:
        print("Nothing relevant changed.")
        return 0
 
    for lineno, text, why in hits:
        print(f"L{lineno}: {text}")
        for w in why:
            print(f"    <- {w}")
    print(f"\n{len(hits)} matched / {len(table)} watched keys")
    return 10
 
 
if __name__ == "__main__":
    sys.exit(main())

Feeding it a five-line change list left exactly two lines standing.

L1: Behavior change: WallpaperManager.setBitmap now throws when the caller is in the background.
    <- import:android.app.WallpaperManager
L4: Foreground services with type dataSync are limited to 6 hours per day.
    <- service-type:dataSync

2 matched / 18 watched keys

The other three were about Credential Manager, Camera2 and Compose. All genuinely important changes, none of which my current code touches. The decision not to read them became mechanical.

An ordinary English word broke the silence

The first version had no GENERIC set. It used the trailing identifier of every symbol as a key, full stop.

Running that version produced matches like these.

L1: Chrome now blocks mixed content over the internet.
    <- permission:android.permission.INTERNET
L2: Android 17 tightens INTERNET-less loopback access.
    <- permission:android.permission.INTERNET

Because android.permission.INTERNET contributed internet as a key, every sentence containing the ordinary English word matched. A permission that almost every app declares had handed the filter a key that almost every paragraph contains. As filter design goes, that is about as bad as the pairing gets.

In raw numbers the fix was small: 19 watched keys became 18. But that one key was the thing breaking the silence. False positives look like the harmless failure mode, the one where you merely receive some extra notifications. In practice they cause a different failure: the notifications stop being believed. Once that happens, the correct ones go unread too.

Until I made that change I had been worrying almost entirely about the other direction, about missing something that mattered. The dangerous side was the opposite one.

That last row was added later. An absence of reports looks identical from the outside whether things are calm or broken. Deciding that an empty inventory exits with code 2 and makes noise is what made the quiet trustworthy.

The instructions to the agent came out to three steps

What actually goes to Antigravity is surprisingly short. Pushing the judgement into the script left very little for the prompt to carry.

1. Run `./inventory.sh .` and save the output as inventory.tsv
2. Fetch the change list being watched as changes.txt
3. Run `python3 relevance_filter.py inventory.tsv changes.txt`
   - exit 0  ... do nothing, leave no report
   - exit 10 ... report with the output attached verbatim; do not summarise or paraphrase
   - exit 2  ... report that the watch itself is broken

The "do not summarise" clause earned its place in practice. Summaries read nicely, but they tend to drop the qualifiers that carry the actual risk, such as which API level the behaviour starts at or which service type it is limited to. If only two lines matched, handing me those two lines is both faster and safer.

Summarising pays off when the volume is high. If the filter is doing its job, the volume is low, and low volume does not need summarising. The two mechanisms turned out to be substitutes rather than complements.

Three things I look at myself, once a quarter

Handing the weekly judgement to a machine meant I had to decide where my own attention goes. Since the external markers are gone, I have to place my own.

1. The diff of the inventory itself. Which APIs, permissions or service types appeared since last time? A newly touched surface is a newly watched one.
2. Deprecations parked earlier. Everything silenced weekly gets reviewed together here.
3. A minimal on-device check. Install a Canary build and confirm just two paths: applying a wallpaper, and receiving a notification.

Three items, deliberately. A longer list does not get executed, and an operating rule that is not executed is indistinguishable from one that was never written.

Build the safety net for what the filter misses

This filter will miss things. Behaviour changes that never appear in release notes cannot be caught in principle, and ones phrased differently will slip past the string match.

So I spend roughly as much effort on the net underneath as on the accuracy of the detector. For me that net is staged rollout in the store: ship to a small percentage first, watch crash-free users and ANR before widening. That practice predates Android 17, but with the external verification markers gone, it now carries more of the weight.

I have written up the halt-criteria side of that in designing halt criteria an agent can evaluate during a staged rollout, and the concrete Android 17 migrations I actually hit in inventorying local network permission call sites by hand-proof detection and auditing orientation and resizability constraints on large screens.

If you are building the same thing

Before writing any filter, write down five changes you can confidently say you do not need to hear about. If you can name five, that standard can become code. If you cannot, the condition you write will end up as something like "anything that looks relevant," and an ordinary English word will break your silence within the first week.

That detour is exactly the one I took, and it is the part I would skip if I were starting again.