Předmluva

• OS
  • Operační systém, software, na kterém bezi jiný software.
• Android
  • Operační systém od společnosti Google, Inc. pro chytré telefony.
• GOS
  • GrapheneOS, zkratka pro tento OS založený na OS Android
• LOS
  • LineageOS, zkratka pro tento OS založený na OS Android.
  • LineageOS je založený na AOSP.
• AOSP
  • Android Open Source Project, jedná se o Android, který je "očištěný" od služeb Google a má v sobě pouze licenčně svobodné programy.
• Raspberry Pi
  • Raspberry Pi je jednodeskový počítač, zaměřený hlavně pro kutily.
  • Tento počítač má tzv. GPIO pinout, ke kterému lze připojit čidla a ty poté přímo z OS programovat.
• DDNS
  • Dynamic DNS, neboli dynamická domena.
  • Jedná se o domenu, kterou vam přideli nejaky poskytovatel (třeba freedns.afraid.org), který vam doménu aktualizuje periodicky, což se hodi, kdyz mate dynamickou IP adresu.
• Desktop Mode
  • v kontextu OS Android se jedná o funkcionalitu operačního systému, který umožňuje ovládat telefon připojený k počítačovému monitoru (společně s periferiemi jako myš a klávesnice) jako klasicky stolni počítač, byť s jinou filozofií ovládání.
  • Telefon se tak chová jako klasický stolní počítač, ačkoliv si ponechává své rozhraní pro dodatečnou funkcionalitu.
  • Jinymi slovy lze říci, že telefon plní funkci stolniho počítače i telefonu zároveň.
  • Subjektivně si myslim, že budoucnost výpočetní techniky půjde i tímto směrem.

Co předcházelo

V květnu 2022 jsem se po delší době používání svého tehdejšího telefonu Nokia 5 (Čistý Android) rozhodl k zakoupení nového přístroje, jelikož Nokia přestávala stačit mým potřebam, stejně tak i co se velikosti displeje týče.
Volba tehdy padla na Xiaomi Mi 11 Lite 5G, verze 8G/128G v černé barvě.

Společně s tím jsem pořídil i ochranné prvky, jako je ochranné sklo, pouzdra. Jinymi slovy snaha o to, aby telefon vydržel užívání v dalších letech.

Nicméně, nebylo to pouze o pozitivech.

Pomerně rychle jsem si zvykl na nové prostředí, s ním však přišly i věci jinak mě neznámé a kolikrát i "podezřelé". Jelikož Xiaomi je čínského "návrháře" (rozlišuji zde, že produkt je vyrobený v Číně / ČLR, kdo jej však navrhuje je pro mě subjektivně další entita), byly zde i aplikace, které jsem k dispozici mít nechtěl, místy to bylo i podivné chování OS.

Je pravdou, že krátce po koupi přišla slíbená aktualizace na Android 13, nicméně tím jinak nedůležité aktualizace ze strany výrobce (v tomto případě považuji jak fyzicky výrobce HW, tak i dodavatel OS) ustaly. Vlastně jedinými aktualizacemi - dodám, že pouze akutními, řešícími konkrétní bezpečnostní problém - byly pouze bezpečnostní.

Příchod Garmin Pay

Časem jsem se rozhodl si pořídit i chyté hodinky, jelikož jsem v té době rozhodl vyzkoušet si placení právě chytrými hodinkami.

První pokus byl s Xiaomi Watch 2. Paradoxní volba pro tohoto výrobce byla pro "čistý" operační systém s možností Google Wallet/Pay přímo v hodinkách.
Nicméně nepovedlo se mi tohoto docilit, hodinky při pokusu nahlásily chybu a odmítly platební kartu přidat. Původní způsob užití bylo "zpohodlnit" placení (při nástupu do MHD, v obchodě...). Už v té době jsem se snažil najít myšlenku "Jak separovat platby od (relativně permanentně) k datům připojeného telefonu. Dá se říci, že o sledování fyzického pohybu bankovními institucemi jsem tušil, nicméně čím dál více jsem měl potřebu toto oddělit. V této době (duben 2025) mi "stačilo", kdyz na domácí Wi-Fi jednorázově sesynchronizuji peněženky.

Ač se mi Xiaomi Watch 2 líbily, vrátil jsem je zpět a rozhodl se jít cestou Garmin Forerunner 255, společně s Garmin Pay.

Záhy jsem zjistil, že hodinky od Garminu nejenže nabídly styl placení, který jsem hledal, ale také možnost si napsat vlastní program. Garmin jako takový má sice uzavřený systém, nicméně má k němu k dispozici SDK (Software Development Kit, sadu programu na vývoj softwaru pro daný produkt, zjednodušeno), což mi otevřelo cestu časem i k tomu si naprogramovat vlastní "statistiky" k jednomu mému oblíbenému sportu/relaxaci.

Lze tedy říci, že Garmin vyřešil nejen problém v té době pro mě aktuální, ale přidal mi do života i možnost žít aktivněji s možností si to sledovat.

Závěrem, mé současné hodinky mi doporucil člověk jménem Valentino Hesse, čímž mu za doporučení chci poděkovat i formou tohoto textu.

Nástup VPN

V pozdějších fázích, asi tak rok před změnou jsem ve zvýšeném měřítku začal užívat domácí VPN. Konkretne jsem na svoji Raspberry Pi 3. generace (verze B) nastavil WireGuard. Jelikož už v té době jsem měl na své DDNS i certifikát přes LetsEncrypt, vlastnictví VPN dávalo smysl, hlavně kvůli bezpečnosti týkající se bankovních aplikací.

S nástupem a nastavením VPN se trochu pojí i nová filozofie užívání telefonu. Na Xiaomi jsem si všiml tzv. "sekundárního prostoru", přeloženě jde o jiný profil/uživatele na stejném telefonu. Telefon s touto funkcionalitou se chová, jako kdyby byl právě čerstvě nainstalován / zapnut, de facto jde o stejné prostředí. Výhodou tohoto prostředí je možnost mít separované aplikace (takže třeba "normální" profil bez bankovních věcí a "bankovní" profil s bankovními aplikacemi různých bank, aplikace na nákup, popřípadě komunikátory se separovaným účtem).

S tímto se však pojí vyšší nároky na baterii telefonu, jelikož "klasický" Android / LineageOS / AOSP "neumí" ukončit profil, kdyz není potřebný. Znamená to tedy, že profil běží na pozadí i nadále (což není vždy nevýhoda). Nezřídka se stávalo, že i po jedné cestě do obchodu telefon dokázal "propálit" i 20 %. To sice na cestu tam i zpět stačilo, místy bylo však užívání s ohledem na maximální dostupnost náročné, což ne vždy bylo příjemné, zvláště při delších cestách.

Od ledna 2026 jsem začal řešit, čím Xiaomi Mi 11 Lite 5G nahradím.

Google Pixel 10 Pro XL

Postupne jsem začal zkoumat specifikace různých telefonu, co by daný přistroj měl umet. V zasade jsem měl tyto požadavky:

• Profiling (rozšířená forma "sekundárního prostoru" od Xiaomi, alespoň 2 profily), ideálně s možností daný profil ukončit,
• Always-On VPN (čili zablokování veškerého provozu, není-li VPN aktivní)
• Dual-SIM (historicky mám více SIM karet, které i do dnešního dne udržuji v "provozu")
• větší display (hodně dobré zkušenosti u Xiaomi Mi 11 Lite, který měl velký display)
• Na základě zkušeností u Xiaomi i dlouhodobá podpora výrobce/dodavatele OS.

Volbou po cca 4 měsících, rešeršovaného výzkumu i za pomocí jazykových modelů (Gemini, ChatGPT) v několika instancich (tímto mám na mysli opakované využití AI "Jaký telefon? Zde jsou mé požadavky"), tak i dotazování různých diskusních fór jsem dospěl ke konečnému závěru, kterým se stal Google Pixel 10. generace, verze Pro, velikost XL. Formalním jménem "Google Pixel 10 Pro XL 16/256 GB".

Telefon jsem se rozhodl po delším váhání objednat a jelikož jsem v té době měl i členství v jednom větším internetovém obchodě, definitivně jsem se rozhodl pro koupi, konkretně zelené verze "Jade", která mi "zapadala do korporatního stylu".

Lze říci, že další den mi byl telefon doručen a já se tak mohl začít radovat z nového stroje. Samozřejmě, pro maximalni ochranu nového stroje jsem i jako v případě Xiaomi Mi 11 Lite přiobjednal ochranné prvky.

GrapheneOS

Zjednoduším-li to, Pixel jsem si neobjednal pouze jako náhradu, ale i jako cilený důvod. Už asi 2 měsíce před koupí jsem měl povedomí o operačním systému "GrapheneOS", který oproti standardnímu Androidu nabízel i od základu přeimplementovanou funkcionalitu týkající se bezpečnosti a soukromí.

I to byla součást mého předchozího rešeršovaného vyhledavání, který OS chci použít. Ano, jinymi kandidaty byla i Motorola, nicméně některé funkce jako GrapheneOS nenabízela a byť s autory GrapheneOS uzavřela partnerství na oficiálního dodavatele hardware (tím rozumím telefony), první přístroje od Motoroly mající jako OS GrapheneOS nebudou k dispozici dříve, než v roce 2027.

Funkcionalita společná a rozdilná

Jednou z motivaci pro nový telefon byla i funkcionalita tzv. "Desktop Mode", která se předchozích verzích Androidu objevovala pouze od výrobce Samsung, tzv. "DeX". Jiná varianta - která hovořila i v prospěch dříve zmíněné Motoroly - byl "Smart Connect", nicméně důvodem pro Pixel (a později i GrapheneOS) byly aktualizace operačního systému samotného.

"Zakladní" Android

Desktop Mode

Základní Android - záleží zde i na hardwaru telefonu - funkcionalitu Desktop Mode umí. Předchůdcem jím bylo USB OTG (USB On-The-Go), což je možnost připojit USB flash do telefonu a zacházet s ním podobným stylem, jako kdyby šlo o počítač, stejně tak ovladaní přes klávesnici a myš.
Desktop Mode přidává DisplayPort Alt Mode přes USB-C, která vyjma datového/ovladacího přenosu přenáší i obrazové data možné zobrazit právě na externím monitoru. Je to umožněné tzv. propustností rozhranní, v tomto případě USB-C.

Aktualizce

Ač společnost Google má snahu o snižovaní tzv. e-waste (elektronický odpad), ne každý výrobce je tomu nakloneň. Ano, stále jde o výdělek, nicméně funguje-li telefon i po své moralní zastaralosti, výrobce zpravidla nechce poskytovat opravy jinak starým strojům.

Řada Pixel od Google má v tomto případě jinou filozofii, jelikož jde o "vlajkové lodě" pro Android, filozofie aktualizaci je zde jiná a mnohem otevřenější k tomu udržet stroj v aktuálním stavu, jelikož hardware je poměrně schopný.

Rozdíl GrapheneOS oproti "základu"

Co se GrapheneOS týče, většína funkcí je v tomto systému oproti zakladnímu OS Android zachována, nicméně GrapheneOS má zaměření hlavně na bezpecnost.
Velkým rozdilem je zde nejen Always-On VPN (formalně dostupná již od verze Androidu 7/8), nicméně společně s profilovaním (které oproti zakladu má funkci cíleného vypnutí) je možnost zablokovat veškerý síťový provoz, neběží-li VPN na pozadí.

Toto je především zajímavé, má-li uživatel domácí VPN.

Základní Android nabízí aplikacím tzv. "pískoviště", nicméně v GrapheneOS je této funckionalitě věnována mnohem větší pozornost po stránce zabezpečení a soukromí. Lze i v určitých ohledech aplikaci dovolit, kam bude moci pristupovat (což je hodně zajimavé u některých aplikací typu Messenger od Meta, stejně tak WhatsApp).

Dále je hodně zajimavé - především s užitím vypínatelného profilu - právě pro bankovní aplikace, kdy nejenže dovolíte této aplikací běžet explicitně pouze tehdy, kdy je potřeba, ale také donutíte její provoz jít třeba přes vaši domácí síť. Lze tak říci, že telefon máte elektronicky stále připojený přes síťový prvek, kterému důvěřujete (což o "datech" - datovému připojení přímo z telefonu platí dvojnásob).

Jinou variantou jsou i aplikace, které chcete mít "zamknuté" za specialním heslem a dostupné pouze a pouze majiteli přístroje.

Post Scriptum ke GrapheneOS

Mám-li v krátkosti udělat výtah, lze říci, že GrapheneOS jsem na svůj Pixel 10 Pro XL nainstaloval v podstatě hned druhý den po přijetí telefonu. Možnost vyzkoušet si zakladní OS přímo od Google jsem zde moc nevyužil, jelikož i přes vlastnictví nového telefonu (a s tím spojenym "WOW" efektem) jsem měl jasný záměr.

Nicméně musím dodat, že byl by nějaký závažnější problém s GrapheneOS, příručka, respektive postup pro instalaci "sériového" Androidu je velmi jednoduchá. V zásadě stačí upravený webový prohlížeč, USB kabel do počítače a trocha času. Je to tedy změna lehce zvrátitelná a dívám se tedy na GrapheneOS s "mentalitou" "Lze to vrátit, bude-li třeba".

Vedlejší efekt na předchozím telefonu

Ač jsem zmínil, že Pixel 10 Pro XL s GrapheneOS se stal hlavním "tažným koněm" mobilního života, otevřelo mi to možnost si "hrát" do té doby s "produkčním" telefonem od Xiaomi.

Měl jsem povědomí, že telefony od Xiaomi - nachází-li se na uzemí Evropské Unie - lze tzv. odemknout a nainstalovat jiný operační systém, v mem případě LineageOS / LOS. Je to forma AOSP, která v sobě nemá predinstalované aplikace od spolecnosti Google a i daného výrobce/návrháře. Jedná se tak o "De-Googled" software, místy i "de-bloated" systém.

Učinil jsem tak a telefon jsem začal užívat jako "záložní". Ač LineageOS podporu pro vypínání profilů nemá, Always-On VPN funkcionalita je zde také přitomna a lze ji užít podobným způsobem, jako na GrapheneOS.

Kdyz zmíním paradox, že Xiaomi Mi 11 Lite 5G po instalaci LineageOS "ožilo", nebudu daleko od pravdy. Pominu-li některé funkcionality řešitelné externě, telefon je plně funkční a stačilo by jej prodat s poznamkou "Toto nefunguje, je to záměr nikoliv můj, ale dodavatele systému".

Přislušenství k telefonum přidané

V kratkosti zde zminím i "obnovu" přislušenství pro oba přístroje. Puvodní, originální nabijecí adaptér pro Xiaomi postupně ztrácel na výkonu, rozhodl jsem se tedy - i s ohledem na pracovní Samsung Galaxy S25 - vyzkoušet si bezdrátové nabíjení, které jsem doteď neměl možnost využít.

Postupne volba padla na nejen GaN nabíjecí adaptér (vzhledem k dobrým referencím jsem užil "AlzaPower Ultímate X500 67W"), tak nabíjecí "puk" "AlzaPower WQT110" s podporou Qi2.

Jelikož jsem 3Dtiskař a 3Dmodelář, návrh a 3Dtisk stojánku přímo pro tento puk (zohledňuící proporce i slabší "MagSafe" u Samsungu Galaxy S25) byl logickym krokem.

Paradox s ohledem na bezpečnost aktualizovaného OS Android

Dostavám se tímto do poslední kapitoly, kde budu řešit a pokládat otázky, na které nejspíše nedostanu odpovědi.
Jakožto člověk IT-znalý (pro kontext, pracuji jako automation engineer, server administrator a on-call ve větší IT firmě) vnímám paradox, kdy výrobcem dodaný software má "certifikaci" pro určité funkce - v tomto případě třeba Google Wallet. Funkcionalitu Tap-n-Pay zde musím nahrazovat právě Garmin Pay.

Lze se na to i dívat z jiného úhlu pohledu, kdy platba hodinkami je paradoxně bezpečnější (NFC čip v hodinkách je jinak vypnut, zapíná se pouze, když uživatel funkci pro placení explicitně zapne v daný okamžik).

To platí jak pro GrapheneOS, tak pro LineageOS.

Telefony, obecně systémy (jak Android, tak i Debian, Arch Linux) se snažím držet v aktualním stavu a nezřídka si sám zajišťuji i aktualizace / opravy.

Otázka - kterou si kladu - je "Proc je alternativní systém jinak pravidelně aktualizovaný méně bezpečný, než zastaralý systém dodaný výrobcem, který nemá dalšího důvodu se o daný přistroj / hardware starat?"

Narážím tak na paradox, kdy i pravidelně aktualizovaný - ale necertifikovaný - software je bezpečnější, než jinak "certifikovaný" software od výrobce, který se rozhodl od určitého data aktualizace nedodavat. Pokud telefon nadále funguje, proč jeho funkcionalitu ořezávat, když by to samé mohl zvládat i dalších - dejme tomu - 5 let a tím tak ještě více "rozprostřít" náklady na iniciální pořízení?

Závěrem

GrapheneOS byl cílem snažení nejen o na to najít soukromí ve světě stále více a více připomínající 1984, ale také i tom, že jinak morálně zastaralé přístroje mají i nadále svůj důvod existovat.

Mým pohledem GrapheneOS - byť s určitými nedostatky, které jsem akceptoval - plní přesně to, co jsem od něj očekával, tedy nabídnout alespoň soukromí ve světě, kdy je každý krok monitorován.

Jako přidaným benefitem i nabídnout funkcionalitu, která by v roce rozmachu informačních technologií na začátku 21. stoleti mohla působit jako sci-fi - mít skoro plnohodnotný počítač ne v batohu, ale přímo v kapse.

Galerie

| Nabíjecí stojánek pro Qi2 wireless | "Dockovací" stanice s užitím 3Dtisku |
| | |

The post GrapheneOS, poznatky z užívání first appeared on Hard Wired.

Android Debug Bridge (ADB)

Android Debug Bridge (ADB) je mocný nástroj pro komunikaci s Android zařízeními, který každý pokročilý uživatel a vývojář by měl znát. V tomto článku si ukážeme praktické využití ADB na příkladu správy souborů v Meta Quest 3, ale principy platí pro všechna Android zařízení.

Co je ADB?

ADB je command-line nástroj, který umožňuje komunikaci mezi počítačem a Android zařízením přes USB nebo Wi-Fi. Původně byl vyvinut pro vývojáře, ale jeho využití sahá daleko za hranice programování.

Klíčové vlastnosti:

• Přenos souborů mezi počítačem a zařízením
• Vzdálené spouštění příkazů na Android systému
• Instalace a správa aplikací
• Debugging a logování
• Systémové úpravy bez nutnosti rootování

Instalace a nastavení

macOS/Linux:

# Homebrew (macOS)
brew install android-platform-tools

# Ubuntu/Debian
sudo apt install android-tools-adb

Windows:

Stáhněte Android SDK Platform Tools z oficiálních stránek Google.

Základní příkazy

Připojení a správa zařízení

# Zobrazení připojených zařízení
adb devices

# Restart ADB serveru (při problémech s připojením)
adb kill-server && adb start-server

Výstup:

List of devices attached
2G0YC5ZGCZ01G4    device

Přenos souborů

# Upload souboru do zařízení
adb push "local_file.mp4" /sdcard/Movies/

# Download souboru ze zařízení
adb pull /sdcard/Movies/video.mp4 ./

# Upload celé složky
adb push ./folder/ /sdcard/destination/

Správa souborů na zařízení

# Zobrazení obsahu složky
adb shell ls -la /sdcard/

# Vytvoření složky
adb shell mkdir /sdcard/NewFolder

# Smazání souboru
adb shell rm "/sdcard/Movies/video.mp4"

# Smazání složky
adb shell rm -rf /sdcard/OldFolder

Pokročilé techniky

Práce se soubory s mezerami v názvu

Při práci se soubory obsahujícími mezery je nutné používat správné uvozovky:

# Správně - s uvozovkami
adb shell "rm '/sdcard/Movies/Wonder Woman 1984.mp4'"

# Špatně - bez uvozovek (způsobí chybu)
adb shell rm /sdcard/Movies/Wonder Woman 1984.mp4

Batch operace

Pro hromadné operace můžete vytvořit bash skripty:

#!/bin/bash
files=(
    "video1.mp4"
    "video2.mkv"
    "video3.avi"
)

for file in "${files[@]}"; do
    echo "Uploading: $file"
    adb push "$file" /sdcard/Movies/
    if [ $? -eq 0 ]; then
        echo "✓ Success: $file"
    else
        echo "✗ Failed: $file"
    fi
done

Řešení běžných problémů

Unauthorized zařízení

Problém: adb devices zobrazuje unauthorized

Řešení:

1. Zkontrolujte USB debugging v Developer Options
2. Potvrďte RSA klíč v zařízení
3. Restartujte ADB server:

   adb kill-server && adb start-server

Resetování autorizačních klíčů

# Smazání starých klíčů a vygenerování nových
rm -f ~/.android/adbkey ~/.android/adbkey.pub
adb kill-server && adb start-server

Praktické příklady z reálného použití

Správa VR obsahu v Meta Quest 3

# Zobrazení dostupného místa
adb shell df -h /sdcard

# Přenos velkých VR videí
adb push "8K_VR_Video.mp4" /sdcard/Movies/

# Kontrola průběhu přenosu (v jiném terminálu)
adb shell du -sh /sdcard/Movies/

Zálohování herních dat

# Zálohování složky s herními daty
adb pull /sdcard/Android/data/com.game.package ./backup/

# Obnovení ze zálohy
adb push ./backup/com.game.package /sdcard/Android/data/

Optimalizace výkonu

Rychlost přenosu

Rychlost přenosu závisí na několika faktorech:

• USB kabel - používejte kvalitní USB 3.0+ kabely
• USB port - preferujte USB 3.0+ porty
• Velikost souborů - větší soubory = vyšší efektivita

Typické rychlosti:

• USB 2.0: ~20-25 MB/s
• USB 3.0: ~35-45 MB/s

Monitoring přenosu

# Zobrazení detailního průběhu
adb push -v "large_file.mp4" /sdcard/Movies/

# Kontrola volného místa před přenosem
adb shell "df -h /sdcard | grep sdcard"

Bezpečnostní aspekty

USB Debugging

• Aktivujte pouze při potřebě
• Používejte "Always allow from this computer" pouze u důvěryhodných počítačů
• Pravidelně kontrolujte autorizované počítače v Developer Options

Síťové připojení

# ADB přes Wi-Fi (vyžaduje USB aktivaci)
adb tcpip 5555
adb connect 192.168.1.100:5555

Závěr

ADB je nepostradatelný nástroj pro každého, kdo chce využít plný potenciál Android zařízení. Ať už spravujete soubory v Meta Quest 3, vyvíjíte aplikace, nebo jen chcete mít větší kontrolu nad svým zařízením, ADB vám poskytne potřebnou flexibilitu a sílu.

Klíčové takeaways:

• ADB funguje se všemi Android zařízeními
• Správné uvozování je kritické pro soubory s mezerami
• Batch skripty šetří čas při hromadných operacích
• Bezpečnost by měla být vždy prioritou

Pokročilé příkazy pro power users

Systémové informace

# Informace o zařízení
adb shell getprop ro.product.model
adb shell getprop ro.build.version.release

# Stav baterie
adb shell dumpsys battery

# Využití úložiště
adb shell df -h

# Spuštěné procesy
adb shell ps | grep com.oculus

Správa aplikací

# Seznam nainstalovaných aplikací
adb shell pm list packages

# Instalace APK
adb install app.apk

# Odinstalace aplikace
adb uninstall com.package.name

# Vymazání dat aplikace
adb shell pm clear com.package.name

Logování a debugging

# Zobrazení logů v reálném čase
adb logcat

# Filtrování logů podle tagu
adb logcat -s "MyApp"

# Uložení logů do souboru
adb logcat > device_logs.txt

Automatizace s skripty

Bash skript pro hromadné stahování

#!/bin/bash
# download_vr_content.sh

DEST_DIR="/Volumes/ExternalDrive/VR/"
QUEST_DIR="/sdcard/Movies/"

# Vytvoření cílové složky
mkdir -p "$DEST_DIR"

# Získání seznamu souborů
echo "Scanning Quest for video files..."
adb shell "find $QUEST_DIR -name '*.mp4' -o -name '*.mkv'" | while read file; do
    filename=$(basename "$file")
    echo "Downloading: $filename"

    # Stažení s progress barem
    adb pull "$file" "$DEST_DIR"

    if [ $? -eq 0 ]; then
        echo "✓ Downloaded: $filename"
        # Volitelně smazat ze zařízení po úspěšném stažení
        # adb shell "rm '$file'"
    else
        echo "✗ Failed: $filename"
    fi
done

echo "Download complete!"

Python skript pro monitoring

#!/usr/bin/env python3
import subprocess
import json
import time

def get_device_info():
    """Získání informací o připojeném zařízení"""
    try:
        result = subprocess.run(['adb', 'devices'],
                              capture_output=True, text=True)
        return result.stdout
    except Exception as e:
        return f"Error: {e}"

def get_storage_info():
    """Kontrola dostupného místa"""
    try:
        result = subprocess.run(['adb', 'shell', 'df', '-h', '/sdcard'],
                              capture_output=True, text=True)
        return result.stdout
    except Exception as e:
        return f"Error: {e}"

def monitor_transfer(file_path):
    """Monitoring průběhu přenosu"""
    print(f"Monitoring transfer of: {file_path}")

    while True:
        try:
            result = subprocess.run(['adb', 'shell', 'ls', '-la', file_path],
                                  capture_output=True, text=True)
            if result.returncode == 0:
                print(f"Transfer in progress... {time.strftime('%H:%M:%S')}")
            else:
                print("Transfer completed or file not found")
                break
        except KeyboardInterrupt:
            print("\nMonitoring stopped")
            break

        time.sleep(5)

if __name__ == "__main__":
    print("ADB Device Monitor")
    print("=" * 30)
    print(get_device_info())
    print(get_storage_info())

Troubleshooting guide

Časté chyby a jejich řešení

Debug příkazy

# Kontrola ADB verze
adb version

# Verbose výstup pro debugging
adb -v devices

# Restart s debug informacemi
adb kill-server
ADB_TRACE=all adb start-server

Best practices

1. Organizace souborů

# Vytvořte strukturu složek
adb shell mkdir -p /sdcard/Media/{Movies,VR,Games}
adb shell mkdir -p /sdcard/Backups/{Apps,Data}

2. Pravidelné zálohování

# Automatické zálohování důležitých dat
adb pull /sdcard/Android/data/important.app ./backups/$(date +%Y%m%d)/

3. Monitoring výkonu

# Sledování využití CPU a paměti
adb shell top -n 1
adb shell cat /proc/meminfo

Integrace s dalšími nástroji

Použití s Git

# Automatické commitování záloh
git add backups/
git commit -m "ADB backup $(date)"

Kombinace s rsync

# Synchronizace s lokálním úložištěm
adb pull /sdcard/DCIM/ ./photos/
rsync -av ./photos/ /backup/quest-photos/

The post Android Debug Bridge (ADB) first appeared on Hard Wired.

Bluetooth bezpečnostní rizika: Jak se chránit před skrytými hrozbami

Bluetooth se stal součástí našeho každodenního života – od připojení sluchátek po synchronizaci chytrých hodinek. Tato neviditelná technologie však skrývá vážná bezpečnostní rizika, která mohou ohrožovat naše osobní data i soukromí.

Skrytá hrozba v kapse

Bluetooth technologie dnes běží na miliardách zařízení po celém světě. Její všudypřítomnost a schopnost navazovat spojení na dálku z ní však činí atraktivní cíl pro útočníky. Na rozdíl od tradičních kybernetických útoků, které vyžadují aktivní účast uživatele, mohou Bluetooth exploity zasáhnout bez jakékoliv interakce ze strany oběti.

Bezpečnostní experti varují, že i zdánlivě neškodné zapnutí Bluetooth může vystavit zařízení útoku. Stačí být ve špatnou chvíli na špatném místě – například v kavárně, na letišti nebo na zastávce.

BlueBorne a BrakTooth: Reálné hrozby současnosti

Mezi nejznámější Bluetooth exploity patří BlueBorne, poprvé detailně popsaný v roce 2017 výzkumníky ze společnosti Armis Labs. Tento typ útoku umožňuje útočníkovi získat přístup k zařízení přes aktivní Bluetooth bez nutnosti párování nebo jakékoliv akce uživatele.

BlueBorne původně ohrožoval přes 8,2 miliardy Bluetooth zařízení na platformách Android, iOS, Linux i Windows. Ačkoliv byl v mnoha systémech opraven, princip útoku zůstává aktuální i v roce 2025.

Novějším příkladem je BrakTooth – skupina zranitelností zveřejněná v roce 2021, která dokázala způsobit vše od odmítnutí služby až po vzdálené spuštění kódu na cílových zařízeních.

Jak útoky fungují

Problém nespočívá v konkrétních aplikacích, ale v samotném Bluetooth stacku – způsobu, jak zařízení spravují bezdrátové spojení. Pokud obsahuje bezpečnostní díru, může útočník pomocí speciálně upraveného signálu:

• Získat neautorizovaný přístup do systému
• Spustit škodlivý kód
• Proniknout na další zařízení v okolí
• Ukrást citlivá data

Dosah útoku je omezen pouze dosahem Bluetooth signálu – typicky 10 až 30 metrů.

Proč jste stále v ohrožení

Trvalá připravenost: Většina uživatelů má Bluetooth zapnutý 24/7 kvůli připojeným sluchátkům, chytrým hodinkám nebo dalším gadgetům. Tato permanentní dostupnost poskytuje útočníkům neustálou příležitost.

Zastaralé systémy: Miliony zařízení v Česku stále běží na starších verzích Androidu (verze 8 a nižší) nebo používají levnější hardware s neaktualizovaným Bluetooth softwarem.

Zero-click útoky: Vývoj směřuje k útokům, které nevyžadují žádnou interakci uživatele – Bluetooth je pro tyto techniky ideálním nosičem.

Praktická ochrana

Efektivní ochrana proti Bluetooth útokům nevyžaduje technické znalosti, ale důslednost:

Vypínejte Bluetooth, když ho nepotřebujete – zejména v noci a na veřejných místech. Znemožníte tím útočníkům vyhledávat vaše zařízení.

Udržujte systém aktuální – bezpečnostní záplaty jako ty pro BlueBorne jsou účinné pouze u aktualizovaných zařízení.

Omezte viditelnost – zkontrolujte nastavení, aby vaše zařízení nebylo trvale viditelné pro ostatní.

Kontrolujte oprávnění aplikací – nepovolujte přístup k Bluetooth aplikacím, které ho skutečně nepotřebují.

Buďte opatrní při párování – nepřipojujte se k neznámým zařízením, která mohou napodobovat legitimní hardware.

Používejte Bluetooth selektivně – zvažte jeho použití pouze doma nebo v autě, nikoliv na veřejnosti.

Závěr

Bluetooth není nutné se bát, ale stejně jako u Wi-Fi nebo hesel platí základní pravidlo: bezpečnost začíná u správného nastavení a rozumného používání. S rostoucím počtem připojených zařízení a vývojem nových útočných technik se preventivní opatření stávají klíčovými pro ochranu našich digitálních životů.

Jednoduché změny v chování a nastavení mohou dramaticky snížit riziko a zajistit, že Bluetooth zůstane užitečným nástrojem, nikoliv bezpečnostní hrozbou.

The post Bezpečnostní rizika Bluetooth first appeared on Hard Wired.

Nulování počítadla kartáčkové hlavice Philips SoniCare

Jednoduchý návod pro každou lamu. V minulém článku jsme si řekli jak probíhalo reverzní inženýrství zubního elektrického kartáčku Philips SoniCare. Nyní si ukážeme jen jednoduchý ale podrobný návod jak na to. Zvládne to opravdu každý.

Nejprve budete potřebovat aplikaci NFC Tools. Jedná se o aplikaci pro práci s NFC čipem který je umístěn v samotné hlavici kartáčku. Aplikace je k dispozici buď pro iOS nebo Android.

Teď musíte najít UID hlavice kartáčku. K tomu použijte aplikaci NFC Tools. Využijeme funkci “Číst” Tady zjistíme základní informace. Pokud chcete vidět kompletní výpis karty, jdeme do menu Jiné/Others - Read - Edit memory Tím získáte dlouhý seznam adres a jejich dat. Najdeme tam i své UID v prvních dvou řádcích.

Ve výše uvedeném snímku obrazovky je UID 04:03:47:7A:22:70:81. (Poslední bajt na první adrese je ignorován, protože se jedná o hodnotu BCC0 a nikoli část UID.)

Teďbudeme potřebovat kód produktu. Ten je vytištěn na spodní straně kovového ráfku na základně hlavy:

Nebo to najdete zakódováno v ASCII na adresách 21 až 23 (ignorujte první 2 byty).

Teď máme všechny potřebná data k vygenerovaní hesla pro odemčení a vymazaní čítače/počítadla doby používání kartáčkové hlavice. Přejdeme na stránku SonicareGenerator a vygenerujeme jedinečný příkaz který obsahuje příkaz pro nastavení původní hodnoty a heslo (1B:61:F0:A5:0F,A2:24:00:00:02:00) pro reset hlavice kartáčku:

Generátor hesel SONICARE

V NFC Tools aplikaci, přejdeme na “Advanced NFC commands” zadáme svůj konkrétní příkaz který nám vygeneroval Password Generátor do pole “Data” a odešlete jej do hlavice kartáčku. Hlava pro resetování získá původní hodnoty čítače/počítadla a můžeme používat další periodu. Toto můžeme opakovat do nekonečna ale doporučuji to u jedne čistíci hlavice udělat max 2x aby štětiny neztratili svoji pružnost a funkci.

Svět by byl lepší místo, kdyby nenažrané korporace nešly jen po zisku.

The post Nulování počítadla kartáčkové hlavice Philips SoniCare first appeared on Hard Wired.

Dneska se podíváme jak zprovoznit Bluetooth na ESP32. Cílem je umožnit telefonu připojit se na naše Bluetooth zařízení a odpovídat na specifické zprávy. Jako vývojové prostředí použijeme PlatformIO.

ESP32

Pro projekt použijeme ESP32 Development Board z Aliexpressu. V době psaní článku stojí zhruba 120CZK.

platformio.ini

Konfigurační soubor pro projekt.

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
monitor_speed = 115200

main.cpp

Jako základ kódu jsem použil výborný článek ESP32 a Bluetooth Low Energy (BLE) z Drátek Návody a provedl úpravy pro potřeby projektu. Pro zjednodušení nejprve celý kód projektu. Rozbor bude pokračovat.

#include <Arduino.h>

// Bluetooth knihovny
#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

// inicializace modulu z knihovny
BLECharacteristic *pCharacteristic;

// proměnná pro kontrolu připojených zařízení
bool deviceConnected = false;

// proměnná pro ukládání přijaté zprávy
std::string receivedMessage;

// proměnná pro zprávu pro odeslání
String out = "";

// definice unikátních ID pro různé služby,
// pro vlastní UUID využijte generátor
// https://www.uuidgenerator.net/
#define SERVICE_UUID "6E400001-B5A3-F393-E0A9-E50E24DCCA9E"
#define CHARACTERISTIC_UUID_RX "6E400002-B5A3-F393-E0A9-E50E24DCCA9E"
#define CHARACTERISTIC_UUID_TX "6E400003-B5A3-F393-E0A9-E50E24DCCA9E"

int compareCommand(std::string message, String command)
{
    String converted = String(message.c_str());
    converted.trim();
    converted.toLowerCase();

    return converted == command;
}

void setOutputMessage(String message)
{
    out = message;
    out += "\n";
}

void clearOutputMessage()
{
    out = "";
}

void sendMessage()
{
    char message[out.length() + 1];
    out.toCharArray(message, out.length() + 1);

    // přepsání zprávy do BLE služby
    pCharacteristic->setValue(message);

    // odeslání zprávy skrze BLE do připojeného zařízení
    pCharacteristic->notify();
}

// třída pro kontrolu připojení
class MyServerCallbacks : public BLEServerCallbacks
{
    // při spojení zařízení nastav proměnnou na log1
    void onConnect(BLEServer *pServer)
    {
        deviceConnected = true;
    };
    // při odpojení zařízení nastav proměnnou na log0
    void onDisconnect(BLEServer *pServer)
    {
        deviceConnected = false;
        pServer->getAdvertising()->start();
    }
};

// třída pro příjem zprávy
class MyCallbacks : public BLECharacteristicCallbacks
{
    // při příjmu zprávy proveď následující
    void onWrite(BLECharacteristic *pCharacteristic)
    {
        // načti přijatou zprávu do proměnné
        receivedMessage = pCharacteristic->getValue();

        // pokud není zpráva prázdná, vypiš její obsah
        // po znacích po sériové lince
        // a pokud přijde očekávaný příkaz pošli odpověď
        if (receivedMessage.length() > 0)
        {
            Serial.print("Prijata zprava: ");
            for (int i = 0; i < receivedMessage.length(); i++)
            {
                Serial.print(receivedMessage[i]);
            }
            Serial.println();

            if (compareCommand(receivedMessage, "ahoj"))
            {
                setOutputMessage("No nazdar");
            }
        }
    }
};

void setup()
{
    // zahájení komunikace po sériové lince
    // rychlostí 115200 baud
    Serial.begin(115200);

    // inicializace Bluetooth s nastavením jména zařízení
    BLEDevice::init("ESP32 BLE");

    // vytvoření BLE serveru
    BLEServer *pServer = BLEDevice::createServer();
    pServer->setCallbacks(new MyServerCallbacks());

    // vytvoření BLE služby
    BLEService *pService = pServer->createService(SERVICE_UUID);

    // vytvoření BLE komunikačního kanálu pro odesílání (TX)
    pCharacteristic = pService->createCharacteristic(
        CHARACTERISTIC_UUID_TX,
        BLECharacteristic::PROPERTY_NOTIFY);
    pCharacteristic->addDescriptor(new BLE2902());

    // vytvoření BLE komunikačního kanálu pro příjem (RX)
    BLECharacteristic *pCharacteristic = pService->createCharacteristic(
        CHARACTERISTIC_UUID_RX,
        BLECharacteristic::PROPERTY_WRITE);
    pCharacteristic->setCallbacks(new MyCallbacks());

    // zahájení BLE služby
    pService->start();

    // zapnutí viditelnosti BLE
    pServer->getAdvertising()->start();
    Serial.println("BLE nastaveno, ceka na pripojeni..");
}

void loop()
{
    if (deviceConnected == true && out.length() > 0)
    {
        sendMessage();
        delay(100);
        clearOutputMessage();
    }

    // pauza před novým během smyčky
    delay(1000);
}

Rozbor kódu

#include <Arduino.h>

// Bluetooth knihovny
#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

Knihovny potřebné pro obsluhu Bluetooth.

BLECharacteristic *pCharacteristic;

Inicializace modulu knihovny pro práci s Bluetooth.

bool deviceConnected = false;

Indikace, že je zařízení připojeno k našemu Bluetooth zařízení.

std::string receivedMessage;

Proměnná pro uložení zprávy, kterou pošleme našemu Bluetooth zařízení.

String out = "";

Proměnná pro uložení odchozí zprávy.

#define SERVICE_UUID "6E400001-B5A3-F393-E0A9-E50E24DCCA9E"
#define CHARACTERISTIC_UUID_RX "6E400002-B5A3-F393-E0A9-E50E24DCCA9E"
#define CHARACTERISTIC_UUID_TX "6E400003-B5A3-F393-E0A9-E50E24DCCA9E"

Bluetooth se skládá z jednotlivých služeb pro které je mít potřeba vygenerované unikátní identifikátory.

int compareCommand(std::string message, String command)
{
    String converted = String(message.c_str());
    converted.trim();
    converted.toLowerCase();

    return converted == command;
}

Naše Bluetooth zařízení se chová jako server. Pokud mu pošlete zprávu/příkaz, který rozpozná, tak odpoví zpět. Příchozí zpráva se ukládá do proměnné typu std::string. Zprávu je potřeba očistit od bílých znaků, normalizovat (převést na malá písmena ) a porovnat s příkazem, který chceme provést. Tady byl lehce zádrhel, protože vhodné metody obsahuje zase String objekt. Céčko/C++ jsem provozoval naposledy na vysoké pro školní projekty a už tam jsem většinu věcí řešil v Pythonu. Jsem už prostě zmlsaný moderními programovacími jazyky. Mé řešení asi nebude nejefektivnější, ale je lehce čitelné a funguje.

TLDR: compareCommand vezme příchozí zprávu, očistí od bordelu, porovná s námi zadaným příkazem a vrátí hodnotu porovnání.

void setOutputMessage(String message)
{
    out = message;
    out += "\n";
}

Pomocná funkce pro nastavení odchozí zprávy.

void clearOutputMessage()
{
    out = "";
}

Pomocná funkce pro vyčistění proměnné po odeslání zprávy.

void sendMessage()
{
    char message[out.length() + 1];
    out.toCharArray(message, out.length() + 1);

    pCharacteristic->setValue(message);

    pCharacteristic->notify();
}

Funkce zapouzdřující odeslání zprávy. Převede zprávu na pole znaků, předá Bluetooth knihovně a pomocí metody notify odešle na připojené zařízení.

class MyServerCallbacks : public BLEServerCallbacks
{
    void onConnect(BLEServer *pServer)
    {
        zarizeniPripojeno = true;
    };

    void onDisconnect(BLEServer *pServer)
    {
        zarizeniPripojeno = false;
        pServer->getAdvertising()->start();
    }
};

Během testů se objevil problém s opětovným připojením. Když se telefon odpojil od Bluetooth serveru, nešlo se znovu připojit. Pomohl jen restart ESPčka. Dle různých zdrojů za to můžou různé verze knihoven. Pokud přidáme při odpojení zařízení pServer->getAdvertising()->start();, který začne propagovat náš Bluetooth server do prostoru, opětovné připojení funguje.

Třída zapouzdřující callbacky pro náš Bluetooth server. Pokud se zařízení připojí/odpojí nastaví proměnnou deviceConnected.

class MyCallbacks : public BLECharacteristicCallbacks
{
    void onWrite(BLECharacteristic *pCharacteristic)
    {
        receivedMessage = pCharacteristic->getValue();

        if (receivedMessage.length() > 0)
        {
            Serial.print("Prijata zprava: ");
            for (int i = 0; i < receivedMessage.length(); i++)
            {
                Serial.print(receivedMessage[i]);
            }
            Serial.println();

            if (compareCommand(receivedMessage, "ahoj"))
            {
                setOutputMessage("No nazdar");
            }
        }
    }
};

Třída zapouzdřující callback pro příjem zprávy. Při příchozí zprávě nenulové délky se jako první vypíše do sériové konzole. Následně proběhne porovnání jestli obsahuje, pro nás známý, příkaz. V našem případě ahoj. Pokud ano, tak odpoví No nazdar.

setup()

Serial.begin(115200);

Nastavení rychlostí komunikace přes sériovou linku. Musí být stejné jako v platformio.ini.

BLEDevice::init("ESP32 BLE");

Inicializace Bluetooth s nastavením jména, na které se bude dát z telefonu připojit.

BLEServer *pServer = BLEDevice::createServer();
pServer->setCallbacks(new MyServerCallbacks());

Vytvoření Bluetooth serveru. Nastavíme callbacky pro detekci připojení/odpojení zařízení pomocí třídy nadefinované výše.

BLEService *pService = pServer->createService(SERVICE_UUID);

Vytvoření Bluetooth služby.

pCharacteristic = pService->createCharacteristic(
        CHARACTERISTIC_UUID_TX,
        BLECharacteristic::PROPERTY_NOTIFY);
pCharacteristic->addDescriptor(new BLE2902());

Vytvoření komunikačního kanálu pro odesílání zpráv.

BLECharacteristic *pCharacteristic = pService->createCharacteristic(
        CHARACTERISTIC_UUID_RX,
        BLECharacteristic::PROPERTY_WRITE);
pCharacteristic->setCallbacks(new MyCallbacks());

Vytvoření kanálu pro příjem zpráv. Nastavujeme callback pro příjem nadefinovaný výše.

pService->start();

Nastartování Bluetooth služby.

pServer->getAdvertising()->start();
Serial.println("BLE nastaveno, ceka na pripojeni..");

Zviditelnění pro ostatní zařízení.

loop()

if (deviceConnected == true && out.length() > 0)
{
    sendMessage();
    delay(100);
    clearOutputMessage();
}

delay(1000);

Loop smyčka každou sekundu zkontroluje jestli je zařízení připojené k našemu Bluetooth serveru a jestli existuje zpráva co by šla odeslat. Pokud jsou obě podmínky splněny odešleme zprávu a vyčistíme data.

TLDR

Bluetooth server čeká na zp rávy. Pokud přijde zpráva, která obsahuje známy příkaz, nastaví se příslušné proměnné. Smyčka loop každou sekundu zkontroluje jestli jsou příslušné proměnné pro odchozí zprávu a pokud ano odešle zprávu na připojené zařízení. No raketová věda to teda není.

Serial Bluetooth Terminal

Kód je zkompilovaný, nahraný na ESP32 a běží. Teď je potřeba začít s naším Bluetooth zařízením komunikovat. Pro Android jde použít výbornou aplikaci Serial Bluetooth Terminal. Umí to co potřebujeme. Připojit se k zařízení, posílat a obdržet zprávy.

Po instalaci se v obrazovce Devices přepněte do tabu Bluetooth LE a naskenujte zařízení. Objeví se naše ESPčko. Kliknutím na něj se připojíte.

Pokud připojení proběhne v pořádku zobrazí se následující.

Po odeslání zprávy ahoj dostaneme odpověď.

Závěr

Prezentovaný kód je takové minimum, bez hlubší znalosti Bluetooth a jeho vnitřního fungování, které ověřuje koncept ESP32 jako Bluetooth serveru odpovídajícího na příkazy.

Happy coding.

The post ESP32 Bluetooth Server first appeared on Hard Wired.