Practical playbook for responding to a mass spam-call attack on an Android phone, using ADB (USB or Wireless Debugging) to extract the call log and block offending numbers in bulk.
Written after a real incident on 2026-04-13 where ~260 spam calls hit the phone within hours. Keeping this as a runbook because these attacks are recurring.
| Approach | Result |
|---|---|
adb shell content insert --uri content://com.android.blockednumber/blocked_numbers |
❌ SecurityException: Caller must be system, default dialer or default SMS app. The shell UID cannot write to BlockedNumberProvider. |
am start -a android.settings.BLOCKED_NUMBERS_SETTINGS |
❌ Intent not resolvable on many OEM builds (Motorola tested). |
am start -a com.android.dialer.action.BLOCKED_NUMBERS_SETTINGS |
❌ Activity not exported — SecurityException. |
| Push a vCard with all numbers as one contact, import, toggle "Route to voicemail" | ✅ Works on stock Android. One toggle blocks all numbers. |
| Import the vCard into a dedicated call-blocker app (e.g. EAGLX Callblocker, Calls Blacklist) | ✅ Cleanest — the app has the Default Dialer role it needs and offers bulk import from a contact. |
| Carrier anti-spam service (Telcel, AT&T MX, Movistar) | ✅ Best for ongoing attacks — on-device blocking is whack-a-mole against spoofed numbers. |
- ADB installed (
platform-tools). - Phone with USB debugging or Wireless debugging enabled.
- If USB port is flaky (charge-only / not recognized), use Wireless debugging — it worked when USB didn't.
# Wireless debugging: Settings → Developer options → Wireless debugging
adb pair <ip>:<pair-port> <6-digit-code>
adb connect <ip>:<connect-port>
adb devices # should show "device"adb shell content query \
--uri content://call_log/calls \
--projection "number:date:type" > calllog.txtgrep -oE 'number=[^,]+' calllog.txt \
| sed 's/number=//' \
| grep -vE '^(YOUR_LEGIT_NUMBER|\+52YOUR_LEGIT_NUMBER)$' \
| sort -u > spam_numbers.txtbuild_vcard.sh:
#!/usr/bin/env bash
set -euo pipefail
IN="${1:-spam_numbers.txt}"
OUT="${2:-spam_blocked.vcf}"
{
echo "BEGIN:VCARD"
echo "VERSION:3.0"
echo "FN:SPAM BLOCKED"
echo "N:BLOCKED;SPAM;;;"
while IFS= read -r num; do
[[ -n "$num" ]] && echo "TEL;TYPE=CELL:$num"
done < "$IN"
echo "END:VCARD"
} > "$OUT"
echo "Wrote $OUT with $(grep -c '^TEL' "$OUT") numbers"# MSYS_NO_PATHCONV=1 needed on Git Bash / MSYS to stop path mangling
MSYS_NO_PATHCONV=1 adb push spam_blocked.vcf /sdcard/Download/spam_blocked.vcf
MSYS_NO_PATHCONV=1 adb shell am start \
-a android.intent.action.VIEW \
-d "file:///sdcard/Download/spam_blocked.vcf" \
-t "text/x-vcard"If the import dialog doesn't appear (modern Android blocks some file:// intents), open Files → Downloads on the phone and tap the .vcf manually.
Two options — do both for belt-and-suspenders:
A. Send the contact to voicemail (stock Android): Contacts → SPAM BLOCKED → ⋮ → Route to voicemail ON.
B. Import into a call-blocker app: Open your call-blocker (EAGLX Callblocker, Calls Blacklist by Vlad Lee, etc.) → its import / blacklist-from-contact feature → select SPAM BLOCKED.
- Disconnect Wireless debugging when done (it's a risk on public Wi-Fi): Settings → Developer options → Wireless debugging → OFF.
- Keep
spam_blocked.vcf— reuse it on other phones by importing the same contact.
- Don't trust USB-C cables. Several "data" cables in my drawer turned out charge-only. If
adb devicesis empty, swap cables before anything else, but Wireless debugging is the fastest fallback. - A phone that only shows "USB charging" and isn't enumerated in Windows Device Manager is usually a dirty/damaged USB-C port (lint) or a charge-only cable — not an ADB config problem.
- Spoofed numbers: most spam attacks use spoofed caller IDs, so the numbers you block today may never call again anyway. The carrier-side filter matters more than the on-device blocklist — always call the carrier and enable their anti-spam service during an active incident.
- Local government / community blocklists (e.g. Mexico's EAGLX Callblocker for known fraud rings) are worth installing in advance; they auto-update from a curated DB.
- Track install dates after a cloud restore:
dumpsys package <pkg> | grep -iE 'firstInstall|lastUpdate'. Useful to distinguish "installed by attacker" from "restored from backup."
README.md— this document.build_vcard.sh— script to turn a plain list of numbers into an importable vCard..gitignore— excludes any real phone-number lists so personal data isn't committed.