Android als Barcode-Scanner

Ich melde mich jetzt auch mal wieder zu Wort. Der Titel ist nicht ganz eindeutig, ich will euch hier jetzt nicht den ZXing-Barcode-Scanner vorstellen oder so, sondern ich habe etwas kleines gebastelt, das vielleicht sonst noch jemand nützlich finden könnte.

Und zwar ein kleines Script für den Scripting Layer for Android, mit dem die gescannten Barcodes an einen Client im Netzwerk gesendet werden. Das Script gibt es weiter unten (bzw. nach dem Break) auch als QR-Code, um es direkt mit SL4A abscannen zu können.

import android
import socket

HOST = ''
PORT = 38174

droid = android.Android()

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind((HOST, PORT))
sock.listen(1)

droid.makeToast('Waiting for client...')
conn, addr = sock.accept()
droid.makeToast('Client %s:%d connected' % addr)

while True:
	code = droid.scanBarcode()
	if not code:
		break
	conn.send('%s\n' % code.result['extras']['SCAN_RESULT'])

conn.close()

Als Client lässt sich dieser Bash-Einzeiler verwenden:

nc $PHONE_IP 38174 | while read code; do xvkbd -text "$(echo -n $code | head -c -1)\r"; done

Read more…

_http._tcp IN SRV 0 0 80 www1

So, oder so ähnlich, würden DNS-Records für Websites aussehen, wenn die Browser es unterstützen würden. Aber nein, im Moment unterstützt es kein einziger. Und das, obwohl die entsprechenden Bugs seit Ewigkeiten offen sind:

E-Mail (SMTP) nutzt den MX-Record. Mach ja auch Sinn, wobei sich auch hier prinzipiell auch SRV-Records verwenden lassen könnten, ist aber halt so. Für Jabber und SIP werden in der Regel SRV-Records verwendet und auch die meisten LDAP- und Kerberos-Clients unterstützen sie. Doch bei HTTP ist das anders. Alle Webbrowser lösen nur A/AAAA/CNAME-, aber keine SRV-Records auf.

Und wo ist jetzt mein Problem? Funktioniert doch alles! Ja toll, funktioniert. Aber kann mir mal bitte jemand von diesen Typen, die rumrennen und rumschreien, dass die http://www.-Subdomain doch scheiße ist, erklären, wieso ich für die Domain (also direkt example.com.) einen A-Record auf den Webserver anlegen sollte? Wieso? Macht doch keinen Sinn. Warum ausgerechnet der Webserver und nicht der Jabber-Server? Warum ist der Webserver wichtiger? Domains lassen sich auch für was anderes verwenden, als für das Hosten von Websites, ja?

Abgesehen von dem Unsinn, für einen Service (statt für einen Host) A/AAAA-Records anzulegen bietet so ein SRV-Record noch ein paar tolle Vorteile. A/AAAA sind halt eben für Hosts gedacht und nicht für Services. Im Gegensatz zu SRV-Records bieten sie nämlich keine Unterstützung für Prioritäten und Gewichte. Damit lassen sich für HTTP-Services durchaus interessante Dinge machen. Also im Prinzip genau das, was man mit MX-Records schon seit Jahren für E-Mail machen kann:

_http._tcp IN SRV 0 30 www1
_http._tcp IN SRV 0 70 www2
_http._tcp IN SRV 5 0 www-fallback

Also liebe Browserentwickler. Implementiert endlich SRV-Records für HTTP (und andere Protokolle, die ihr unterstützt) und hört auf zu heulen. Die paar Milisekunden, die für einen SRV-Lookup draufgehen, sind nur so lange verschwendet, bis die meisten Domains entsprechende Records haben. Und es gibt ja eigentlich auch keinen Grund, der dagegen spricht, diese anzulegen. Also, ab in den Texteditor, programmieren, testen und committen. Danke!

Der Google-Trojaner

Oder: Warum ich nicht glaube, dass Google nur Gutes will.

In diesem Beitrag geht es um meine Meinung zu Googles Möglichkeit, Apps auf Android-Smartphones aus der Ferne zu deinstallieren. Wer das nicht mitbekommen hat, findet hier weitere Informationen.

Wie wahrscheinlich schon durch die Überschrift deutlich wurde, finde ich das ganze eher weniger berauschend. Und zwar hat das ganze einen sehr einfachen Grund:

Wenn Google diese Backdoor nur dazu nutzen möchte, Schadsoftware von Android-Geräten zu entfernen, dann gäbe es einen viel einfacheren Weg: Eine einfache Benachrichtigung, die den Benutzer darauf hinweist, dass er Malware installiert hat und ob er ihm die Möglichkeit bietet, diese zu deinstallieren.

Dann bleibt da noch die Frage, wofür Google diese Backdoor möglicherweise nutzen möchte oder im schlimmsten Fall eventuell sogar schon nutzt. Hier habe ich keine konkreten Anhaltspunkte und möchte Google deshalb auch keine Vorwürfe machen und hoffe einfach mal das Beste. Trotzdem bleibt ein mulmiges Gefühl.

Und wo wir schon beim Thema sind: Was ich auch nicht gerade positiv finde, ist, dass mir keine wirkliche Alternative zu den Google-Diensten auf Android bekannt ist, die man auf eigener Hardware betreiben kann oder die die Daten komplett verschlüsselt auf potentiell unsicheren Servern speichert. Und das finde ich sehr schade, da doch gerade Android die offene Plattform ist, mit der das ganze doch relativ einfach möglich sein sollte.

Wer möchte mein Retter sein und die entsprechenden Andwendungen schreiben? Es wäre jedenfalls großartig. Aber wer nicht ganz so viel Zeit investieren möchte, könnte mir ja erklären, warum es so, wie es im Moment ist, besser ist, als wenn der Benutzer noch gefragt wird, ob er die App deinstallieren will.

Android 3.0 Honeycomb Preview

Sieht sehr interessant, aber auch sehr ressourcenhungrig aus. Will mir jemand ein Honeycomb-Tablet schenken?

KenFM über WikiLeaks

(via scusiblog.org)

Klausurenzeit

Wohl die schönste Zeit des Jahres, oder? Noch drei wunderschöne Klausuren, wovon zwei doch super einfach sind: Deutsch und Wirtschaft. Und dann noch eine extrem schwere in Mathe.

So, wer hat das jetzt geglaubt und die unsichtbaren Ironie-Tags übersehen? Mathe ist einfach, für Deutsch und Wirtschaft suche ich noch Freiwillige, die für mich schreiben wollen. Wer Interesse hat, meldet sich bitte in den Kommentaren.

Deutsch wird abenteuerlich (obwohl wir keine Erlebniserzählung schreiben dürfen… leider… :-D) und Wirtschaft wird bestimmt ganz toll, weil wir dieses Jahr schon gefühlt 300 Blätter bekommen und ich da nicht mehr so wirklich durchblicke. Abgesehen davon ist das sowieso – wie nenn ich es – interessant. Ein Viereck mit sechs Ecken und das soll dann auch noch magisch sein. Das kann doch nicht funktionieren.

Nebenbei eine Frage an meinen Sozialkundelehrer: Wie schafft man es, eine Klausur, die wir Mitte November geschrieben haben, immer noch nicht rauszugeben?

[Update] Ich hab Deutsch hinter mir und ich lebe noch.

6.8 + 5.2 = 13

Kein Wunder, dass wir da so gut abschneiden…

Wiederauferstehung

Oder so. Nachdem ich mal wieder bloggen will und auch diverse andere Blog-Hosting-Serivces ausprobiert habe (Tumblr, Posterous, …) und mit keinem so wirklich glücklich war, werde ich eben dieses Blog wiederbeleben. Als Zeichen des Neuanfangs habe ich gleich mal ein neues Theme ausgesucht. Diesmal wird natürlich hoffentlich alles besser. ;-)

Android SDK unter Debian Squeeze

Wie ihr vielleicht mitbekommen habt, habe ich mir ein Smartphone gekauft, auf dem Android läuft. Und dafür will man dann ja auch vielleicht Software für entwickeln, auch wenn man das in Java tun muss, führt ja kein Weg dran vorbei. Also SDK geladen und gespielt. Wollte ich zumindest, hat aber nicht komplett so funktioniert, wie ich wollte. Hauptproblem war eben das verwenden von USB-Debugging zusammen mit meinem Samsung Galaxy S. Deshalb will ich hier jetzt mal die Schritte erläutern, die es für eine saubere Installation gebraucht hat. Es hat etwa 3 Tage gedauert, bis ich das so zusammengebastelt bekommen habe, da sämtliche Lösungen, die ich im Internet gefunden habe, nicht funktionierten.

  1. Zuerst legen wir eine Gruppe an, in die alle Benutzer kommen, die über den SDK Zugriff auf angeschlossene Android-Geräte bekommen sollen und fügen diese auch gleich hinzu (also in meinem Fall julian). Achtet darauf, dass die GID noch frei ist. Ihr müsst euch dann irgendwann noch neu einloggen, da die neue Gruppe erst dann aktiv ist.

    addgroup --gid 123 androidsdk
    adduser julian androidsdk

  2. Dann legen wir direkt die udev-Regel für das Gerät an. Dazu benötigen wir die Vendor- und Product-ID, die in der Ausgabe von lsusb enthalten sind. Diese sieht bei meinem Galaxy S zum Beispiel so aus:

    Bus 003 Device 055: ID 04e8:681c Samsung Electronics Co., Ltd Galaxy Portal/Spica Android Phone

    Die 4-stellige Hexadezimalzahlen vor und nach dem Doppelpunkt sind für uns interessant. Die erste ist die Vendor-ID und die zweite die Product-ID. Daraus legen wir folgende udev-Regel an und speichern sie in /etc/udev/rules.d/51_android.rules (natürlich müsst ihr für andere Geräte die IDs anpassen):

    BUS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="681c", GROUP="androidsdk", MODE="0660"

    Dann noch schnell die Regeln neu laden:

    udevadm control --reload-rules

  3. Nun laden wir den SDK herunter, enpacken ihn und setzen die Rechte richtig:

    # wget http://dl.google.com/android/android-sdk_r06-linux_86.tgz
    # tar xvzf android-sdk_r06-linux_86.tgz
    # mv android-sdk-linux_86/ /opt/android-sdk
    # chown -R root:androidsdk /opt/android-sdk/
    # chmod -R ug+rw /opt/android-sdk/

  4. Als nächstes müsst ihr /opt/android-sdk/tools zu eurem $PATH hinzufügen. Entweder ihr macht das temporär mit

    $ export PATH=$PATH:/opt/android-sdk/tools

    oder dauerhaft, indem ihr

    PATH=$PATH:/opt/android-sdk/tools

    zu eurer ~/.bashrc hinzufügt und diese neu ladet:

    source ~/.bashrc

  5. Wenn jetzt alles funktioniert, sollte beim Ausführen von adb devices euer Smartphone auftauchen (wenn nicht, habt ihr das gleiche Problem, wie ich: Ihr findet im Internet keine Lösung):

    $ adb devices
    List of devices attached
    900028b91393 device

Pencil vs. Camera

Pencil Vs Camera - 9

Pencil Vs Camera - 4

Pencil Vs Camera - 7

Aus dem Flickr-Set Pencil Vs Camera! von Ben Heine. Sehr cool, wie ich finde.

(via alexvetter.de)