In folgendem zeige ich dir, wie dies relativ schnell und einfach möglich ist :)

Der Einfachheit halber habe ich mir in /tmp einen Ordner angelegt, in den ich mir die Repos, die ich umziehen möchte, clone.

1. Zuerst müssen wir unser altes Repo komplett clonen:
   git clone --mirror <original-repo url>
2. Ist das Repo geklont können wir noch prüfen, ob alle Tags und Branches ausgecheckt sind, was aber der Fall sein sollte:
   git tag
git branch -a
3. Jetzt wird die „Verbindung“ zum alten Repo getrennt:
   git remote rm origin
4. Damit wir im nächsten Schritt das neue Repo „verbinden“ können:
   git remote add origin <new-repo url>
5. Das Ganze wird jetzt noch gepusht, fertig.
   git push origin --all &&
git push --tags

Schon haben wir das Repo vollständig kopiert, inklusive der History und aller Tags sowie Branches. :)

Vorab, was ist Natede überhaupt? Natede ist ein „smarter Blumentopf“, der die heimische Luft von Schadstoffen befreien möchte. Um dies zu tun hat er einige Sensoren verbaut, die dann – aktuell und offiziell leider nur über die App – auslesbar sind. Zu diesen Sensordaten zählen Temperatur und Luftfeuchtigkeit, VOCs, CO und Feinstaub (PM2,5).

Vitesy setzt hier anscheinend auf Firebase, die Doku zur Authentifizierung gibt’s hier.

Den refresh_token, den ich in folgendem Request mitschicke, finde ich in den mitmproxy-„Flows“. Mit diesem kann ich mir meinem Token für die API holen.

curl -H "Content-Type: application/json" --data-binary '{"refresh_token":"XXX"}' -X POST "https://securetoken.googleapis.com/v1/token?grant_type=refresh_token&key=AIzaSyD45X1yTlDyZIZxy6btd9Pefcv5JHg9kek" 2&>1 | jq .
{
  "access_token": "eyJhbGciOixxxxxxxxxxxxxxx",
  "expires_in": "3600",
  "token_type": "Bearer",
  "refresh_token": "XXX",
  "id_token": "eyJhbGciOixxxxxxxxxxxxxxx",
  "user_id": "7XVxxxxxxxxxxxxxx",
  "project_id": "860446277852"
}

Um sich den refresh_token direkt mittels E-Mail und Passwort zu holen kann folgendes cURL-Kommando genutzt werden:

curl -H "Content-Type: application/json" --data-binary '{"email":"meine@mail.com","password":"einPa$$wort","returnSecureToken":true}' -X POST "https://www.googleapis.com/identitytoolkit/v3/relyingparty/verifyPassword?&key=AIzaSyD45X1yTlDyZIZxy6btd9Pefcv5JHg9kek" 2&>1 | jq .
{
  "kind": "identitytoolkit#VerifyPasswordResponse",
  "localId": "7XVxxxxxxxxxxxxxx",
  "email": "meine@mail.com",
  "displayName": "John Doe",
  "idToken": "eyJhbGciOixxxxxxxxxxxxxxx",
  "registered": true,
  "profilePicture": "https://graph.facebook.com/xxx/picture",
  "refreshToken": "AEu4Ixxxxxxxxxxx",
  "expiresIn": "3600"
}

Interessant für uns hier in dem Fall ist der id_token (JWT), den wir später für unsere Requests an die Natede-API (https://api.clairyhub.com/; Clairy ist btw der Vorgänger, wobei die APIs hier aber grundlegend verschieden sind) brauchen. Den aktuellen idToken, der aber nur 1 Stunde gültig ist, finden wir auch in unseren Requests:

Um nun beispielsweise unsere Geräte auszugeben, reicht folgender Request (wobei ich hier einige Werte der Response anonymisiert habe):

curl --request GET 'https://api.clairyhub.com/users/me/devices' \
--header "Authorization: Bearer ${id_token}" 2&>1 | jq .
[
  {
    "fwVersion": "1.7.08",
    "location": {
      "zipcode": "86xxx",
      "country": "Deutschland",
      "utcOffset": 60,
      "formattedAddress": "Strasse 1, 86xxx Ort, Deutschland",
      "city": "Ort",
      "street": "Strasse, 1",
      "latitude": 0.0,
      "name": "Strasse 1",
      "placeId": "xxx",
      "description": "Strasse 1, 86xxx Ort, Deutschland",
      "longitude": 0.0
    },
    "isEnrollCompleted": true,
    "entityId": "E8:2A:44:00:00:00",
    "createdAt": "2019-12-20T14:40:00+00:00",
    "connected": true,
    "isEnrollSucceeded": true,
    "deviceName": "NATEDE Wohnzimmer",
    "updatedAt": "2020-01-24T09:00:30+00:00",
    "ssid": "FRITZ!Box",
    "certificateId": "xxx",
    "plant": {
      "id": "spathiphyllum",
      "name": "CLPLANT-spathiphyllum"
    },
    "place": {
      "id": "home",
      "name": "Home",
      "room": {
        "id": "living",
        "name": "Living"
      }
    },
    "sensors": [
      "tmp",
      "hum",
      "vocL",
      "dust",
      "co"
    ],
    "premium": false
  }
]

Anhand der entityId wird unser Gerät identifiziert, dieser entspricht der MAC-Adresse. Möchten wir nun die letzten Messwerte abrufen, hilft folgender cURL-Request:

curl --request GET 'https://api.clairyhub.com/devices/E8:2A:44:00:00:00/measurements/latest' \
--header "Authorization: Bearer ${id_token}" 2&>1 | jq .
{
  "uv": 0,
  "fan": 0,
  "pm25": 10.2,
  "deviceId": "E8:2A:44:00:00:00",
  "tmp": 24.4,
  "vocL": 1,
  "timestamp": 1579878607,
  "hum": 22,
  "co": 0,
  "measuredAt": "2020-01-24T16:10:07+01:00"
}

So weit, so gut. Die aktuellen Messwerte werden aktuell alle 10 Minuten geschickt. Um jetzt alle Messwerte für einen bestimmten Zeitraum zu bekommen, in folgendem Beispiel 1 Tag (Response gekürzt):

curl --request GET 'https://api.clairyhub.com/measurements?deviceId=E8%3A2A%3A44%3A00%3A00%3A00&fromDateTime=2020-01-23T00%3A00%2B01%3A00&toDateTime=2020-01-23T23%3A59%3A59.999999999%2B01%3A00&granularity=finest&sensors=tmp%2Chum%2Cpm25%2Cco%2Cco2%2Cvoc%2CvocL' \
--header "Authorization: Bearer ${id_token}" 2&>1 | jq .
[
  {
    "deviceId": "E8:2A:44:00:00:00",
    "firstMeasurementAt": "2020-01-23T00:06:07+01:00",
    "lastMeasurementAt": "2020-01-23T00:06:07+01:00",
    "aqi": {
      "count": 1,
      "max": 53.17297525495789,
      "min": 53.17297525495789,
      "sum": 53.17297525495789
    },
    "co": {
      "count": 1,
      "max": 0,
      "min": 0,
      "sum": 0
    },
    "hum": {
      "count": 1,
      "max": 33,
      "min": 33,
      "sum": 33
    },
    "pm25": {
      "count": 1,
      "max": 38.1,
      "min": 38.1,
      "sum": 38.1
    },
    "tmp": {
      "count": 1,
      "max": 13.1,
      "min": 13.1,
      "sum": 13.1
    },
    "vocL": {
      "count": 1,
      "max": 1,
      "min": 1,
      "sum": 1
    }
  },
  {
    "deviceId": "E8:2A:44:00:00:00",
    "firstMeasurementAt": "2020-01-23T00:16:08+01:00",
    "lastMeasurementAt": "2020-01-23T00:16:08+01:00",
    "aqi": {
      "count": 1,
      "max": 51.32705573108122,
      "min": 51.32705573108122,
      "sum": 51.32705573108122
    },
    "co": {
      "count": 1,
      "max": 0,
      "min": 0,
      "sum": 0
    },
    "hum": {
      "count": 1,
      "max": 33,
      "min": 33,
      "sum": 33
    },
    "pm25": {
      "count": 1,
      "max": 40.2,
      "min": 40.2,
      "sum": 40.2
    },
    "tmp": {
      "count": 1,
      "max": 13.1,
      "min": 13.1,
      "sum": 13.1
    },
    "vocL": {
      "count": 1,
      "max": 1,
      "min": 1,
      "sum": 1
    }
  },
  ...
]

Möchten wir nur bestimmte Sensor-Werte, können wir den Parameter sensors auch entsprechend anpassen.

Ähnliches Vorgehen, um die Alarme zu bekommen:

https://api.clairyhub.com/devices/E8:2A:44:00:00:00/alerts?fromDate=2020-01-23T00%3A00%2B01%3A00&toDate=2020-01-23T23%3A59%3A59.999999999%2B01%3A00

Wobei die Parameter fromDate und toDate hier optional sind.

Auf GitHub habe ich mal angefangen, da ein bisschen was zusammen zu tragen… :)

In meinem Fall ist es die Natede-App. Das Projekt, ein smarter Blumentopf 🌺, habe ich vor einiger Zeit bei Kickstarter unterstützt und vor kurzem auch – endlich! – erhalten. Leider wird hier aber (noch) keine offizielle/öffentliche API angeboten, hier versuche ich mehr über die App herauszufinden. Dazu aber dann später mehr in einem eigenen Artikel.

Also, los geht’s.

Was wird benötigt?

Am einfachsten ist es, das ganze in einem Emulator zu testen, erstmal laden wir uns also Android Studio herunter und installieren dieses, wenn noch nicht geschehen.
Zudem natürlich einen Proxy, ich nutze hier mitmproxy. Eine Alternative wäre beispielsweise Charles.

mitmproxy lässt sich am Mac beispielsweise ziemlich easy mit Homebrew installieren:

brew install mitmproxy

Schritt 1 – virtuelles Device anlegen

Nachdem die Requirements nun geklärt wären, legen wir los. Zuerst müssen wir uns ein virtuelles Android-Device anlegen. Hierzu öffnen wir nun Android Studio, starten damit den AVD-Manager und legen uns ein Device an.

Wie auf den Bildern zu sehen habe ich mich hier für ein Pixel 3 XL mit Android 9 Pie (API-Version 28) entschieden. Wichtig ist nur, dass ihr hier eine „Google APIs“-Version ohne den Play Store nutzt (sonst klappt später z. B. das adb root-Kommando nicht).

Schritt 2 – Android-Device vorbereiten

Da Apps seit Android 7 vom User hinzugefügte CAs ignorieren (außer, die App wird entsprechend angepasst, was uns ja – da wir nicht der Entwickler sind – nicht möglich ist), müssen wir ein eignes System-CA hinzufügen. Wie das geht ist auf der Seite von mitmproxy recht gut dokumentiert – dieser Anleitung könnt ihr gerne folgen.

Schritt 3 – Proxy starten und am Android-Emulator konfigurieren

Den Proxy könnt ihr nun über’s Terminal anstarten mit mitmproxy -p $port. Da ich aber eine WebGUI bevorzuge, wähle ich mitmweb:

$ mitmweb -p 8082
Web server listening at http://127.0.0.1:8081/
Proxy server listening at http://*:8082

Hier sehen wir nun, die WebGUI ist unter localhost:8081 erreichbar, der Proxy lauscht auf dem Port 8082. Dies konfigurieren wir nun in unserem Emulator, der ja bereits läuft. Hier dürcken wir einfach auf die 3 Punkte, um zu den Einstellungen zu kommen:

Das war’s!

Nachdem wir die Einstellungen gespeichert haben nutzt unser Gerät den Proxy und wir können mitlauschen. Öffnen wir nun beispielsweise unsere App oder surfen eine Webseite an, sehen wir diese Requests auf unserer mitmweb-GUI.

Um die App übrigens auf eurem virtuellem Gerät zu installieren könnt ihr euch die APK herunterladen – dafür gibt es verschiedene „APK Downloader“. Diese dann einfach per Drag & Drop „auf das Smartphone ziehen“, fertig. :)

Na dann, viel Spaß – da kann man sich jetzt erstmal ein Weilchen austoben :D Und wie gesagt, der Artikel zur Natede-App folgt. 👋

Die Lösung hier ist das Apple Developer Portal. Hier finden sich alle Xcode-Versionen, inklusive Betas.

Möglichkeit 1: Parallele Downloads in Chrome aktivieren

Die erste Möglichkeit wäre beispielsweise im Chrome folgendes Flag zu aktivieren: chrome://flags/#enable-parallel-downloading
Dies sorgt für parallele Downloads, was für merklich mehr Speed sorgt.

Möglichkeit 2: Schnellere Downloads mittels aria2

Eine zweite Möglichkeit ist der Download mittels aria2, welches sich mittels Homebrew schnell installieren lässt.

Ich habe dann folgendes Ruby-Script von Ian Dundas für den Download verwendet:

#!/usr/bin/env ruby

print "What is the URL of your Apple Downloads resource?\nURL:"
url = gets.strip

print "What is the ADCDownloadAuth cookie token:\nADCDownloadAuth: "
token = gets.strip

command = "aria2c --header \"Host: adcdownload.apple.com\" --header \"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\" --header \"Upgrade-Insecure-Requests: 1\" --header \"Cookie: ADCDownloadAuth=#{token}\" --header \"User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_1 like Mac OS X) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0 Mobile/14B72 Safari/602.1\" --header \"Accept-Language: en-us\" -x 16 -s 16 #{url} -d ~/Downloads"

exec(command)

aria2 nutzt hier ebenfalls bis zu 16 parallele Verbindungen, was den Download merklich beschleunigt.

Der Token wird im Cookie ADCDownloadAuth gespeichert, also einfach einmal im Browser einloggen, um dann den Token zu kopieren.

Entpacken mittels xip

Auch für die schnellere Installation bzw. das Entpacken um an die .app zu kommen gibt es einen „Trick“. Statt die Datei per Doppelklick im Finder zu öffnen und zu entpacken, kann man auch wieder zum Terminal greifen:

xip -x ~/Downloads/Xcode_11.3.xip

Im Gegensatz zum Doppelklick im Finder wird hier nämlich nicht die Signatur geprüft, was aber durchaus auch ein Risiko sein könnte. Ob man dieses in kauf nehmen möchte, kann aber jeder für sich selbst entscheiden :)

So, und mein Download dürfte nun auch fertig sein. :D 👍

Ab sofort ist jedoch die Anmeldung zur Beta offiziell geöffnet und über die Beta-App von Huawei möglich. Leider begrenzt Huawei die Listenplätze immer, für die aktuelle Beta stehen anscheinend lediglich 400 Plätze bereit – schnell sein lohnt sich also.

Ich habe mich für die Beta eingetragen und hoffe nun, einen Platz in der Liste zu bekommen. Bis die ersten Betas dann ausgerollt werden, dürfte es nun nur noch wenige Tage dauern, das Update kommt dann per OTA.

Wer sich für die Änderungen zwischen der aktuellen Version EMUI 9 und der künftigen EMUI 10-Version auf Basis von Android 10 interessiert, kann sich gerne mal bei YouTube umschauen – hier gibt es bereits einige Videos, die die beiden Versionen miteinander vergleichen und die Änderungen zeigen. :)

Ich möchte hier noch warnend erwähnen, dass dies keine Step-to-step-Anleitung wird, der ihr per Copy & Paste „folgen“ könnt. Um die Installation müsstet ihr euch selbst kümmern, sollte aber kein Problem darstellen. :)

Schritt 1 – die Powerline-Shell

Los geht’s mit der Installation der Powerline-Shell inklusive der dazugehörigen Fonts. Voraussetzung hier ist u. a. Python. Die Installtions-Schritte sind in der README.md auf Github verlinkt.

Update: https://github.com/romkatv/powerlevel10k

Schritt 2 – ein neues Theme hinzufügen

Ein recht beliebtes Theme, auch für ZSH, ist Agnoster. Auch für ZSH habe ich dieses Theme gerne genutzt, so auch also jetzt auch (wieder) mit der Bash.

Schritt 3 – iTerm2 Farbschema ändern

Zu guter Letzt wird in iTerm noch das Farbschema angepasst. Ich nutze hier Argonaut, welches nicht standardmäßig mit dabei ist aber ebenfalls auf Github zu haben ist.
Geändert werden kann das Farbschema, sobald es installiert ist, unter den Einstellungen (⌘ + i) -> Colors.

So. Das dürft’s dann auch schon wieder gewesen sein. Das Ergebnis ist dann folgendes:

Das schöne: Soetwas wie Bash-Git-Prompt bringt die Powerline-Shell direkt mit, darum braucht ihr euch also nicht zusätzlich zu kümmern. Ich bin mit diesem Setup aktuell recht zufrieden und werde dieses wohl auch noch eine ganze Zeit beibehalten. 😇

Leider gibt es aber doch einige „Problemchen“, die ZTE bei der G-Version (Europa) nicht in den Griff zu bekommen scheint…

Im März lieferte ZTE beispielsweise Android 7.0 für das Axon 7, nicht aber per OTA, sondern via ZIP zum selber flashen. Hier gab es dann auch noch ein paar Probleme, weshalb man den Download der ZIP sperrte und auf den nächsten Tag verschob – fanden viele nicht so cool, hätte man besser machen können. Dann folgte Ende März schon bald das Update auf Android 7.1 mit den letzten Sicherheits-Patches und unter anderem Daydream-Unterstützung.

Angekündigt wurde das 7.1-Update auf Facebook folgendermaßen:

Guten Tag an alle Axon 7 Freunde!
Nachdem euch unser letztes Stückchen Nougat nicht ganz so gut geschmeckt hat, haben wir uns an die Rührschüssel gesetzt und werden bis zum 31.03 eine neue Geschmacksrichtung für euer Axon 7 zur Verfügung stellen!

-Geschmacksrichtung: Nougat 7.1.1
-Stand des Sicherheitsupdates: März 2017
-Google Daydream zertifiziert
-Verteilung wird über FOTA erfolgen

Wir informieren euch, sobald wir mit der Verteilung starten!
America first, Germany second!

Tja, ZTE. Hier scheint man sich aber leider verrührt zu haben, denn dieses Stückchen Nougat schmeckt leider weniger gut als das vorherige…

Ein Problem auch: die Verschlüsselung. Hier wurde im Forum immer auf das nächste Update vertröstet, bis die Verschlüsselung endlich mit 7.1 Einzug halten sollte – oder doch nicht? Nein, leider nicht. Was kam, ist ein Eintrag in den Einstellungen:

Der Eintrag „Smartphone verschlüsseln“ ist rein informativ, kann nicht geklickt werden. Witzigerweise wird hier zwar vorgegaukelt, das Smartphone sei verschlüsselt, was aber nicht der Fall ist – wenn man davon ausgeht, dass das Smartphone beim booten erst per Passwort entschlüsselt werden muss, um auf die Dateien zuzugreifen. Einen weiteren Punkt für die Verschlüsselung sucht man in den Einstellungen vergebens. Über Umwege aber schafft man es, die Einstellungen zur Verschlüsselung (.Settings$CryptKeeperSettingsActivity) zu öffnen, was einen zu folgendem führt:

In obigem Screenshot ist der Button nicht klickbar, da mein Akkustand zu niedrig ist und nicht am Ladegerät hängt. Ok, so weit so gut. Das Problem: Der Button wird mit vollem Akku und am Netzteil zwar klickbar, alles was dann aber passiert ist ein Neustart des Geräts – eine Verschlüsselung erfolgt nicht…

Auch „witzig“: Man wollte das 7.1er-Update wohl ein bisschen voreilig liefern (man munkelt, es handelt sich hier auch nur um eine leicht geänderte Beta der U-Version, die übrigens in Sachen Updates weit besser zu funktionieren scheint…) und hat die Google-Zertifizierung nicht mehr abgewartet. Ist zwar erstmal kein Problem, dennoch unschön:

Und die restlichen Bugs des letzen 7.1er-Updates:

• In den Einstellungen -> Konten fehlen sämliche Konten, hier wird nur noch das Google-Konto aufgeführt.
• Whatsapp hat an einigen Ecken Probleme, vor allem mit der In-App-Kamera.
• Updates im PlayStore funktionieren nicht richtig mit der aktuellen PlayStore-Version, hier wird lediglich die Meldung „Auf Netzwerk warten…“ angezeigt.
• der WLAN-Switch in den Quick-Settings zeigt manchmal „on“, obwohl WLAN deaktiviert ist.
• …

Wie man sieht, verstecken sich hier einige Bugs, die nicht nur vereinzelt auftreten, was man schnell merkt, wenn man einen Blick in’s ZTE-Forum wirft. Dort ist sogar von Spyware die Rede.

Wie gesagt, die Hardware des Axon 7 ist wirklich top, hier kann man nicht meckern. Bringt aber leider auch nur wenig, wenn die Software Müll ist. Auf Caschy’s Blog wird auch schon vor dem Update „gewarnt“.

Glücklicherweise wird ja parallel an LineageOS für’s Axon 7 gearbeitet, hier hoffe ich auf eine baldige Stable-Version, damit ich mir dies nicht mehr antun muss… Zum Abschluss hier noch meine Update-Historie bis heute:

Komprimieren (packen)

Dekomprimieren (entpacken)

Archivinhalte anzeigen

Was hier jetzt nicht behandelt wird, sind die jeweils genutzten Algorithmen oder andere, tiefere Details. Hierzu können aber jederzeit gerne die Manpages der jeweiligen Tools durchstöbert werden. ;)

Seit heute sollte hierfür wohl ein Update verfügbar sein, welches aber – anscheinend – nicht wirklich Abhilfe schafft. Glücklicherweise gibt es aber, solltet ihr auf die Spotify-App auf eurem PC nicht verzichten können oder wollen, einen Workaround (für ).

Der Workaround beschreibt das Anlegen einer RAM-Disk, heißt, statt auf der Festplatte wird die Spotify-Datenbank im RAM gespeichert. Für Windows wird das Ganze im oben verlinkten Workaround mithilfe des Programms „ImDisk“ beschrieben. Wie Ihr eine solche RAM-Disk mit OS X MacOS bzw. Linux anlegt, beschreibe ich euch jetzt … :)

Mit MacOS ist es relativ easy über’s Terminal:

diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://8388608`

Dieser Befehl legt euch eine 4GB (4096*2048 = 8388608) große RAM-Disk an, was wohl ausreichen sollte – getestet habe ich es nicht.

Auch bei Linux – genauer Debian bzw. Ubuntu – läuft es ebenfalls recht easy über’s Terminal. Eine Möglichkeit ist beispielsweise mit tmpfs:

sudo mkdir /mnt/ramdisk &&
sudo chmod 777 /mnt/ramdisk &&
sudo mount -t tmpfs -o size=4G none /mnt/ramdisk

Wenn bei tmpfs die RAM-Disk „voll“ ist, lagert dieses aber die Dateien in den Swap aus, nutzt also wieder die Festplatte… Eine alternative wäre ramfs, was euch aber im blödsten Fall den kompletten RAM vollschaufelt.

Auf diese RAM-Disk könnt ihr das schuldige Verzeichnis dann auslagern und per Symlink (ln -s) dahin verlinken, wo sie hin gehört. Fertig. Nach einem Neustart gehen diese Daten auf der RAM-Disk natürlich verloren – dies sollte aber kein Problem sein.

Dies soll keine endgültige Lösung sondern einen Workaround darstellen, bis Spotify dieses Problem wirklich fixt. ;)

Lässt sich recht easy mit einer Schleife realisieren:

for node in $(<hostlist.txt); do
  scp meineDatei.tgz ${node}:~/
done

In die hostlist.txt kommt dann eine Auflistung der Rechner, ggf. mit vorangestelltem User, also johann@srv01.

Over and out! :) 

Wahrscheinlich bei vielen so, wie auch Statistiken zeigen… 😏 Kann Facebook bzw. Instagram sich ja nicht gefallen lassen, also hat man Snapchat kurzerhand nachgebaut – nennt sich dann „Instagram Stories“. Instagram selbst beschreibt die neue Funktion folgendermaßen:

Einführung von Instagram Stories, eine neue Funktion, mit der du alle Momente deines Tages teilen kannst und nicht nur jene, die du in deinem Profil behalten möchtest. Wenn du mehrere Fotos und Videos teilst, werden sie zusammen als Slideshow dargestellt – deine Story.
Du kannst mehrere Fotos und Videos in deiner Story teilen. Erwecke sie mit Text und Zeichentools zum Leben. Nach 24 Stunden werden sie ausgeblendet und nicht mehr in deinem Profil oder deinem Feed angezeigt.

Wie gesagt – ein Snapchat-Klon. Kommt aber vermutlich (zu?) spät, aber mal sehen, wie sich das noch entwickelt. Ich bin gespannt… Snapchat hat hier aber einen riesen Vorsprung, was beispielsweise Geofilter oder die Masken-Filter betrifft. Letzteres könnte Facebook aber mit dem übernommenen Dienst Masquerade (MSQRD) wett machen. Wie gesagt – abwarten, was hier noch kommt. :)

Glücklicherweise. Ab sofort ist das Gerät nämlich in Deutschland vorbestellbar – in Gold und Grau. Preis? War bereits vorher bekannt: rund 450 Euro.

Bei Amazon konnte man das Gerät bereits vor einiger Zeit vorbestellen, damals aber eben nur in Gold. Inzwischen ist es dort aber als „Derzeit nicht verfügbar“ gelistet.

Heute gab ZTE Deutschland aber auf der eigenen Facebookseite bekannt, dass das Axon 7 ab sofort bei Saturn und MediaMarkt vorbestellbar ist:

Wann das Gerät aber dann versandt wird (bzw. in der Filiale abgeholt werden kann, wenn gewünscht), geht leider nicht hervor. Dürfte aber Mitte August werden.

Ich kann’s kaum erwarten – außerdem macht’s mein OnePlus One echt nicht mehr lange, leider… Wird also Zeit, dass das Ding offiziell erhältlich ist! :)

Kann man sich mal anschauen… ;)

Momentan ist die App – normalerweise – nur für Beta-Tester verfügbar, die sich auf der Webseite in die Mailing-Liste eingetragen haben. Diese bekommen wohl nach und nach eine Einladung. Ich habe mich dort vor einiger Zeit schon eingetragen, bis dato aber noch keine Einladung bekommen.

Wer sich die App trotzdem schonmal anschauen möchte, kann sich die APK wie so oft bei APKMirror laden.

Die Bilder werden übrigens nicht auf dem Smartphone direkt bearbeitet, sondern online. Heißt, euer Bild wird hochgeladen, bearbeitet und wieder heruntergeladen. Heißt auch, dass die App ohne aktive Internetverbindung natürlich nicht genutzt werden kann. Nur zur Info – wer dies warum auch immer nicht möchte, sollte die App nicht nutzen. Ich denke aber nicht, dass die Bilder lange auf den Servern gespeichert bleiben.

Update 22.07.2016:
Sieht so aus als hätte man der Beta-App nun einen Riegel vorgeschoben – momentan heißt es also, dass man, um die App nutzen zu können, auf das offizielle Release warten muss.

Update 24.07.2016:

Nachdem die inoffizielle Beta vor kurzem geblockt wurde, haben die Entwickler hinter der App eben den offiziellen Start im Google Play Store verkündet – die App kann nun also offiziell auch für Android herunterladen werden :)