Wie immer spannend die Grafiken von asymco.com. Finde ich korrekt von RIM, Apple und HTC, dass sie verkaufte Geräte ausweisen und nicht nur Shipments

Was sofort auffällt, wenn man vorher nur Samsungs und HTCs verwendete, ist die neue Ice Cream Sandwich Oberfläche:

Mir gefällt die Oberfläche mit dem dunklen Hintergrund und den weissen und blauen Highlights sehr gut. Wie vielfach geschrieben, wirkt die Oberfläche aufgeräumter und weniger verspielt als die bisherigen Android Versionen. Spontan erinnert es mich ziemlich an die Oberfläche des Blackberry 5 OS (sorry für den crappy Screenshot):

Auch Windows Phone 7 ähnelt mit dem dunklen Hintergrund und der strikten Farbgebung diesem Stil (Trolle, sattelt eure Pferde noch nicht. Ich werfe hier kein Plagiat vor). Mir gefallen jedenfalls alle drei Oberflächen sehr gut. Doch was hat das mit Standard zu tun. Wir kommen dazu.

Einer der grössten Kritikpunkte an Android ist die Fragmentierung des Systems. Viele Versionen sind im Umlauf. Gerätehersteller und Netzbetreiber machen alle ihre Anpassungen am Aussehen und dem Funktionsumfang von Android. Einige mit guten Absichten, da sie denken ihre eigene Oberfläche sei tatsächlich einfacher/schöner/besser zu bedienen, andere aber auch mit zweifelhaften Absichten indem sie Bloat- und Spyware installieren.

Was die Oberflächen und Anpassungen aber immer verursachen sind höhere Aufwände bei der Aktualisierung auf eine neue Android Version. Die Anpassungen müssen nämlich angepasst und wieder getestet werden. In Vergangenheit interessierte das die Hersteller weniger. Das Gerät ist ja schon verkauft. Die Tatsache zeigt dieser Beitrag hier ziemlich eindrücklich auf. An der letztjährigen Google-Entwicklerkonferenz wurde das Thema dann auch aufgegriffen und eine “Update Alliance” mit den grossen Herstellern gebildet. Während mindestens 18 Monaten sollten Geräte die neueste OS-Version erhalten. Die Ernüchterung ist allerdings zum Ende des letzten Jahres gekommen. Keiner spricht mehr von der Update Alliance oder hätte etwas davon gehört. So laufen heute noch 40% der Android-Geräte mit sehr alten Versionen (max 2.2 – immerhin im Dezember 2010 durch 2.3 abgelöst worden). Die aktuelle Version 4.x, immerhin im Oktober 2011 verfügbar, verwenden lediglich 0.6% der Geräte (besagte Galaxy Nexus und Nexus1 sind auch die einzigen die momentan auf Android 4 laufen).

Was sind die Probleme dieser vielfältigen Versionen? Zum einen ist es grundsätzlich ein Problem, wenn alte Software im Einsatz ist. Allfällige Sicherheitslücken werden nicht mehr gefixt, Funktionen können nicht verwendet werden, Unterstützungssoftware ist allenfalls nicht mehr mit alten Versionen kompatibel etc. Das ist dem Privatanwender vermutlich bis auf die funktionalen Erweiterungen relativ egal, ein Unternehmen muss sich der Frage aber sicherlich stellen. Ein weiteres Problem von vielfältigen Versionen ist der Betrieb einer Geräteflotte. Jedes Gerät, jede Oberfläche muss evaluiert, getestet und supported werden. Gerade bei Smartphones wird viel Support dem Anwender übergeben und dieser muss sich oft auf Anweisungen oder Anleitungen verlassen. Diese Aufwände explodieren, wenn mehr als eine Oberfläche im Betrieb ist. Von unterschiedlichem Funktionsumfang gar nicht zu reden. Auch für den Anwender ist Android oftmals etwas verwirrlich. Anwendungen lösen ihre Oberflächen jeweils selber. Der Anwender ist so oft mit unterschiedlichen Betriebskonzepten konfrontiert. Alles Gewöhnungssache möchte man denken. Doch zu bedenken ist es.

Das Problem mit den unterschiedlichen Oberflächen hat man jetzt mit Android 4.0 ein wenig entschärft:

In Android 4.0, Holo is different. We’ve made the inclusion of the unmodified Holo theme family a compatibility requirement for devices running Android 4.0 and forward. If the device has Android Market it will have the Holo themes as they were originally designed.

Will ein Hersteller also mit der neuesten Version von Android auf Dienste wie Google Market, etc. zugreifen, ist er verpflichtet die Standardoberfläche zumindest auf dem Gerät zu belassen. Anwendungsentwickler können somit die Elemente dieser Oberfläche verwenden. Ein Unternehmen könnte, zur Vereinfachung des Supports und der Erstellung von Anleitungen, eben auf diese Oberfläche zurückgreifen. Wie dies  möglich ist, muss bei den ersten Geräten ohne Standard-Android geprüft werden. 

Es ist aus Sicht von Standardisierungsfreunden jedenfalls ein Licht im Tunnel. 

Dell will künftig keine Netbooks mehr herstellen und sich stattdessen auf die Produktion von dünnen und leistungsfähigen Notebooks konzentrieren. Der Grund sei die geringe Nachfrage.

Ich vermisse aber das Kino schon auch und würde sofort wieder kommen liebe Kitag (die Jungs/Mädels in Brünnen hab ich aufgegeben)

Update: Und für zuweilen mitlesende Bürokollegen die meine Leidenschaft und daher mein Wissen über Filme nicht teilen (pointing at tobias): Das da unten ist Pan der frühstückt (Pans Labyrinth). Das darunter (und jetzt schau ich auch Pit an, der den Millenium Falcon in Präsentationen als Sternenkreuzer bezeichnet) sind Chewbacca und Han Solo. Ihres Zeichen die Besitzer und Piloten des Millenium Falcon. Und das andere sind Sternenzerstörer. Get your Sci-Fi right, damned!

so gesehen im Vorspann zu Big Bang Theory:

Und wer findet es

Für den User sicher einerseits komfortabel. Andererseits finde ich es zuweilen sogar schade nicht explizit zu wissen was Updates für neue Funktionen bringen. Das weil ich relativ schnell im Apple Appstore Anwendungen aktualisiere. Die Zusatzfunktionen finde ich dann jeweils eher zufällig oder weil ich im Netz darüber las.

Warum aber problematisch? Android hat ja keine Qualitätskontrolle was den Code angeht, sondern setzt auf die Kontrolle durch die Community. Obwohl das Prinzip ebenfalls seine Berechtigung hat, ist es weniger zeitnah als eine vorgelagerte Kontrolle wie es Apple und Microsoft machen. So kann es vorkommen, dass Anwendungen schädlichen Code enthalten (Daten ausspähen, verteilen, etc.) und das erst durch News publik wird. Google kann dann diese Applikationen von den Geräten entfernen. bis dahin können aber schon Daten abgeflossen sein. Der andere Fall ist das Update. Es kann eine Anwendung in den Market kommen, und eine einfache Funktion erfüllen (bsp. Ringtones, Wallpapers, etc.) Lässt man nun Autoupdates zu, kann diese Applikation zu einem späteren Zeitpunkt ihren Zweck völlig ändern und die Anpassung wird automatisch im Hintergrund installiert.

Das Risiko ist definitiv erhöht, auch wenn natürlich das bewusste Updaten durch den Anwender nicht viel sicherer ist, da in der Beschreibung des Updates nicht stehen wird: “Von nun an lesen wir ihre SMS aus und senden sie an einen russischen Server”

via t3n.de

Anbei ein kurzer Überblick, was gemäss meinen Beobachtungen neu hinzugekommen ist. Die Policies sind im iPCU in Payloads unterteilt:

Restrictions-Payload:

Gerätefunktionalität:

- Siri erlauben

- Benutzer muss für alle Einkäufe das iTunes Store-Kennwort eingeben (verhindert wohl Apps innerhalb eines gewissen Zeitraums ohne PW-Eingabe zu installieren)

- Game Center Einstellungen: Mehrspielermodus erlauben

- Game Center Einstellungen: Hinzufügen von Game Center-Freunden zulassen.

iCloud

- Backup erlauben

- Synchronisierung von Dokumenten erlauben

- Fotostream erlauben (Nichterlauben kann zu Datenverlust führen, da die im Fotostream gespeicherten Bilder gelöscht werden)

Sicherheits- und Datenschutzrichtlinien erzwingen:

 - Diagnosedaten dürfen an Apple gesendet werden

- Benutzer dürfen nicht vertrauliche TLS-Zertifikate annehmen

- Verschlüsselte Backups erzwingen (Was ich noch nicht getestet habe, ist ob dies auch für die iCloud Backups gilt)

 

VPN-Payload

 - Für alle Daten (Somit kann der ganze Netzverkehr über die VPN-Verbindung geschickt werden, und damit im Unternehmen über einen Proxy kontrolliert werden)

E-Mail Payload

- Bewegen erlauben: Zwingt die Accounts in den Sandbox-Modus (damit werden für viele Anwender Drittlösungen wie ehemals MobileOffice eigentlich obsolet, wenn es lediglich darum geht die E-Mail-Daten in einer Sandbox zu speichern. Verhindert ebenfalls den Abfluss von Informationen ohne diese über einen Server verschicken zu müssen.)

- Gleiche Einstellung auch in Exchange möglich

 - Zusätzlich lassen sich Zertifikate oder SCEP-Settings für die Signierung/Verschlüsselung von Mails definieren.

 

Was nicht direkt im iPCU ersichtlich ist, ist das Verhalten von Anwendungen die über ein MDM verteilt werden. Wir verteilen bspweise eine App die als Quickguide die Services erklärt. Dies aus dem Grund, dass der Anwender das Gerät am MDM provisioniert, und auf diesem Weg direkt die notwendigen Anleitungen erhält. Nun konnte der Anwender die Kontrolle des MDM immer deinstallieren, hatte dann aber auch die Einstellungen und Zertifikate nicht mehr. Somit konnte man verhindern, dass der Anwender weiterhin auf Unternehmensressourcen zugreifen kann, wenn er kein MDM mehr installiert hat. Anders verhielt es sich mit den Applikationen die man verteilt hat. Diese blieben auf dem Gerät. Mit iOS 5 ändert dies nun. Applikationen werden, wenn über MDM verteilt, automatisch zu “managed Applications”. Wenn also die MDM-Kontrolle entfernt wird, werden auch die Applikation und deren Daten gelöscht. Somit könnte man kritischere Applikationen entwickeln und verteilen.

Dort wurde @thegooroo für ein Quiz eingespannt was einen erfahrenen Medienmann natürlich überhaupt nicht aus der Ruhe bringt. Die Themenwahl EVP war dann schon etwas beunruhigend.

da stiess dann auch noch @kusito hinzu und nach der Quizteilnahme verzogen wir uns auf die Front und später zum Essen. Somit ein gelungener Abend auch wenn ich mir von @thegooroo mehr crowdsourcingpower erwartet hätte. aber wie ich heute sagte ist er ein unterbewerteter twitterer.

und für Leute welche meinen Tumblr nicht kennen/nutzen auch hier eine Alternative.