DEV Community: Benjamin Kincses

That .apkm file will not install from your file manager

Benjamin Kincses — Sun, 08 Nov 2026 11:55:55 +0000

Downloaded a beta update today. Tapped the file in the file manager. Nothing happened. No error, no install screen. Nothing.

The file was fine. The format was the problem.

An .apkm is not an APK

It is a zip. Inside is not one app but a set of them: a base.apk, plus config splits. One split per CPU architecture, one per screen density, one per language, and sometimes a pile of feature modules on top.

The stock Android installer opens a single APK. It does not open bundles. Third-party installer apps exist for this format, but you do not need one. You need adb and two minutes.

Look inside first

unzip -l app.apkm

Real numbers from the two bundles I installed today: one was 201 MB with over 30 splits inside. The other was 340 MB with 126 files, 85 of them feature splits. My phone needed 4 files out of the first bundle and 72 out of the second. Everything else in there is for other phones.

Check the signature before you install anything

A split bundle from a mirror is still a sideload. Two checks, both cheap.

First, the version. If the bundle's versionCode is lower than the installed app's, Android refuses the downgrade and the install dies.

adb shell dumpsys package com.google.android.youtube | grep versionCode

Second, the signing certificate. An update only installs over the existing app if the same key signed it. If the cert differs, one of two things is true: the file is a modded build, or it is not the app you think it is. Either way, you want to know before, not after.

apksigner verify --print-certs base.apk

Pull the installed app's base.apk and compare the SHA-256 fingerprint. Today both bundles matched the installed apps exactly. Official builds, just shipped as bundles. That is the normal case for beta mirrors, but check anyway. It costs ten seconds.

Install only the splits your phone needs

Pick by three things: architecture (arm64-v8a on most current phones), density (mine is 320 dpi, so xhdpi), language (en).

adb install-multiple -r base.apk split_config.arm64_v8a.apk split_config.xhdpi.apk split_config.en.apk

If the bundle has feature splits, install the ones for your architecture and language too. If a required split is missing, the installer fails and names it.

Verify like you mean it

adb shell dumpsys package com.google.android.youtube | grep -E "versionName|versionCode"

Then open the app. New version in dumpsys plus the app actually running is proof. "Install said Success" on its own is not.

The short version

.apkm, .apks, .xapk: bundles, not apps. The file manager tap failing is expected behavior, not a broken file.
The bundle is a zip. Look inside before you install anything from it.
Match the signing cert to the installed app. Mismatch means stop.
Install base plus your architecture, density, and language splits with install-multiple.
Verify the version after, and launch the app.

Blind RSA in circl ignored the reader you passed it

Benjamin Kincses — Thu, 05 Nov 2026 10:46:30 +0000

Cloudflare's circl has a partially blind RSA signer. Its Blind method takes an io.Reader. The blinding factor used that reader. The salt did not. It read from crypto/rand directly.

That breaks the contract. Two calls with the same deterministic reader should give the same blinded message. They did not, because half the randomness came from somewhere else. The sibling code in brsa.go did it right and used the supplied reader throughout.

The fix is one line in blindsign/blindrsa/partiallyblindrsa/pbrsa.go:

_, err := io.ReadFull(random, salt)

It used to read from rand.Reader. Now it reads from random, the reader the caller passed in.

The test pins it down. TestBlindUsesSuppliedReader calls Blind twice with fresh deterministic readers that emit the same byte sequence. Both blinded messages must be identical. It fails before the fix and passes after. Callers passing crypto/rand see no behavior change.

Merged as cloudflare/circl#711: https://github.com/cloudflare/circl/pull/711

mypy rejected subclassing an inferred-Any variable. The fix is deferred, not special-cased.

Benjamin Kincses — Thu, 29 Oct 2026 10:45:27 +0000

mypy accepted this:

from typing import Any

def f(x: Any):
    class Sub(x): pass

It rejected this:

def f(*args: *tuple[int, Any]) -> Any:
    x = args[1]
    class Sub(x): pass

Same variable, same Any. The difference is when the type is known. Semantic analysis runs before type inference. When a base class is a variable with no inferred type yet, the analyser saw Var.type is None and reported it invalid, early, before inference ever got a say.
The fix does not special-case Any. It defers the verdict. A new DeferredBaseClassVar exception fires when a base-class variable has no inferred type yet, on the base-class analysis path only. analyze_base_classes catches it, treats the base as Any provisionally so MRO computation proceeds, and records it for the checker to settle once inference is done. The premature --disallow-subclassing-any error is skipped for provisional bases for the same reason: you cannot grade a type that does not exist yet.
The general point is the one that keeps showing up in type checkers: an error raised in the wrong phase is a false positive, even when the check itself is correct. Fix the phase, not the check.
Since the first version, the deferred-base handling gained support for a second subscript and for string subscripts, pushed 2026-10-29. The PR is still open, not merged.
PR: python/mypy#22037. Fixes #21998.

lazycommit: the commit message is clerical work

Benjamin Kincses — Fri, 23 Oct 2026 22:15:08 +0000

The problem

The change is done. Tests pass. Then I run git commit and sit there,
staring at a blinking cursor, trying to compress an hour of work into
seven words.

I have typed "fix stuff" more times than I will admit. Also "wip",
"changes", and once, memorably, "please work". Every one of those
commits was good code with a message written by a person who had
already spent his attention on the code.

So for Slow and Steady I built the tool I kept wishing for. It does not
write code. It does the clerical work after the code, which is exactly
the work laziness should take.

What I built

lazycommit is a small CLI, one Python file, standard library only.

Stage your changes, run it, and it prints three commit messages in
Conventional Commits format. You press 1, 2 or 3, and it commits
with the one you picked. Press q and it walks away and commits
nothing.

git add stats.py
lazycommit

No dependencies to install, no config file, no API key. The whole thing
is small enough to read in one sitting, which I count as a feature.

How it works

Three steps, and the interesting part is what each one refuses to do.

1. Read the staged diff, and only the staged diff.
git diff --cached. Unstaged work never leaves the machine, because it
was never part of this commit. If nothing is staged, the tool says so
and exits. It does not guess.

2. Send a capped diff to a free text endpoint.
The diff is truncated at 6,000 characters before it goes anywhere. The
head of a diff carries the file names and the first hunks, which is
enough context for a subject line, and the cap keeps the request small.
The default endpoint is the Pollinations text API: free, no key,
a messages array in and text out. The model and endpoint are flags
(--model, --endpoint), so swapping providers is a one-line change.

The prompt is strict. Exactly three lines. Conventional Commits format.
Imperative mood, under 72 characters each. Three different angles on the
same change.

3. Parse like you do not trust the model. Because I do not.
Models like to help. They add "Here are three options for you!" and
numbering and backticks. The parser strips all of that, prefers lines
that actually match the type(scope): summary pattern, drops
duplicates, and takes the first three. If nothing usable comes back,
you get a one-line error. Not a traceback, and not a garbage commit.

That defensive parser is most of the code, and most of the tests.
23 tests, all offline, API and git mocked.

Demo

A real run, live free API, throwaway repo. The staged change adds an
empty-list guard to an average() helper:

$ git add stats.py
$ lazycommit
  1. feat(stats): handle empty list in average
  2. fix(stats): return 0 for empty numbers
  3. perf(stats): guard against division by zero
pick 1-3 (or q to quit): 1
[master bab7bea] feat(stats): handle empty list in average
 1 file changed, 2 insertions(+)

Notice what happened there. Three messages, one change, and they still
disagree about whether it was a feat, a fix or a perf. Anyone who
has argued about commit types in a review thread knows that argument.
The tool does not settle it. It just makes sure I am choosing between
three decent options instead of inventing a fourth bad one from
nothing.

Total time, about ten seconds, most of it network.

What I learned

The API call was the easy part. Fifteen lines, including the error
handling. Everything else was deciding where the laziness stops.

One generated message would have been faster to build. It also would
have been a command: take it or leave it. Three messages is a menu.
Reading three short lines and pressing one key is genuinely lazy, and
the choice stays mine. That difference is the whole design.

The other thing: a tool that commits on your behalf has to be boring
about safety. Stage nothing, get nothing. Model rambles, commit
nothing. Network dies, one clean line of error and commit nothing.
Every failure path in lazycommit ends the same way, with your repo
exactly as you left it.

Slow and steady, it turns out, is a decent spec for a lazy tool.
Small, a little stubborn, and it saves its effort for the part you
actually want to skip.

The code is on GitHub: https://github.com/Dextheking1/lazycommit. MIT licensed.
Take it, break it, and go back to not writing commit messages.

This is part of the DEV x MLH Hacktoberfest "Slow and Steady"
challenge.

3 prompt patterns that actually work, with copy-paste examples

Benjamin Kincses — Mon, 28 Sep 2026 23:18:46 +0000

Most bad AI output is a bad prompt, not a bad model. These three patterns fix the majority of it. Each one includes a template you can copy.

1. Role plus constraints

Vague prompts get vague answers. Give the model a role and hard constraints:

You are a senior Python reviewer. Review the code below.
Rules:
- List only real bugs, not style nits
- Max 5 items
- Each item: one line describing the bug, one line with the fix

The constraints do the heavy lifting. "Max 5 items" and "one line each" force density. Without them you get a polite essay.

2. Few-shot examples

Show the model what good output looks like instead of describing it. Two examples beat two paragraphs of instructions:

Convert these into calendar event titles:

Input: "Lunch with Sara tomorrow at noon"
Output: "Lunch - Sara"

Input: "Dentist appointment Friday 3pm"
Output: "Dentist"

Input: "Call the bank about the fee on Monday morning"
Output:

The model continues the pattern. This works for formatting, classification, tone matching, and extraction. Use it whenever the output has a shape you can demonstrate.

3. Ask for questions first

For anything complex, make the model interrogate you before it answers:

I want to automate my invoice reminders. Before you suggest anything,
ask me every question you need answered to give a good recommendation.

This kills the biggest failure mode: the model guessing your context and confidently solving the wrong problem. Answer its questions, then let it work.

Putting it together

A strong prompt usually combines all three: a role with constraints, one or two examples of the output shape, and a questions-first step for anything ambiguous. Try rewriting your most-used prompt with this structure and compare the outputs.

I build AI automations for businesses. Chatbots, workflow automation, custom tools that cut manual work. Engineering proof: github.com/Dextheking1. DMs open on X: @FREEAIMETHODS.

Automate a boring task for $0 with the Google AI Studio free API tier

Benjamin Kincses — Mon, 28 Sep 2026 16:29:04 +0000

Automate a boring task for $0 with the Google AI Studio free API tier

Google AI Studio gives you a free Gemini API key with a generous free tier. No credit card. Here is the full path from zero to a working automation.

1. Get your free API key

Go to aistudio.google.com, sign in with a Google account, and click "Get API key". Copy it. Treat it like a password: put it in an environment variable, never in your code.

export GEMINI_API_KEY="your-key-here"

2. Make your first call

No SDK needed. Plain curl works:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-lite:generateContent" \
  -H "Content-Type: application/json" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -d '{"contents":[{"parts":[{"text":"Summarize this in one sentence: The quick brown fox jumps over the lazy dog."}]}]}'

gemini-2.5-flash-lite is the fastest model and has the most generous free-tier quota, so it is the right default for automations.

3. Build something real: a text summarizer

Say you wake up to 40 unread newsletters and threads. This script condenses pasted text into 5 bullets:

import os, sys, json, urllib.request

API_KEY = os.environ["GEMINI_API_KEY"]
MODEL = "gemini-2.5-flash-lite"
URL = f"https://generativelanguage.googleapis.com/v1beta/models/{MODEL}:generateContent"

def summarize(text):
    body = json.dumps({
        "contents": [{"parts": [{"text":
            "Summarize the following in exactly 5 short bullets:\n\n" + text}]}]
    }).encode()
    req = urllib.request.Request(
        URL, data=body,
        headers={"Content-Type": "application/json", "x-goog-api-key": API_KEY})
    with urllib.request.urlopen(req) as res:
        data = json.load(res)
    return data["candidates"][0]["content"]["parts"][0]["text"]

if __name__ == "__main__":
    print(summarize(sys.stdin.read()))

Usage:

cat long-article.txt | python summarize.py

Zero dependencies beyond the standard library. Run it on a schedule with cron and you have a free daily digest.

4. Know the limits

The free tier has rate limits (requests per minute and per day). They change, so check your current quota at aistudio.google.com under usage. If you hit a 429, slow down and retry later.

One real caveat: do not send private or customer data through the free tier. Keep it to public or personal content.

Where this goes

Once you see what one script can do, the next step is wiring it into a real workflow: inbox triage, lead follow-ups, report generation. That is the part I do for businesses.

I build AI automations for businesses. Chatbots, workflow automation, custom tools that cut manual work. Engineering proof: github.com/Dextheking1. DMs open on X: @FREEAIMETHODS.