DE112016006734T5

DE112016006734T5 - Integriertes Android- und Windows-Gerät

Info

Publication number: DE112016006734T5
Application number: DE112016006734.8T
Authority: DE
Inventors: Matthew J. Adiletta; Myles Wilde; William R. Wheeler; Michael F. Fallon; Aaron Gorius; Amit Kumar; Chengda Yang
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-04-26
Filing date: 2016-04-26
Publication date: 2019-01-03
Also published as: WO2016176206A1; US20190121682A1; US10922148B2

Abstract

Techniken zur Implementierung von Zugang zu Android-Anwendungen und nativen Windows-Anwendungen auf Android-Geräten und -systemen. Eine Prozessorplatine umfasst einen Prozessor, der dafür ausgelegt ist, eine volle Version eines Windows-Betriebssystems und Windows-Anwendungen auszuführen. Die Prozessorplatine ist dafür ausgelegt, kommunikativ mit der Prozessorplatine in einem Android-Gerät, wie etwa einem Smartphone oder Tablet, gekoppelt zu werden. Im Betrieb und wenn die Prozessorplatine kommunikativ mit dem Android-Gerät gekoppelt ist, wird einem Benutzer des Android-Geräts ermöglicht, selektiv Android-Anwendungen und Windows-Anwendungen laufenzulassen, wobei die Windows-Anwendungen nativ auf der Prozessorplatine ausgeführt werden. Die Prozessorplatine kann in einer Datenverarbeitungskarte implementiert sein, die ungefähr die Größe einer Kreditkarte aufweist oder kleiner ist, die ihrerseits über ein Backpack oder ähnliche Mittel mit dem Android-Gerät gekoppelt werden kann. Die Prozessorplatine kann auch im selben Gehäuse wie das Android-Gerät angeordnet sein.

Description

VERWANDTE ANMELDUNGEN
Die vorliegende Anmeldung ist eine Fortsetzung der vorläufigen US-Anmeldung Nr. 62/159,932 , eingereicht am 26.4.2015 mit dem Titel „INTEGRATED ANDROID AND WINDOWS DEVICE“, die hiermit durch Bezugnahme vollständig und für alle Zwecke aufgenommen wird.
STAND DER TECHNIK
In der heutigen zunehmend verbundenen Gesellschaft ist es üblich, dass Benutzer über mehrere Geräte verfügen, die für spezielle Zwecke verwendet werden. Zum Beispiel verfügen Benutzer typischerweise über ein Smartphone für Sprach- und elektronische Kommunikation und Unterhaltung (sowie für andere Zwecke), mindestens einen Desktop-, Laptop-, Notebook- oder ähnlichen Typ von Computer für die Arbeit und/oder persönliche Aufgaben, und können ferner über ein Tablet, Netbook oder Chromebook verfügen, das (im Allgemeinen) zum Zugreifen auf das Internet, Anschauen von Videos usw. verwendet wird. Jedes dieser Geräte stellt Mittel zum Verbinden mit dem Internet und Zugreifen auf Daten von verschiedenen Quellen und Repositorien bereit.
Software- und Gerätehersteller haben sich um universelle Plattformen und nahtlose Umgebungen bemüht, sind aber beim Erreichen ihrer Ziele bisher nicht sehr weit gekommen. Zum Beispiel hat sich Microsoft um eine einheitliche Plattform um Windows 8 (und das aufkommende Windows 10) herum bemüht, unter der sich verschiedene Klassen von Geräten (Desktop/Laptop, Smartphone und Tablet) eine ähnliche Benutzeroberfläche (UI) teilen und ein ähnliches Benutzererlebnis (UX) bereitstellen. Das Windows-8-Paradigma der Verwendung einer UI auf Mosaikbasis, das naturgemäß für Verwendung mit Benutzereingabe auf Berührungsbasis ausgelegt ist, wurde in der Geschäftswelt nicht sehr gut aufgenommen, die hartnäckig an der Verwendung von Microsoft-Produktivitäts-Softwareanwendungen und Vernetzungsdiensten festhält. Insbesondere wurde UI-Funktionalität, wie etwa das in Windows 7 verwendete Startmenü, aus Windows 8 herausgenommen, nach enorm viel Benutzerbeschwerden jedoch (mit einigen Einschränkungen) in Windows 8.1 wieder eingesetzt. Noch schlimmer ist für Microsoft, dass der Marktanteil für Windows-Telefone in den Vereinigten Staaten um 2-3 % fluktuiert, mit etwas höherer Durchdringung in anderen Märkten. Surface-Tablets von Microsoft weisen einen ähnlich irrelevanten Marktanteil auf. Angesichts der Dominanz von Geräten mit Android und dem IOS von Apple auf dem Smartphone- und Tablet-Markt ist sehr unwahrscheinlich, dass Microsoft in diesen Märkten jemals viel Zugkraft gewinnen wird. Umgekehrt ist es wahrscheinlich, dass Microsoft weiter auf dem Unternehmens- und Verbrauchersoftware- und Betriebssystemmarkt dominieren wird.
Ein anderer Aspekt, mit dem sich verschiedene Firmen beschäftigen, ist universeller Zugriff auf Daten. Dies wird typischerweise über Dateneinrichtungen auf „Cloud“-Basis ermöglicht, so wie sie etwa von Google (z. B. Google Docs und Google Drive), Microsoft (Office 365 und SkyDrive), Apple (iCloud), Dropbox und anderen bereitgestellt werden. Einerseits stellen Dateneinrichtungen auf Cloud-Basis einen gewissen Grad an universellem Zugriff auf mindestens einige Benutzerdaten bereit. Die ist jedoch nicht unproblematisch. Insbesondere muss man über Zugriff auf die im Internet gehosteten Einrichtungen verfügen, nur um auf die Daten zuzugreifen; kein Internetzugang bedeutet kein Datenzugang. Außerdem gibt es Probleme mit Netzwerklatenzen und Sicherheitsbedenken. Obwohl Microsoft die Fähigkeit von Office 365 betont, von mehreren Geräten aus auf Dokumente zuzugreifen, wird es vom tatsächlichen Benutzungsstandpunkt aus hauptsächlich als ein Subskriptionsdienst verwendet, um auf Produktivitätsanwendungen von Microsoft Office auf einem einzigen Gerät unter Verwendung einer lokalen Speicherung von Anwendungsdokumentdaten zuzugreifen, statt Cloud-Speicherung der Dokumente zu verwenden, die durch die Anwendungen produziert werden und auf die diese zugreifen.
Zusätzlich zu dem Obigen bevorzugen es Benutzer im Allgemeinen, dass direkt von ihren Geräten aus auf Daten zugegriffen wird; ein Benutzungsmodell, unter dem der Benutzer mehr Kontrolle über seine eigenen Daten hat. Erstens haben sich Benutzer über die Jahre an dies gewöhnt, und der Gedanke, sich für den Schutz ihrer Daten auf jemand anderes zu verlassen, ist etwas beunruhigend. Zweitens ist die durch Anwendungen auf Cloud-Basis wie Google Docs bereitgestellte Echtzeitinteraktion nicht gerade optimal, selbst mit einer schnellen Netzwerkverbindung. Obwohl Google Produktivitätsanwendungsfunktionalität über Webseiten (eine gewaltige technische Aufgabe) sehr gut implementiert hat, ist nichts mit der Verwendung einer direkt auf Ihrem Gerät laufenden Anwendung vergleichbar.
Die Speicherung von Daten auf Geräten von Benutzern hat wiederum seine eigenen Nachteile. Erstens können Daten auf einem anderen Gerät gespeichert sein, das dem Benutzer aktuell nicht verfügbar (z. B. zuhause oder bei der Arbeit gelassen) ist. Zweitens ist es sehr üblich, dieselben Daten über mehrere Geräte zu replizieren, wodurch Speicherungsressourcen verschwendet werden. Zum Beispiel ist es sehr üblich, dass iPhone- und iPad-Benutzer Fotos und Videos über mehrere Geräte replizieren, zum Beispiel dieselben Fotos auf einem iPhone/iPad und in iPhoto auf einem Apple-Mac-Computer haben. Obwohl Apple versucht hat, dies durch seinen iCloud-Dienst zu behandeln, übersteigt die Menge an durch die Fotos in Videos eingenommenem Speicherplatz typischerweise die Menge an kostenlos pro Benutzer angebotener iCloud-Speicherung, und Benutzer sind unwillig, für zusätzlichen Speicherplatz zu bezahlen. Jede Synchronisierungs- oder Backup-Operation führt somit einfach nur zu weiterer Replikation von Daten.
Benutzungsmodelle in der absehbaren Zukunft werden weitgehend diejenigen in der letzten Vergangenheit widerspiegeln. Ein typischer Benutzer wird weiterhin sein Android- oder iPhone-Mobiltelefon für Zwecke benutzen, für die diese Geräte ausgezeichnet geeignet sind, während für Produktivitätsaufgaben ein Desktop- oder Laptop-Computer (oft mit einem angeschlossenen zweiten Display) verwendet wird und für die Freizeit möglicherweise andere Geräte (Tablets, Netbooks usw.) verwendet werden.
Figurenliste
Die obigen Aspekte und viele der einhergehenden Vorteile der vorliegenden Erfindung werden ohne Weiteres ersichtlich, indem diese durch Bezugnahme auf die folgende ausführliche Beschreibung in Verbindung mit den beigefügten Zeichnungen, in denen sich gleiche Bezugszahlen in den verschiedenen Ansichten durchweg auf gleiche Teile beziehen, sofern es nicht anders angegeben ist, besser verständlich wird.

1 ist eine schematische Darstellung einer Ausführungsform einer Architektur für ein integriertes Android- und Windows-Gerät, das sowohl Android- als auch Windows-Anwendungen ausführen kann;
2 ist eine schematische Darstellung einer Softwarearchitektur, die implementiert wird, um Benutzungsszenarien zu ermöglichen, die eine Datenverarbeitungskarte, auf der ein Windows-OS läuft, und ein Android-Hostgerät verwenden;
3 ist eine schematische Blockdarstellung von Funktionsblöcken für eine Datenverarbeitungskarte gemäß einer Ausführungsform;
4 ist eine schematische Blockdarstellung von selektiven Komponenten zum Integrieren einer Datenverarbeitungskarte in ein Smartphone gemäß einer Ausführungsform;
5 ist eine schematische Blockdarstellung eines ersten Prozessors, der zur Implementierung in einer oder mehreren hier beschriebenen Ausführungsformen geeignet ist;
6 ist eine schematische Blockdarstellung eines zweiten Prozessors, der zur Implementierung in einer oder mehreren hier beschriebenen Ausführungsformen geeignet ist;
7 ist eine schematische Blockdarstellung von Komponenten, die durch eine Grafikvorrichtung zum Wiedergeben von nativen Grafikbefehlen und Inhalt verwendet werden;
8 ist eine schematische Blockdarstellung einer nativen Grafik-Werfer-Fänger-Architektur gemäß einer Ausführungsform;
8a ist eine schematische Blockdarstellung einer Android-Grafik-Werfer-Fänger-Architektur gemäß einer Ausführungsform;
9 ist eine schematische Blockdarstellung der Softwarekomponenten, die durch die Android-Architektur definiert werden;
10 ist eine schematische Block- und Datenflussdarstellung ausgewählter Android-Grafikkomponenten und Datenflüsse zwischen ihnen;
11 ist eine schematische Block- und Datenflussdarstellung ausgewählter Komponenten des Android-Grafiksystems und der Zusammensetzung von Grafikinhalt durch SurfaceFlinger und Hardware Composer von Android;
12a ist eine kombinierte schematische und Nachrichtenflussdarstellung einer Ausführungsform, die native Android-Grafikbefehle und -inhalte zu einem entfernten Android-Gerät wirft;
12a ist eine kombinierte schematische und Nachrichtenflussdarstellung einer Ausführungsform, die native Android-Grafikbefehle und -inhalte zu einem entfernten Android-Gerät wirft, das mehrere Sockets verwendet;
12b ist eine kombinierte schematische und Nachrichtenflussdarstellung einer zu der in 12a gezeigten alternativen Konfiguration, unter der OpenGL-Grafikbefehle unter Verwendung eines einzigen Sockets gesendet werden;
13 ist eine Blockdarstellung von Windows-Grafik-APIs und Anzeigetreiberschnittstellen;
14 ist eine Blockdarstellung von Windows-Softwarekomponenten zur Ermöglichung von Windows-Rendering-Operationen;
15 ist eine schematische Blockdarstellung einer Ausführungsform einer Windows-Grafik-Werfer-Fänger-Architektur, unter der ein Windows-Grafik-Werfer native Windows-Grafikbefehle zu einem entfernten Windows-Grafik-Fänger wirft;
16 ist eine schematische Blockdarstellung einer Ausführungsform einer Windows-Grafik-Werfer-Android-Grafik-Fänger-Architektur, unter der auf dem Windows-Werfergerät native Windows-Grafikbefehle und -inhalte in native Android-Grafikbefehle und -inhalte umgesetzt werden;
17a ist eine kombinierte schematische und Nachrichtenflussdarstellung einer Ausführungsform, die native Android-Grafikbefehle und -inhalte von einem Windows-Hostgerät zu einem entfernten Android-Gerät wirft, das mehrere Sockets verwendet, wobei native Windows-Grafikbefehle und -inhalte auf dem Windows-Hostgerät in Android-Grafikbefehle und -inhalte umgesetzt werden;
17b ist eine kombinierte schematische und Nachrichtenflussdarstellung einer zu der in 12a gezeigten alternativen Konfiguration, unter der OpenGL-Grafikbefehle unter Verwendung eines einzigen Sockets gesendet werden;
18 ist eine schematische Blockdarstellung einer Ausführungsform einer Windows-Grafik-Werfer-Androidgrafik-Fänger-Architektur, unter der native Windows-Grafikbefehle und -inhalte auf dem Android-Fängergerät in native Android-Grafikbefehle und -inhalte umgesetzt werden;
19a ist eine kombinierte schematische Block- und Nachrichtenflussdarstellung einer Ausführungsform eines integrierten Android- und Windows-Geräts, das einen Remote-Desktop-Server und -Client verwendet, um Benutzern zu ermöglichen, über ein Android-Hostgerät auf Windows-Anwendungen zuzugreifen;
19b ist eine kombinierte schematische Block- und Nachrichtenflussdarstellung einer ersten alternativen Implementierung, unter der native Windows-Grafikbefehle und - inhalte von einer Datenverarbeitungskarte geworfen werden, die ein Windows-Betriebssystem hostet;
19c ist eine kombinierte schematische Block- und Nachrichtenflussdarstellung einer zweiten alternativen Implementierung, unter der native Windows-Grafikbefehle auf der Datenverarbeitungskarte in Android-Grafikbefehle und -inhalte umgesetzt werden und zu einem auf dem Android-Hostgerät implementierten Android-Grafikfänger geworfen werden;
20 zeigt eine beispielhafte Bildschirmkopie einer auf einem integrierten Android/Windows-Gerät laufenden Windows-Anwendung;
21a und 21b zeigen Anzeigen einer vereinigten Schnittstelle mit mehreren Panels, darunter ein erstes Panel, das Android-Anwendungen aufweist, ein zweites Panel, das Windows-Anwendung aufweist, und ein drittes Panel, das kombinierte Datei-, Kontakt- und Email-Ordner zeigt, im Hoch- bzw. Querformat;
22 ist eine Darstellung einer Codierungsreihenfolge und Wiedergabereihenfolge einer Sequenz von I-Frames, P-Frames und B-Frames;
23 ist eine schematische Darstellung nativer Windows- oder Android-Grafik, die von einer Datenverarbeitungskarte zu einem Android-Hostgerät geworfen wird, das ferner dafür ausgelegt ist, Android-Grafikbefehle und -inhalte zu einem Android-TV zu werfen;
24a und 24b zeigen eine beispielhafte Implementierung eines integrierten Android/Windows-Geräts, das ein Backpack umfasst, in das ein Android-Gerät eingefügt wird;
25a, 25b und 25c zeigen beispielhafte Ansichten einer Datenverarbeitungskarte gemäß einer Ausführungsform;
26 zeigt eine Ausführungsform einer Prozessorplatine, die für Verwendung in der Datenverarbeitungskarte von 24b und 25a-25c geeignet ist.
27 ist eine schematische Blockdarstellung einer Übersicht über ausgewählte Komponenten in einer LDE-Architektur (Little Data Engine) auf hoher Ebene gemäß einer Ausführungsform;
28 ist eine schematische Blockdarstellung einer Architektur für den die Verarbeitung von Sensordaten betreffenden analytischen Stapel von LDE;
29 ist eine schematische Blockdarstellung einer Software-API für die LDE gemäß einer Ausführungsform;
30 ist eine Tabelle eines persönlichen Analytik-Benutzungsmodells 2200 gemäß einer Ausführungsform;
31 ist eine schematische Blockdarstellung einer Implementierungsarchitektur, die weitere Integration von hier besprochenen Komponenten darstellt;
32 ist eine schematische Blockdarstellung einer Ausführungsform einer Datenverarbeitungskarte, die einen USB-Verbinder des Typs C verwendet;
33 ist eine schematische Veranschaulichung von Schnittstellenschaltkreisen zwischen einem USB-Verbinder des Typs C und einer CPU und einem PMIC gemäß einer Ausführungsform;
34a und 34b sind perspektivische Ansichten einer Datenverarbeitungskarte, die einen USB-Verbinder des Typs C und einen Fingerabdruckleser umfasst, gemäß einer Ausführungsform; und
35a und 35b zeigen eine vordere bzw. hintere isometrische Ansicht eines Mobiltelefons, das mit der Datenverarbeitungskarte von 34a und 34b verbunden ist, gemäß einer Ausführungsform.

AUSFÜHRLICHE BESCHREIBUNG
Es werden hier Ausführungsformen integrierter Android- und Windows-Vorrichtungen beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein umfassendes Verständnis von Ausführungsformen der Erfindung zu gewährleisten. Für Fachleute ist jedoch erkennbar, dass die Erfindung ohne eine oder mehrere der spezifischen Einzelheiten oder mit anderen Verfahren, Komponenten, Materialien usw. praktiziert werden kann. In anderen Fällen sind wohlbekannte Strukturen, Materialien oder Operationen nicht im Detail gezeigt oder beschrieben, um Verschleierung von Aspekten der Erfindung zu vermeiden.
Der Klarheit halber können einzelne Komponenten in den vorliegenden Figuren auch durch ihre Kennzeichnungen in den Figuren bezeichnet werden, statt durch eine bestimmte Bezugszahl. Referenzzahlen, die sich auf eine bestimmte Art von Komponente (im Gegensatz zu einer bestimmten Komponente) beziehen, können außerdem mit einer Bezugszahl gezeigt sein, der „(typ.)“ folgt, was „typisch“ bedeutet. Es versteht sich, dass die Konfiguration dieser Komponenten typisch für ähnliche Komponenten ist, die existieren können, die aber der Einfachheit und Klarheit halber in den Zeichnungsfiguren nicht gezeigt sind, oder für anderweitig ähnliche Komponenten, die nicht mit getrennten Bezugszahlen gekennzeichnet sind. Umgekehrt soll „(typ.)“ nicht so aufgefasst werden, dass die Komponente, das Element usw. typischerweise für ihre bzw. seine offenbarte Funktion, Implementierung, Zweck usw. verwendet wird.
Die Ausdrücke „Kommunikationsnetz“ und „Kommunikationsnetze“ werden hier austauschbar verwendet, um sich auf ein oder mehrere Systeme und/oder Verfahren zum Senden und/oder Empfangen eines Datensignals zu beziehen. Diese Ausdrücke schließen Kommunikation mit kurzer Reichweite und Kommunikation mit großer Reichweite ein. Der Ausdruck „Kommunikation mit kurzer Reichweite“ bezieht sich hierbei auf Systeme und Verfahren zum drahtlosen Senden/Empfangen von Datensignalen zwischen Geräten, die einander relativ nahe sind. Kommunikation mit kurzer Reichweite umfasst zum Beispiel Kommunikation zwischen Geräten, die ein BLUETOOTH®-Netzwerk, ein PAN (Personal Area Network), NFC (Nahfeldkommunikation), RFID (Hochfrequenzidentifikation), ZigBee-Netzwerke, eine WiDi-Verbindung (Wireless Display) von INTEL®, eine WiGig-Verbindung (drahtlos mit Gigabit-Fähigkeit) von INTEL®, Millimeterwellenkommunikation, UHF-Kommunikation (ultrahohe Frequenz), Kombinationen davon und dergleichen verwenden. Kommunikation mit kurzer Reichweite kann deshalb als direkte Kommunikation zwischen Geräten ermöglichend aufgefasst werden, ohne Notwendigkeit dazwischentretender Hardware/Systeme wie Router, Mobilfunkmasten, Internet-Dienstanbieter und dergleichen.
Wie in jeder vorliegenden Ausführungsform gebraucht, kann sich der Ausdruck „Modul“ auf Software, Firmware und/oder Schaltkreise beziehen, die dafür ausgelegt ist/sind, das Ausführen einer oder mehrerer Operationen im Einklang mit der vorliegenden Offenbarung durchzuführen oder zu veranlassen.
Software kann als Softwarepaket, Code, Anweisungen, Anweisungssätze und/oder Daten realisiert sein, die auf nichttransitorischen computerlesbaren Speichermedien aufgezeichnet sind. Firmware kann als Code, Anweisungen oder Anweisungssätze und/oder Daten realisiert sein, die in nichtflüchtigen Speicherungsvorrichtungen gespeichert werden, darunter Vorrichtungen, die aktualisiert werden können (z. B. Flash-Speicher). „Schaltkreise“, so wie sie in jeder vorliegenden Ausführungsform verwendet werden, können zum Beispiel einzeln oder in einer beliebigen Kombination fest verdrahtete Schaltkreise, programmierbare Schaltkreise wie Computerprozessoren, die einen oder mehrere einzelne Anweisungsverarbeitungskerne umfassen, Automatenschaltkreise, Software und/oder Firmware, die Anweisungen speichert, die durch programmierbare Schaltkreise ausgeführt werden, umfassen. Die Module können zusammen oder einzeln als Schaltkreise realisiert sein, die einen Teil eines Client-Geräts oder eines Authentifizierungsgeräts bilden.
Der Klarheit halber und zum leichteren Verständnis beschreibt die vorliegende Offenbarung mobile Datenverarbeitungsgeräte und Bildschirme als ein oder mehrere in einem Speicher gespeicherte Module, wobei das Modul bzw. die Module computerlesbare Anweisungen umfasst bzw. umfassen, die, wenn sie durch einen Prozessor des betreffenden Geräts (mobiles Datenverarbeitungsgerät oder Bildschirm) ausgeführt werden, bewirken, dass das Gerät verschiedene Operationen ausführt. Es versteht sich, dass solche Beschreibungen beispielhaft sind und dass mobile Datenverarbeitungsgeräte und Bildschirme dafür ausgelegt sein können, Operationen auszuführen, die in Verbindung mit einem oder mehreren Modulen auf andere Weise beschrieben werden. Beispielsweise können die hier beschriebenen Datenverarbeitungsgeräte und Bildschirme Logik umfassen, die mindestens teilweise in Hardware implementiert ist, um das Ausführen einer oder mehrerer Operationen im Einklang mit der vorliegenden Offenbarung, wie etwa der in Verbindung mit verschiedenen hier identifizierten Modulen beschriebenen, zu veranlassen. In dieser Hinsicht wird angemerkt, dass „Logik“, so wie sie hier verwendet wird, diskrete und/oder analoge Schaltkreise umfassen kann, darunter zum Beispiel einen Vielzweckprozessor, einen DSP (digitalen Signalprozessor), ein SoC (System on Chip), Automatenschaltkreise, festverdrahtete Schaltungselemente, anwendungsspezifische integrierte Schaltungen, Kombinationen davon und dergleichen.
Die Verwendung von mobilen Geräten wie Mobiltelefonen, Smartphones, Tablet-PCs und Laptop-PCs hat drastisch zugenommen. Angesichts der weit verbreiteten Verwendung dieser mobilen Technologien konzentrieren sich Mikroprozessorentwickler zunehmend auf die Entwicklung von Prozessoren, die sowohl hohe Leistungsfähigkeit als auch niedrigen Stromverbrauch aufweisen. Ein Ziel einer solchen Entwicklung ist die Vergrößerung der Verarbeitungsfähigkeit unter Aufrechterhaltung oder sogar Vergrößerung der Batterielebensdauer des zugrundeliegenden Geräts. In einigen Fällen wurde gezeigt, dass Verkleinerung der Größe von Prozessorkomponenten die Prozessorleistungsfähigkeit verbessern kann, während gleichzeitig der Stromverbrauch verringert wird. In den kommenden Jahren wird erwartet, dass Herstellungstechniken die Produktion von Prozessoren mit „desktopartiger“ Datenverarbeitungsleistungsfähigkeit ermöglichen wird, sowie Stromverbrauch, der niedrig genug ist, um in einem mobilen Gerät verwendet zu werden.
In den letzten Jahren tendierte der Verbraucherbedarf in Richtung mobiler Geräte, die große integrale Displays aufweisen, aber dünn genug sind, um in eine Hosentasche oder kleine Tasche zu passen. Verbesserte Herstellungstechniken haben es Geräteherstellern erlaubt, die Ansteuerelektronik solcher Geräte zunehmend zu miniaturisieren. Obwohl dies die Produktion von zunehmend dünnen Geräten ermöglicht hat, werden die Längen- und Breiteabmessungen aktueller mobiler Geräte oft durch die Anforderung eines integralen Displays eingeschränkt. Während weitere Miniaturisierung der Ansteuerelektronik weitere Verringerungen der Gerätedicke ermöglichen kann, können Länge und Breite eines mobilen Geräts durch die entsprechenden Abmessungen eines integralen Displays vorgeschrieben werden. Dies kann den Grad begrenzen, zu dem ein mobiles Gerät als Ganzes miniaturisiert werden kann.
Wie oben besprochen ist es heutzutage üblich, dass Benutzer über mehrere Geräte verfügen, die jeweils ihre eigenen Anwendungen und Daten aufweisen. Obwohl einige Arten von Daten relativ portierbar über Plattformen sind (z. B. Bilder, die in Standardformaten wie JPEG und PNG gespeichert sind), gilt dies für andere nicht Dokumente, die durch Produktivitätsanwendungen wie Microsoft-Office-Produkte produziert werden). Dazu kommen persönliche Geräte in Unternehmensumgebungen, was oft als BYOD (Bring Your Own Device - eigenes Gerät bringen) bezeichnet wird. Dies führt zu einem massiven Problem für Manager der IT (Informationstechnologie), da es viel mehr Arten von Geräten und Daten zu verwalten gibt, wodurch Personalkosten steigen. Ein Ansatz bestand einfach darin, es Angestellten nicht zu gestatten, ihre eigenen Geräte für Unternehmenszwecke zu verwenden. BYOD ist jedoch nicht mehr wegzudenken, da Angestellte in vielen Industrien und Technologien erwarten, in der Lage zu sein, ihre eigenen vertrauten Geräte zu verwenden, und oft nicht gewillt sind, für Firmen zu arbeiten, die die Verwendung der persönlichen Geräte der Benutzer nicht gestatten.
Eines der Probleme ist das getrennte Verwalten von Firmendaten und persönlichen Daten auf demselben Gerät. Betriebssysteme stellen keine vorgegebenen Einrichtungen hierfür bereit, und Ansätze auf Anwendungsebene sind im Allgemeinen kläglich gescheitert. In einigen Unternehmungsumgebungen kann das Speichern bestimmter Arten von Daten und Dokumenten auf persönlichen Geräten nicht gestattet sein (und in einigen Fällen kann auch das Speichern auf durch die Firmen selbst bereitgestellten Computern nicht gestattet sein). Obwohl einige Gerätehersteller wie BlackBerry versucht haben, Geräte mit „zweifacher Personalität“ zu implementieren, die Firmendaten von persönlichen Daten trennen, bestand wenig Durchdringung solcher Geräte in Unternehmungsumgebungen.
Ein anderer persönlicher und Unternehmens-Benutzungsgesichtspunkt ist die Verwendung von Ressourcen auf Cloud-Basis sowohl zum Archivieren von Daten als auch zur Ermöglichung von aktiven Arbeitsplätzen. Persönliche Benutzer können oft Archivierungseinrichtungen auf Cloud-Basis als Sicherheitsmaßnahme verwenden, das heißt, wenn sie es nicht vergessen. Außerdem wird Archivierungseinrichtungen auf Cloud-Basis von einzelnen Benutzern und Unternehmen gleichermaßen nicht vertraut. Wie sicher sind ihre Daten? Manchmal wählen Verwendungen die Grenze kostenloser Speicherung, die entweder für ihre Bedürfnisse unzureichend ist (wie viele Benutzer haben nur 5 GB Daten auf ihren Geräten), oder zu schwierig, auf zweckmäßige Weise zu implementieren (die meisten Benutzer speichern ihre Daten nicht nur in einem einzigen oder einigen wenigen Ordnern). Jeder mit einem Gerät, das sich synchronisiert, weiß, dass es dazu kommen kann, dass dieselben Daten über mehrere Geräte propagiert werden.
Die Datenorganisation ist auch für viele Benutzer ein Problem. Wie können Benutzer leicht persönliche Daten von Unternehmensdaten trennen, nicht nur auf einem einzigen Gerät, sondern über alle Geräte hinweg, die sie verwenden können? Es muss eine bestimmte Datei gefunden werden..., die vor vielen Monaten erstellt wurde? Wie wäre es mit einer Menge von Dateien, die verwandte Daten auf einem Niveau für einen bestimmten Zweck enthalten, aber anderweitig für andere Zwecke nicht miteinander in Beziehung stehen, so dass es logisch nicht sinnvoll wäre, solche Dateien zusammen zu speichern. Während Suchwerkzeuge wie Spotlight von Apple OS X nett sind, geben sie typischerweise entweder eine zu sehr eingeschränkte oder zu wenig eingeschränkte Liste von Ergebnissen im Allgemeinen in einem verflachten Format zurück.
Viele Personen verwenden ein Smartphone für Aktivitäten wie Anrufe, Senden von Nachrichten, Browsen im Web, Musikhören, Fotos aufnehmen usw. Diese selben Personen können auch über einen oder mehrere Computer verfügen, auf denen eine Version von Microsoft Windows läuft, und sind mit der Verwendung bestimmter Windows-Anwendungen, wie etwa Microsoft-Office-Anwendungen, sowie vielen Anwendungen, die nur auf Windows laufen, vertraut und zufrieden. Der Versuch von Microsoft, aus seiner Dominanz auf dem Desktop- und Unternehmensanwendungsmarkt Kapital zu schlagen, ist gemäß den meisten Kriterien völlig fehlgeschlagen, und Microsoft hat sogar seine Benutzeroberfläche für Windows 8 völlig neu entworfen, um der von Windows Phone 7 und 8 verwendeten nahezukommen, um zu versuchen, mehr Benutzer auf Windows Phone migriert zu bekommen, aber ohne Erfolg.
In der letzten Zeit hat Microsoft sein Surface-3-Tablet der dritten Generation als besseres Gerät als Apple Airbook vermarktet, da es sowohl auf eine einem herkömmlichen Laptop ähnliche Weise betrieben werden kann, wenn eine Tastatur angeschlossen ist, als auch als Touchscreen-Tablet betrieben werden kann, wenn die Tastatur nicht angeschlossen ist. Das Surface 3 ist jedoch immer noch auf Microsoft-Windows-Anwendungen beschränkt und hat den Formfaktor eines Tablet.
Die dominantesten Betriebssysteme im Mobiltelefon- und Tablet-Raum sind das Android von Google. Seit seiner Einführung 2008 hat Android große Fortschritte erzielt und ist das favorisierte Mobil-Betriebssystem vieler Benutzer. Außerdem gibt es buchstäblich hunderte tausende Android-Anwendungen, die von PlayStore von Google erhältlich sind. Die Android-Plattform unterstützt jedoch nicht das Ausführen nativer Windows-Anwendungen und unterstützt auch nicht die Implementierung einer virtuellen Maschine, mit der native Windows-Anwendungen ausgeführt werden könnten.
Gemäß Aspekten der hier offenbarten Ausführungsformen wird ein integriertes Gerät bereitgestellt, das auf Android-Hardware laufende native Android-Anwendungen und auf INTEL®-x86-Hardware laufende Microsoft-Windows-Anwendungen unterstützt. In einem Aspekt wird dies durch Verwendung einer „Datenverarbeitungskarte“ ermöglicht, die entweder in das Gehäuse eines Android-Geräts eingebettet oder in einen Steckplatz in einem „Backpack“ eingebettet oder gekoppelt werden kann, mit dem das Android-Gerät über einen eingebauten Micro-USB-Verbinder gekoppelt ist.
1 zeigt eine beispielhafte Implementierung einer Datenverarbeitungskarte 100 und eines Android-Hostgeräts 102. Die Datenverarbeitungskarte 100 umfasst ein Prozessor-SoC 104, mit dem Speicher 106 und eine USB-Schnittstelle 108 wirksam gekoppelt sind. Abhängig von ihrer beabsichtigten Implementierung bzw. ihren beabsichtigten Implementierungen kann die Datenverarbeitungskarte 100 null oder mehr Schnittstellen zur drahtlosen Kommunikation (WCOMM) umfassen, die etwa durch eine WiFi-Schnittstelle (IEEE 802.11) 110 und eine BLUETOOTH®-Schnittstelle 112 abgebildet sind.
Das Android-Hostgerät 102 repräsentiert allgemein verschiedene Arten von Geräten, die ein Android-Betriebssystem verwenden.
Solche Geräte wären, aber ohne Beschränkung darauf, Mobiltelefone, Tablets, Netbooks (z. B. Chromebooks) und tragbare Geräte wie Google Glass und Android-Armbanduhren. Zur Veranschaulichung ist das Android-Hostgerät mit einem Prozessor-SoC 114 abgebildet, das eine GPU 116 umfasst, die wirksam mit Speicher 118, einer USB-Schnittstelle 120, einer WiFi-Schnittstelle 122 und einer BLUETOOTH®-Schnittstelle 124 gekoppelt ist. Ein Android-Hostgerät kann ferner andere drahtlose Kommunikationsschnittstellen umfassen, wie etwa ein Mobilfunk-Kommunikationssystem (z. B. ein LTE-Mobilfunk-Kommunikationssystem). Obwohl die GPU 116 als Teil des Prozessor-SoC 114 abgebildet ist, können bei einigen Implementierungen die GPU und das Prozessor-SoC getrennte Komponenten umfassen.
Die verschiedenen Schnittstellen zur Eingabe/Ausgabe (I/O), wie etwa drahtlose Kommunikationsschnittstellen, die in einigen der vorliegenden Figuren gezeigt sind, können im Allgemeinen als getrennte Komponenten abgebildet sein. Wie nachfolgend ausführlicher besprochen wird, können diese I/O-Schnittstellen in einem Prozessor-SoC implementiert sein, wobei in diesem Fall die getrennt gezeigten I/O-Schnittstellen einen Port, einen Verbinder oder eine Antenne repräsentieren.
Bei der in 1 dargestellten Ausführungsform ist die Datenverarbeitungskarte dafür ausgelegt, ein Betriebssystem von Microsoft Windows zu implementieren. Das Windows-Betriebssystem kann im Allgemeinen ein beliebiges oder zukünftige Windows-Betriebssysteme umfassen, wie etwa Windows 8.1 oder das (2015 herausgegebene) Windows 10. Die Betriebssysteme von Microsoft Windows sind darüber hinaus ein vollständiges Betriebssystem, das ursprünglich für Verwendung auf Desktop-Computern, Laptop-Computern, ausgewählten Tablets und dergleichen ausgelegt war.
Ausführlicher sind ausgewählte Komponenten eines Windows-Betriebssystems 126 als in Speicher 106 geladen abgebildet, darunter Grafikbibliotheken und APIs (Anwendungsprogrammschnittstellen) 128 und ein Grafiktreiber 130. Außerdem sind in dem Speicher 106 Symbole für mehrere Windows-Anwendungen 132 und einen virtuellen Anzeigepuffer 134 abgebildet, der zum Layouten und Rendern einer virtuellen Windows-GUI (grafischen Benutzeroberfläche) 136 verwendet wird. Windows-Anwendungen 132 laufen im „Benutzer“-Raum, während der Ausdruck „Kern“ hier im Kontext von Betriebssystemkomponenten verwendet werden kann, die herkömmlicherweise als in einem Betriebssystemkern implementiert betrachtet werden, wobei angemerkt wird, dass unter bestimmten Architekturansichten Treiber und Bibliotheken als sich in getrennten Betriebssystemschichten befindend betrachtet werden können, die sich außerhalb des OS-Kerns befinden, oder im Benutzerraum implementiert sein können.
Das Android-Hostgerät 102 führt ein Android-Betriebssytem 138 aus, das als in Speicher 118 geladen abgebildet ist und Grafikbibliotheken und APIs 140 und einen Grafiktreiber 142 umfasst. Außerdem sind mehrere Android-Anwendungen 144 als in dem Speicher 118 geladen abgebildet, darunter ein Remote-Desktop- bzw. RD-Client 146 von Windows, sowie ein Anzeigepuffer 148, mit dem Pixel-Bitmapinhalt gespeichert wird, der auf einem physischen Display 150 des Android-Hostgeräts 102 angezeigt wird.
Unter einem Benutzungsszenario ist die Datenverarbeitungskarte 100 über ein USB-Kabel, ein USB-Dock oder ein USB-Plugin in Kommunikation mit dem Android-Hostgerät 102 gekoppelt (z. B. weist die Datenverarbeitungskarte 100 ähnlich wie ein USB-Flash-Laufwerk einen männlichen USB-Schnittstellenverbinder auf), um dadurch eine physische USB-Verbindung zu bilden. Bei einer Ausführungsform wird die USB-Verbindung als eine IP/USB-Verbindung (IP über USB) 152 implementiert.
Bei einer Ausführungsform wird einem Benutzer ermöglicht, Windows-Anwendungen 132, die auf der Datenverarbeitungskarte 100 laufen, zu betrachten und mit diesen in Interaktion zu treten, während sie auf dem Display 150 des Android-Hostgeräts 102 angezeigt werden. Dies wird durch „Werfen“ von Grafikinhalt entfernt von der Datenverarbeitungskarte 100 über die IP/USB-Verbindung 152 zu dem Android-Hostgerät 102 ermöglicht, wie durch einen Strom von Grafik- bzw GFX-Paketen 154 abgebildet ist. Dem Android-Hostgerät 102 (z. B. über Touchscreen-Eingaben) zugeführte Benutzereingaben werden in Windows-Eingaben umgesetzt und dem Windows-Betriebssystem 126 zugeführt, wie durch einen Strom von Benutzereingabe- bzw. UI-Paketen 156 abgebildet ist.
2 zeigt ausgewählte Aspekte einer Softwarearchitektur, die implementiert wird, um Benutzungsszenarien zu ermöglichen, die eine Datenverarbeitungskarte, auf der ein Windows-OS läuft, und ein Android-Hostgerät verwenden. Die Softwarearchitektur umfasst eine Windows-Domäne 200, eine Android-Domäne 202 und eine Internet-Domäne 204. Die Windows-Domäne 200 und die Android-Domäne 202 werden jeweils weiter in einen Benutzerraum 202 und einen Systemraum 208 unterteilt.
Die Windows-Domäne 200 umfasst einen entfernten Server 210, der mit einem Manager 212 in der Android-Domäne 212 kommuniziert. Bei der in 2 dargestellten Ausführungsform wird Kommunikation zwischen dem entfernten Server 210 und dem Manager 212 über die IP/USB-Verbindung 152 ermöglicht. Als Alternative können der entfernte Server 210 und der Manager 212 unter Verwendung einer der verschiedenen hier beschriebenen und dargestellten drahtlosen Kommunikationsverbindungen kommunizieren.
Zusätzlich zu der Kommunikation mit dem entfernten Server 210 ist der Manager 212 auch als in der Lage abgebildet, über durch das Internet 214 ermöglichte Verbindungen auf verschiedene Internet-Ressourcen zuzugreifen. Die beispielhaften Internet-Ressourcen sind in 2 als Clouds abgebildet und umfassen einen Heimat-Cloud-Server 216, den Google Cloud Service 218, Dienste 220 der Apple iCloud, Dienste von Microsoft OneDrive und DropBox-Dienste 224. Unter verschiedenen Benutzungen kann der Manager 212 zum Zugriff auf Internet-Ressourcen für Anwendungen und Dienste, die in der Android-Domäne 202 laufen, verwendet werden oder kann als Gateway wirken, um es Anwendungen und Diensten, die in der Windows-Domäne 200 laufen, zu ermöglichen, auf die Internet-Domäne 204 zuzugreifen.
Der Einfachheit und Zweckmäßigkeit halber ist die IP/ USB-Verbindung 152 als eine direkte Verbindung zwischen dem entfernten Server 210 und dem Manager 212 gezeigt. Wie nachfolgend beschrieben und dargestellt wird, kann eine IP/USB-Kommunikationsverbindung jedoch eine logische Verbindung sein, die eine oder mehrere physische USB-Verbindungen umfasst.
Bei einer Ausführungsform wird Implementierung einer IP-Kommunikationsverbindung über eine oder mehrere physische USB-Verbindungen mittels existierender Vernetzungssoftwarestapel in Kombination mit eingebauten USB-Hardwareschnittstellen ermöglicht. Dies ist in 2 als Netzwerkstapel 226 und 228 abgebildet. Schicht 1 umfasst eine USB-Bitübertragungsschicht (PHY) 228, die unter Verwendung wohlbekannter standardisierter Techniken als herkömmliche USB-Verbindung konfiguriert ist. Im Allgemeinen kann die USB-PHY 228 einer beliebigen existierenden und zukünftigen USB-Verbindung entsprechen, wie etwa einer USB 2.0- oder USB 3.0-Verbindung. Die auf Software basierenden Vernetzungsschichten in der Android-Domäne 202 umfassen eine Medienzugangskanal- bzw. MAC-Schicht 230A, eine IP-Schicht 232A, eine Transportschicht 234A, eine Vermittlungsschicht 236A, eine Darstellungsschicht 238A und eine Anwendungsschicht 240A und eine Privatprotokollschicht 242A. Die auf Software basierenden Vernetzungsschichten in der Windows-Domäne 200 umfassen eine MAC-Schicht 230W, eine IP-Schicht 232W, eine Transportschicht 234W, eine Sitzungsschicht 236W, eine Darstellungsschicht 238W und eine Anwendungsschicht 240W und eine Privatprotokollschicht 242W.
Bei einer Ausführungsform verwenden die MAC-, IP-, Transport-, Sitzungs-, Darstellungs- und Anwendungsschichten existierende Vernetzungssoftwarekomponenten, die durch die Betriebssysteme Android und Windows bereitgestellt werden, und werden unter Verwendung wohlbekannter Techniken implementiert. Zum Beispiel verwendet im Kontext des Internetzugangs die IP-Schicht IPv4- oder IPv6-Adressen, implementiert die Transportschicht eines oder mehrere der Protokolle TCP und UDP, wird die Sitzungsschicht für IP-Sockets verwendet, wird die Darstellungsschicht zur Verschlüsselung verwendet und wird die Anwendungsschicht für HTTP (das Hypertext Transport Protocol) verwendet. Bei einer Ausführungsform wird die MAC-Schicht als eine Ethernet-MAC-Schicht implementiert, und von den Schichten über der MAC-Schicht an erscheint die PHY-Schicht als eine Ethernet-Verbindung. Bei einer Ausführungsform wird dies über die USB-PHY 228 ermöglicht. Unter einer optionalen Konfiguration wird ein „Shim“ 224 zwischen der USB-PHY 228 und den MAC-Schicht-Softwarekomponenten implementiert, wobei das Shim eine Ethernet-PHY-Schnittstelle zur MAC-Schicht freilegt. Als Ergebnis können die existierenden Android- und Windows-Vernetzungssoftwarekomponenten entweder ohne Modifikation oder mit minimalen Änderungen implementiert werden.
Die Privatprotokollschichten 242A und 242W werden verwendet, um zusätzliche Funktionalität bereitzustellen, wie etwa Sicherheitsmaßnahmen und Anwendungsfunktionalität. Aspekte des Privatprotokolls können als in einer oder mehreren der Sitzungs-, Darstellungs-, Anwendungsschicht oder Benutzer-/Anwendungsschicht implementiert betrachtet werden.
3 zeigt ausgewählte Komponenten einer Datenverarbeitungskarte 300 gemäß einer Ausführungsform. Die Datenverarbeitungskarte 300 umfasst eine Prozessorplatine, auf der verschiedene Komponenten angebracht sind und die (nicht gezeigte) Verbindungsverdrahtung zur Kopplung der Komponenten umfasst. Die ausgewählten Komponenten umfassen ein Prozessor-SoC 304, Systemspeicher 306 und eine EMMC (Embedded Multimedia Card) 308, ein Power-Management-IC (integrierte Schaltung, auch als „Chip“ bekannt) 310, ein Batterielade-IC 312, ein Tankanzeige-IC 314, einen Flash-Treiber 316, Flash-Speicher 318, ein Sensor-Hub 320. Außerdem ist ein Dock-Verbinder 322 mit einem Rand der Prozessorplatine 302 gekoppelt, wodurch eine Verbindung mehrerer I/O-Signale mit externen Komponenten über geeignete Kabel mit passenden Verbindern (oder Verwendung eines an einer externen Komponente angebrachten passenden Verbinders) (beides nicht gezeigt) ermöglicht wird. Der Dock-Verbinder 322 ist mit einem Stromversorgungsverbinder 324, einem HDMI-Verbinder 326, einem USB-3.0-Verbinder 330 und zwei USB-2.0-Verbindern 330 und 332 abgebildet. Der Stromversorgungsverbinder 324 ist mit dem Tankanzeige-IC 324 gekoppelt, während der HDMI-Verbinder mit HDMI-Pegelumsetzern 334 gekoppelt ist, ihrerseits mit einer HDMI-Schnittstelle 336 auf dem Prozessor-SoC 304 gekoppelt. Das Prozessor-SoC 304 ist ferner mit einer USB 3.0-Schnittstelle 338 und USB 2.0-Schnittstellen 340 und 342 abgebildet, die jeweils mit dem USB-3.0-Verbinder 328, dem USB-2.0-Verbinder 330 und dem USB-2.0-Verbinder 332 gekoppelt sind. Zusätzlich zu diesen in 3 abgebildeten Schnittstellen umfasst das Prozessor-SoC 304 weitere Schnittstellen, die nicht gezeigt sind, um Wirrwar zu vermeiden, die aber nachfolgend in Verbindung mit den in 5 und 6 gezeigten beispielhaften Prozessor-SoCs besprochen werden.
Im Allgemeinen kann der Prozessor 304 ein beliebiger Prozessor sein, der dafür ausgelegt ist, die Funktionalität einer konkreten Implementierung oder Menge von Implementierungen wie hier beschrieben zu unterstützen. zum Beispiel kann der Prozessor 304 ein Einzel- oder Mehrkernprozessor, ein Vielzweckprozessor, eine anwendungsspezifische integrierte Schaltung, Kombinationen davon und dergleichen sein. Ohne Beschränkung ist der Prozessor 304 vorzugsweise einer oder mehrere Prozessoren, die von der Intel^Ⓡ Corporation, NVIDIA^Ⓡ, ARM^®, Advanced Micro Devices (AMD^®), SAMSUNG^®, APPLE^® oder QUALCOMM^Ⓡ zum Verkauf angeboten werden. Nichteinschränkende Beispiele für geeignete Prozessoren wären die von Intel^Ⓡ verkauften Prozessorlinien ATOM^Ⓡ, Nehalem, Ivy Bridge und Sandy Bridge.
Im Allgemeinen können die Verbinder an dem Dock-Verbinder 322 einzelne physische Verbinder umfassen, oder mehrere Verbinder können sich einen physischen Verbinder teilen. Zum Beispiel umfasst bei einer Ausführungsform der Dock-Verbinder 322 einen physischen Mikro-USB-Verbinder, der dafür ausgelegt ist, eine Stromversorgungs- und I/O-Einzelschnittstelle für den Stromversorgungsverbinder 324 und einen oder mehrere des USB-3.0-Verbinders 328, USB-2.0-Verbinders 330 und USB-2.0-Verbinders 332 zu unterstützen. Der Mikro-USB-Verbinder kann auch dafür ausgelegt sein, eine HDMI-Signalschnittstelle zu unterstützen, die eine MHL-Verbindung (Mobile High-Definition Link) verwendet.
Das Sensor-Hub 320 fungiert als I/O-Schnittstelle, um verschiedene Daten mit dem Prozessor-SoC 302 zu koppeln. Bei der dargestellten Ausführungsform gehören zu diesen ein Näherungssensor 344, ein Beschleunigungsmesser 346, ein Kreiselsensor 348, ein Umgebungslichtsensor 350 und ein Biometriksensor 352.
Der Systemspeicher 306 umfasst vorzugsweise eine bestimmte Art von dynamischem Direktzugriffsspeicher (DRAM), wie etwa, aber ohne Beschränkung darauf, DDR2- oder DDR3-DRAM. Der Flash-Speicher 318 veranschaulicht verschiedene Arten von nichtflüchtigem Speicher und kann im Allgemeinen zum Beispiel Speicherstrukturen des NAND- oder NOR-Typs umfassen. Zusätzlich oder als Alternative können der Systemspeicher 306 und/oder der Flash-Speicher 318 andere und/oder später entwickelte Arten von computerlesbarem Speicher umfassen. Der Systemspeicher 306 kann mit dem Prozessor 304 integral, von Prozessor 304 getrennt oder eine Kombination davon sein. Wie nachfolgend besprochen kann der Flash-Speicher 318 ein oder mehrere Module speichern, die computerlesbare Anweisungen umfassen, die, wenn sie durch den Prozessor 304 ausgeführt werden, bewirken können, dass ein Gerät, in dem die Datenverarbeitungskarte 300 implementiert ist, mit der vorliegenden Offenbarung vereinbarte Funktionen ausführt.
Abhängig von der konkreten Implementierung kann die Datenverarbeitungskarte 300 ein oder mehrere drahtlose Kommunikationsmittel, abgebildet durch WCOMMS 354, umfassen. WCOMMS 354 kann Hardware (z. B. Schaltkreise), Software oder eine Kombination von Hardware und Software umfassen, wodurch die Datenverarbeitungskarte 300 Signale über ein oder mehrere drahtlose Kommunikationsnetze und/oder über Peer-to-Peer-Kommunikation senden und empfangen kann. Zum Beispiel kann WCOMMS 204 eine(n) oder mehrere Antennen, Sender, Empfänger, Sendeempfänger, Transponder, Netzwerkschnittstellen-Kommunikationsschaltkreise und Kombinationen davon umfassen, wodurch die Datenverarbeitungskarte 300 über ein oder mehrere drahtlose Kommunikationsprotokolle Signale senden und empfangen kann. Beispiele für solche drahtlosen Kommunikationsprotokolle wären Protokolle auf der Basis von IEEE 802.11 (was auch als WiFi bekannt ist) und BLUETOOTH^®-Nahfeldkommunikation. Außerdem kann die Datenverarbeitungskarte 300 dafür ausgelegt sein, Hochfrequenzidentifikation (RFID) für Authentifizierungs- und verwandte Zwecke zu verwenden, wie nachfolgend beschrieben wird.
4 zeigt eine Ausführungsform einer Smartphone-Implementierung, bei der eine Datenverarbeitungskarte 300 über eine USB-Adapterplatine 404 mit einem Smartphone 402 gekoppelt ist. Wie abgebildet umfasst die USB-Adapterplatine 404 ein USB-Hub 406, einen USB-Verbinder 408, eine Batterie 410, ein Lademodul 412 und eine Status-LED-und-Einschalttaste 414. Das USB-Hub 406 ist mit einem USB-Verbinder 416 an dem Smartphone 402 verbunden. Wenn der Dock-Verbinder 322 mit einem (nicht gezeigten) passenden Verbinder an der USB-Adapterplatine 404 gekoppelt ist, der USB-Verbinder 328 an dem Dock-Verbinder 322, während der USB-Verbinder 408 mit dem USB-Verbinder 330 verbunden ist, die Batterie 410 mit dem Stromversorgungsverbinder 332 verbunden ist und die Status-LED-und-Einschalttaste 414 mit der LED-Taste 324 verbunden ist.
5 zeigt einen Prozessor 500, der in einer oder mehreren hier beschriebenen Ausführungsformen verwendet werden kann. Der Prozessor 500 umfasst eine SoC-Architektur und umfasst mehrere INTEL®-ATOM®-Kerne 502, die mit einem Paar von L2-Caches (Level 2) 504 und 506, einem Grafikprozessor 508, Speichercontrollern 510, einem Systemagenten 512, einer Koppelfeldverbindung 514, CSE 516, Sensoren 518, einer Anzeigeschnittstelle 520, einer IUnit 522, einem Biometrikblock 524, einem Audioblock 526, einem drahtlosen Block 528 und einer I/O-Schnittstelle 530 gekoppelt sind. Der Prozessor 500 ist dafür ausgelegt, einen oder mehrere von ATOM®-Kernen 502 zum Hosten eines Betriebssystems 532 zu verwenden.
6 zeigt einen Prozessor 600, der auch in einer oder mehreren hier beschriebenen Ausführungsformen verwendet werden kann. Eine Anzahl von Komponenten in dem Prozessor 500 mit gleichen Bezugszahlen ist wie gezeigt auch in dem Prozessor 600 anwesend. Zusätzlich umfasst der Prozessor 600 zwei Prozessorkerne 602 und 604, jeweils mit einem jeweiligen L2-Cache 606 und 608, einen Systemagenten 610 mit Profilservern 612, einen skalierbaren I/O-Block 614 und einen sicheren Datenblock 616.
Die Kerne 602 und 604 werden als „Big“-Kerne und die ATOM®-Kerne 502 als „Little“-Kerne bezeichnet. Die Kerne 602 und 604 stellen wesentlich höhere Leistungsfähigkeit als ein ATOM®-Kern 602 bereit, aber auf Kosten eines signifikant höheren Stromverbrauchs. Um sowohl hochleistungsfähige als auch energiesparende Prozessorkerne nutzen zu können, arbeiten die Profilserver 612 in Verbindung mit einem Modul 618 der Unterstützung von Little/Big & Profil in der Referenzplattform-Abstraktionsschicht 620, um es dem Prozessor 600 zu ermöglichen, die Kerne 502 und 504 zu verwenden, wenn Strom zum Betrieb in einem Hochleistungsprofil verfügbar ist, während sie die ATOM®-Kerne 602 beim Betrieb in einem energiesparenderen Profil verwendet. Die Referenzplattform-Abstraktionsschicht 620 stellt eine Schicht der Abstraktion zwischen einem Betriebssystem 622 und dem Prozessor 600 bereit, so dass das Betriebssystem 622 befähigt wird, ohne jegliche Notwendigkeit, das Betriebssystem zu modifizieren, unter einem Umfang von Profiloptionen zu arbeiten.
Native Grafik-Werfer-Fänger-Architekturen
7 zeigt eine abstrahierte Grafik-Rendering-Architektur eines generischen Grafikgeräts 700, das Geräteanwendungen 702, Grafik-APIs 704, ein Grafik-Rendering-Subsystem 706, einen Anzeigepuffer 708 und eine Anzeige 710 umfasst. Auf dem Betriebssystem des Grafikgeräts laufende Geräteanwendungen 702 geben native Grafikbefehle an die Grafik-APIs 704 aus. Die nativen Grafikbefehle umfassen im Allgemeinen einen beliebigen Grafikbefehl, der zum Rendern von Inhalt auf einer gegebenen Plattform oder einem gegebenen Gerät verwendet werden kann, und ohne Beschränkung auf eine konkrete Menge von APIs in dieser Grafikarchitektur. Zum Beispiel können die nativen Grafikbefehle im Allgemeinen einen beliebigen Grafikbefehl umfassen, der durch die Betriebssystem-/Geräteimplementierung unterstützt wird; ausführlichere Einzelheiten beispielhafter APIs werden nachfolgend besprochen.
Die Grafik-APIs 704 sind dafür ausgelegt, zwei Rendering-Pfade zu unterstützen: 1) einen Software-Rendering-Pfad; und 2) einen Hardware-Rendering-Pfad. Der Software-Rendering-Pfad beinhaltet Verwendung von Software, die auf dem Hostprozessor des Grafikgeräts, wie etwa einer Zentralverarbeitungseinheit (CPU) ausgeführt wird, was durch Software-Rendering 712 abgebildet ist. Dies wird im Allgemeinen über eine oder mehrere Laufzeit-Grafikbibliotheken 713 implementiert, auf die über Ausführung entsprechender Grafik-APIs 704 zugegriffen wird. Im Gegensatz dazu ist der Hardware-Rendering-Pfad dafür ausgelegt, Grafik unter Verwendung einer oder mehrerer auf Hardware basierender Rendering-Vorrichtungen, wie etwa einer GPU 714, zu rendern. Obwohl eine GPU intern eingebettete Software (nicht gezeigt) zum Ausführen einiger ihrer Operationen verwenden kann, wird solche eingebettete Software über eine Grafikbibliothek, die Geräteanwendungen 702 zugänglich ist, nicht freigelegt, und somit wird Rendern von Grafikinhalt auf einer GPU nicht als Software-Rendern betrachtet.
Das Grafik-Rendering-Subsystem 706 ist ferner mit BitmapPuffern 714 und einem Zusammensteller 718 abgebildet. Software-Rendern beinhaltet im Allgemeinen Rendern von GrafikInhalt als Bitmaps, die virtuelle Zeichnungsoberflächen oder dergleichen umfassen, die als Bitmappuffer 716 in Speicher (z. B. Systemspeicher) zugeteilt sind. Abhängig von der Terminologie, die die Softwareplattform für das Grafikgerät 700 verwendet, werden die Bitmappuffer typischerweise als Schichten, Oberflächen, Ansichten und/oder Fenster bezeichnet. Für Visualisierungszwecke stelle man sich einen Bitmappuffer als ein virtuelles Blatt Papier vor, das ein Array winziger Kästen aufweist, auf die Inhalt „gemalt“ werden kann, indem die Kästen mit verschiedenen Farben gefüllt werden.
Die GPU 714 rendert Inhalt unter Verwendung mathematischer Manipulation von Texturen und anderem Inhalt sowie Unterstützung des Renderns von Inhalt auf Vektorbasis. Die GPU 714 verwendet auch Bitmap-Puffer sowohl intern (nicht gezeigt) als auch im Speicher. Dazu kann Systemspeicher gehören, Speicher, der der GPU gewidmet ist (entweder Speicher auf dem Chip oder Speicher außerhalb des Chips) oder eine Kombination von beidem. Wenn zum Beispiel die GPU in einer Grafikkarte in einem PC oder einem getrennten Grafikchip in einem Laptop enthalten ist, enthält die Grafikkarte oder der Grafikchip im Allgemeinen Speicher, der für GPU-Verwendung gewidmet ist. Bei mobilen Geräten wie Smartphones und Tablets wird die GPU tatsächlich in das Prozessor-SoC eingebettet und wird typischerweise einigen Speicher auf dem Chip sowie Speicher verwenden, der entweder auf dem SoC oder auf einem getrennten Speicherchip eingebettet ist.
Der Zusammensteller 718 wird zum „Zusammenstellen“ des Endgrafikinhalts verwendet, der auf dem Anzeigebildschirm des Grafikgeräts gezeigt wird. Dies wird durchgeführt, indem verschiedener Bitmapinhalt in den Bitmappuffern 716 und durch die GPU 714 gerenderten Puffern (nicht gezeigt) kombiniert und der zusammengestellte Bitmapinhalt in den Anzeigepuffer 708 geschrieben wird. Der Anzeigepuffer 716 wird dann unter Verwendung einer Auffrischrate ausgelesen, um zu bewirken, dass grafischer Bitmapinhalt auf einer Anzeige 718 angezeigt wird. Gegebenenfalls kann Grafikinhalt in einen „Back“-Puffer oder „Backing-Store“ geschrieben werden, der dann in den Anzeigepuffer kopiert wird, oder es kann ein „Pingpong“-Schema verwendet werden, bei dem der Back-Puffer und der Anzeigepuffer konzertiert mit der Auffrischrate umgewechselt werden.
In 8 ist eine beispielhafte native Grafik-Werfer-Fänger-Architektur mit einer Werfer-Vorrichtung 800 gezeigt, die native Grafikbefehle und Inhalt über eine Verbindung 804 zu einem Fängergerät 802 wirft. Wie durch gleiche Bezugszahlen in 7 und 8 angegeben, ist die Grafikarchitektur des Werfergeräts 800 der Grafikarchitektur des Grafikgeräts 700 ähnlich. In der Zwischenzeit werden Komponenten, die das Grafik-Rendering-Subsystem 706 umfassen, wie durch das Grafik-Rendering-Subsystem 706R abgebildet auf dem Fängergerät 802 repliziert. Das Fängergerät 802 umfasst ferner einen Anzeigepuffer 805 und eine Anzeige 806, die im Allgemeinen auf ähnliche Weise wie der Anzeigepuffer 708 und die Anzeige 710 funktionieren, aber andere Puffergrößen und/oder Konfigurationen aufweisen können, und die Auflösung der Anzeige 806 und der Anzeige 710 können gleich oder verschieden sein.
Das Werfen von nativen Grafikbefehlen und -inhalten wird durch jeweilige Werfer- und Fängerkomponenten auf dem Werfergerät 800 und dem Fängergerät 800 ermöglicht, die einen nativen Grafikwerfer 808 und einen nativen Grafikfänger 810 umfassen. Diese Komponenten helfen dabei, das Werfen von nativen Grafikbefehlen und -inhalten auf die folgende Weise zu ermöglichen.
Bei einer Ausführungsform wird der native Grafikwerfer 808 als ein virtueller Grafiktreiber oder dergleichen implementiert, der eine Schnittstelle bereitstellt, die dem Grafik-Rendering-Subsystem 706 ähnlich ist. Grafikbefehle und -inhalte, die sowohl dem Software-Rendering-Pfad als auch dem Hardware-Rendering-Pfad entsprechen, die von den Grafik-APIs 704 ausgegeben werden, werden zu dem nativen Grafik-Werfer 808 gesendet. Abhängig vom Betriebsmodus kann der native Grafik-Werfer 808 als ein Fallen- und Durchgangs-Grafik-Treiber konfiguriert sein oder kann als ein abfangender Grafiktreiber arbeiten. Bei Betrieb als Fallen- und Durchgangs-Grafik-Treiber werden native Grafikbefehle und -inhalte eingefangen, gepuffert und zu dem nativen Grafik-Fänger 810 gesendet. Die gepufferten Befehle werden auch auf transparente Weise zu dem Grafik-Rendering-Subsystem 706 durchgelassen, so dass die Grafik auf dem Werfergerät 800 genauso wie das Grafikgerät 700 zu arbeiten scheint. Unter einem abfangenden Grafiktreiber werden die Grafikbefehle nicht auf dem Werfergerät 800 durchgelassen.
Wie ohne Weiteres zu beobachten ist, implementiert die Werfer-Fänger-Architektur von 8 eine aufgeteilte Grafikarchitektur, wobei das Grafik-Rendering-Subsystem auf das Fängergerät verlagert (oder anderweitig darauf repliziert) wird. Vom Standpunkt des Grafik-Rendering-Subsystems 706R aus gesehen, gibt der native Grafikfänger 810 Grafikbefehle und - inhalte zusammen sowohl mit dem Software(SWF)- als auch Hardware-Rendering-Pfad so aus, als würde dieser Inhalt direkt durch Grafik-APIs 704 bereitgestellt. Das Ergebnis ist, dass Grafikinhalte auf dem entfernten drahtlosen Gerät (d. h. dem Fängergerät 802) mit einer ähnlichen Geschwindigkeit wie auf einem Grafikgerät selbst gerendert werden können (wenn ähnliche Hardwarekomponenten für die Grafik-Rendering-Subsysteme 706 und 706R implementiert werden). Es tritt im Wesentlichen keine Latenz durch den Grafikbefehle- und -inhaltewerfprozess auf, und die Menge an sich aus solcher Latenz ergebender Verzögerung ist im Allgemeinen für den Benutzer nicht wahrnehmbar, insbesondere für Grafikbefehle und -inhalte, die über den Hardware-Rendering-Pfad gerendert werden. Die größte Menge an Latenz wird typischerweise das Werfen eines großen Bildes (z. B. eines großen JPEG- oder PNG-Bildes) beinhalten, das durch Transferien der komprimierten Bilddatei selbst vom Werfer zum Fänger implementiert werden kann.
Um Initialisierung und Betrieb der Verbindung 804 zu unterstützen, umfassen das Werfergerät 800 und das Fängergerät 802 jeweils Verbindungsstapelmodule 812 und 814. Bei einigen Ausführungsformen arbeitet das Werfergerät 800 als Quelle und das Fängergerät 802 als Senke, und es ist entsprechende Software zur Ermöglichung einer Quelle/Senke-Verbindungskonfiguration vorhanden. Zum Beispiel umfasst bei einer Ausführungsform die Verbindung 804 eine WFD-Verbindung (WiFi Direct®), die eine WFD-Quelle und eine WFD-Senke umfasst.
Android-Grafik-Rendering
9 zeigt eine Darstellung der Android-Softwarearchitektur 900. Die Android-Softwarearchitektur umfasst einen Linux-Kern 902, Bibliotheken 904, Android-Laufzeit 906, einen Anwendungs-Rahmen 908 und Anwendungen 910.
Der Linux-Kern 902 nimmt die niedrigste Schicht in dem Android-Softwarestapel ein und stellt eine Abstraktionsebene zwischen der Android-Gerätehardware und den oberen Schichten des Android-Softwarestapels bereit. Während sich ein Teil des Linux-Kerns 902 Code mit Linux-Kernkomponenten für Desktops und Server teilt, gibt es einige Komponenten, die speziell durch Google für Android implementiert sind. Eine neuere Version von Android, Android 4.4 („auch als „KitKat“ bekannt) basiert auf dem Linux-Kern 3.4 oder neuer (man beachte, dass die tatsächliche Kern-Version von dem konkreten Android-Gerät und -Chipsatz abhängt). Die dargestellten Komponenten des Linux-Kerns 902 umfassen einen Anzeigetreiber 912, einen Kameratreiber 914, einen Bluetooth-Treiber 916, einen Flash-Speicher 918, einen Bindertreiber 920, einen USB-Treiber 922, einen Tastenfeldtreiber 924, einen WiFi-Treiber 926, einen Audiotreiber 928 und Power-Management 930.
Über dem Linux-Kern 902 befinden sich Bibliotheken 904, die in C/C++ geschriebene Middleware, Bibliotheken und APIs umfassen, und Anwendungen 910, die auf dem Anwendungs-Rahmen 908 laufen. Die Bibliotheken 904 werden durch einen Android-Gerätevertreiber für eine bestimmte Hardwareabstraktion wie etwa eine spezifische CPU kompiliert und vorinstalliert. Die Bibliotheken umfassen einen Oberflächenmanager 932, einen Medien-Rahmen 934, eine SQLite-Datenbankengine 936, ein OpenGL-ES (eingebettetes System) 938, eine FreeType-Frontbibliothek 940, ein WebKit 942, eine Skia-Grafikbibliothek (SGL) 944, eine SSL-Bibliothek (Secure Socket Layer) 946 und die Libc-Bibliothek 948. Der Oberflächenmanager 932, der auch als „SurfaceFlinger“ bezeichnet wird, ist ein Grafikzusammenstellungsmanager, der Grafikinhalte für Oberflächen zusammenstellt, die Außerbildschirm-Bitmaps umfassen, die mit anderen Oberflächen kombiniert werden, um Grafikinhalt zu erzeugen, der auf einem Android-Gerät angezeigt wird, wie nachfolgend ausführlicher besprochen wird. Der Medien-Rahmen 934 umfasst Bibliotheken und Codecs, die für verschiedene Multimediaanwendungen, wie etwa Wiedergeben und Aufzeichnen von Videos, verwendet werden, und unterstützt viele Formate wie AAC, H.264 AVC, H.263, MP3 und MPEG-4. Die SQLite-Datenbank erfreut sich der Verwendung zum Speichern von und Zugreifen auf Daten und unterstützt verschiedene SQL-Datenbankfunktionen.
Die Android-Softwarearchitektur verwendet mehrere Komponenten zum Rendern von Grafik, darunter OpenGL-ES 938, SGL 944, die FreeType-Fontbibliothek 940 und das WebKit 942. Weitere Einzelheiten des Android-Grafikrenderns werden nachfolgend mit Bezug auf 8 besprochen.
Die Android-Laufzeit 906 verwendet die Dalvik-VM (virtuelle Maschine) 950 und Kernbibliotheken 952. Android-Anwendungen werden in Java geschrieben (man beachte, dass Android 4.4 auch in C/C++ geschriebene Anwendungen unterstützt). Herkömmliche Java-Programmierung verwendet die JVM (Java Virtual Machine) zum Ausführen von Java-Bytecode, der durch einen Java-Compiler erzeugt wird, mit dem Java-Anwendungen kompiliert werden. Im Gegensatz zu JVMs, die Stapelmaschinen sind, verwendet die Dalvik-VM eine Architektur auf Registerbasis, die weniger und typischerweise kompliziertere Anweisungen virtueller Maschinen erfordert. Dalvik-Programme werden unter Verwendung von Android-APIs in Java geschrieben, in Java-Bytecode kompiliert und je nach Bedarf in Dalvik-Anweisungen umgesetzt. Die Kernbibliotheken 952 unterstützen ähnliche Java-Funktionen, die in Java SE (Standard Edition) enthalten sind, aber speziell dafür ausgelegt sind, Android zu unterstützen.
Der Anwendungs-Rahmen 908 umfasst Baublöcke auf hoher Ebene, die zur Implementierung von Android-Anwendungen 910 verwendet werden. Diese Baublöcke umfassen einen Aktivitätsmanager 954, einen Windows-Manager 956, Inhaltsanbieter 958, ein Ansichtsystem 960, einen Benachrichtigungsmanager 962, einen Paket-Manager 964, einen Telefoniemanager 966, einen Ressourcenmanager 968, einen Ortsmanager 970 und einen XMPP-Dienst (Extensible Messaging and Presence Protocol) 972.
Zu den Anwendungen 910 gehören verschiedene Anwendungen, die auf einer Android-Plattform laufen, sowie Widgets, abgebildet durch eine Start-Anwendung 974, eine Kontakte-Anwendung 976, eine Telefon-Anwendung 978 und einen Browser 980. Die Anwendungen können für die konkrete Art von Android-Plattform zurechtgeschnitten sein, etwa hätte ein Tablet ohne Mobilfunkunterstützung keine Telefonanwendung und kann zusätzliche Anwendungen aufweisen, die für die größere Größe eines Bildschirms eines Tablets (verglichen mit einer typischen Android-Smartphone-Bildschirmgröße) ausgelegt sind.
Die Android-Softwarearchitektur bietet vielfältige Grafik-Rendering-APIs für 2D- und 3D-Inhalt, die mit Herstellerimplementierungen von Grafiktreibern in Wechselwirkung treten. Anwendungsentwickler zeichnen Grafikinhalt auf dem Anzeigebildschirm jedoch auf zwei Weisen, mit Canvas oder OpenGL.
10 zeigt ausgewählte Android-Grafikkomponenten. Diese Komponenten werden als Bild-Stream-Produzenten 1000, Rahmen/nativ/Bib./GUI-Module 1002, Bild-Stream-Konsumenten 1004 und eine Hardware-Abstraktionsschicht (HAL) 1006 gruppiert. Ein Bild-Stream-Produzent kann irgendetwas sein, das Grafikpuffer zum Verbrauch produziert. Beispiele wären ein Medien-Player 1008, eine Kameravorschau-Anwendung 1010, Canvas 2D 1012 und OpenGL ES 1014. Die Rahmen/nativ/Bib./GUI-Module 1002 sind C++-Module und umfassen Surface.cpp 1016, iGraphicBufferProduce 1018 und GLConsumer.cpp 1020. Die Bild-Stream-Konsumenten 1004 umfassen SurfaceFlinger 1022 und OpenGL-ES-Anwendungen 1024. Die HAL 1006 umfasst einen Hardwarezusammensteller 1026 und einen Grafikspeicherzuteiler (Gralloc) 1028. Die in 10 abgebildeten Grafikkomponenten umfassen auch einen WindowsManager 1030.
Der häufigste Konsument von Bild-Streams ist SurfaceFlinger 1022, der Systemdienst, der die aktuell sichtbaren Oberflächen konsumiert und sie unter Verwendung von durch den Fenstermanager 1024 bereitgestellten Informationen auf der Anzeige zusammenstellt. SurfaceFlinger 1022 ist der einzige Dienst, der den Inhalt der Anzeige modifizieren kann. SurfaceFlinger 1022 verwendet OpenGL und den Hardware-Zusammensteller zum Zusammenstellen einer Gruppe von Oberflächen. Es können auch andere OpenGL-ES-Apps 1024 Bild-Streams konsumieren, wie etwa die Kamera-App, die einen Bild-Stream der Kameravorschau 1010 konsumiert.
Der Fenstermanager 1030 ist der Android-Systemdienst, der ein Fenster steuert, das ein Container für Ansichten ist. Ein Fenster hat immer eine Oberfläche als Hintergrund. Dieser Dienst beaufsichtigt Lebenszyklen, Eingabe- und Fokusereignisse, Bildschirmorientierung, Übergänge, Animationen, Position, Transformationen, Z-Ordnung und viele andere Aspekte eines Fensters. Der Fenstermanager 1030 sendet alle Fenster-Metadaten zu SurfaceFlinger 1022, so dass SurfaceFlinger mit diesen Daten Oberflächen auf der Anzeige zusammenstellen kann.
Der Hardware-Zusammensteller 1026 ist die Hardwareabstraktion für das Anzeigesubsystem. SurfaceFlinger 1022 kann bestimmte Zusammenstellungsarbeit an den Hardware-Zusammensteller 1026 delegieren, um Arbeit von OpenGL und der GPU abzuladen. SurfaceFlinger 1022 wirkt als ein anderer OpenGL-ES-Client. Wenn also SurfaceFlinger aktiv einen Puffer oder zwei zu einem dritten zusammenstellt, verwendet es zum Beispiel OpenGL ES. Dadurch verbraucht das Zusammenstellen weniger Strom als wenn die GPU alle Berechnung durchführt. Der Hardware-Zusammensteller 1026 führt die andere Hälfte der Arbeit aus. Diese HAL-Komponente ist der zentrale Punkt für jegliches Android-Grafik-Rendering. Der Hardware-Zusammensteller 1026 unterstützt verschiedene Ereignisse, darunter VSYNC und Hotplug für Plug-and-Play-HDMI-Unterstützung.
Android.graphics.Canvas ist eine 2D-Grafik-API und ist unter Entwicklern die beliebteste Grafik-API. Canvas-Operationen zeichnen die Standard- und angepassten android.view.Views in Android. In Android wird Hardwarebeschleunigung für Canvas-APIs mit einer Zeichnungsbibliothek erzielt, die als OpenGLRenderer bezeichnet wird, die Canvas-Operationen in OpenGL-Operationen übersetzt, so dass sie auf der GPU ausgeführt werden können.
Beginnend mit Android 4.0 ist der hardwarebeschleunigte Canvas als Vorgabe freigegeben. Eine Hardware-GPU, die OpenGL ES 2.0 (oder neuer) unterstützt, ist für Android-4.0 und neuere Geräte zwingend. Android 4.4 erfordert OpenGL-ES-3.0-Hardwareunterstützung.
Zusätzlich zu Canvas rendern Entwickler Grafik hauptsächlich auch durch Verwendung von OpenGL ES zum direkten Rendern zu einer Oberfläche. Android stellt OpenGL-ES-Schnittstellen in dem Paket android.OpenGL bereit, das Entwickler benutzen können, um in ihre GL-Implementierungen mit dem SDK (Software Development Kit) oder mit nativen APIs, die in Android NDK (Android Native Development Kit) bereitgestellt werden, aufrufen zu können.
11 zeigt grafisch Konzepte in Bezug auf Oberflächen und die Zusammenstellung der Oberflächen durch SurfaceFlinger 1022 und den Hardware-Zusammensteller 1026 zur Erzeugung des grafischen Inhalts, der auf einem Android-Gerät angezeigt wird. Wie bereits erwähnt werden Anwendungsentwicklern zwei Mittel zur Erzeugung von grafischem Inhalt bereitgestellt: Canvas und OpenGL. Sie verwenden jeweils eine API, die eine Menge von Grafikbefehlen zur Erzeugung von grafischem Inhalt umfasst. Dieser grafische Inhalt wird auf eine Oberfläche „gerendert“, die eine in Grafikspeicher 1100 gespeicherte Bitmap umfasst.
11 zeigt grafischen Inhalt, der durch zwei Anwendungen 1102 und 1104 erzeugt wird. Die Anwendung 1102 ist eine Fotoansichtsanwendung und verwendet einen Canvas-Grafikstapel 1106. Dazu gehören eine Canvas-API 1108, SGL 1110, die Skia-2D-Grafiksoftwarebibliothek und die Android-Oberflächenklasse 1112. Die Canvas-API 1106 ermöglicht Benutzern, über Canvas-Zeichnungsbefehle Grafikinhalt auf (als Oberflächen bezeichnete) virtuelle Ansichten zu „zeichnen“, die als Bitmaps in Grafikspeicher 1100 gespeichert werden. Skia unterstützt das Rendern von 2D-Vektorgrafik und Bildinhalt wie GIFs, JPEGs und PNGs. Skia unterstützt außerdem das FreeType-Textrendering-Subsystem von Android sowie verschiedene Grafikerweiterungen und -effekte wie Anti-Alias, Transparenz, Filter, Schattierungen usw. Die Oberflächenklasse 1110 umfasst verschiedene Softwarekomponenten zur Ermöglichung von Interaktion mit Android-Oberflächen. Die Anwendung 1102 rendert Grafikinhalt auf eine Oberfläche 1114.
Die Anwendung 1104 ist eine Spielanwendung, die Canvas für ihre Benutzeroberfläche und OpenGL für ihren Spielinhalt verwendet. Sie verwendet eine Instanz des Canvas-Grafikstapels 1106 zum Rendern von Benutzeroberflächen-Grafikinhalt auf eine Oberfläche 1116. Die OpenGL-Zeichnungsbefehle werden durch einen OpenGL-Grafikstapel 1118 verarbeitet, der eine OpenGL-ES-API 1120, eine eingebettete Systemgrafikbibliothek (EGL) 1122, eine Hardware-OpenGL-ES-Grafikbibliothek (HGL) 1124, eine Android-Software-OpenGL-ES-Grafikbibliothek (AGL) 1126, eine Grafikverarbeitungseinheit (GPU) 1128, einen PixelFlinger 1130 und die Oberflächen-Klasse 1110 umfasst. Der OpenGL-Zeichnungsinhalt wird auf eine Oberfläche 1132 gerendert.
Der Inhalt der Oberflächen 1114, 1116 und 1132 wird unter Verwendung von SurfaceFlinger 1022 und des Hardware-Zusammenstellers 1026 selektiv kombiniert. In diesem Beispiel hat die Anwendung 1104 den aktuellen Fokus, und somit werden den Oberflächen 1116 und 1132 entsprechende Bitmaps in einen Anzeigepuffer 1134 kopiert.
Die Rolle von SurfaceFlinger ist das Annehmen von Puffern von Daten von mehreren Quellen, Zusammenstellen dieser und Senden dieser zur Anzeige. Unter früheren Versionen von Android geschah dies mit Software-Blitting in einen Hardware-Einzelbildpuffer (z. B. /dev/graphics/fb0), dies wird jedoch nicht mehr so gemacht.
Wenn eine Anwendung in den Vordergrund kommt, bittet der Fenstermanager-Dienst SurfaceFlinger um eine Zeichnungsoberfläche. SurfaceFlinger erzeugt eine „Schicht“ - deren primäre Komponente eine Pufferwarteschlange ist - für die SurfaceFlinger als der Konsument wirkt. Ein Binder-Objekt für die Produzentenseite wird durch den Fenstermanager zur App geleitet, die dann damit beginnen kann, Einzelbilder direkt zu SurfaceFlinger zu senden.
Für die meisten Anwendungen befinden sich zu jedem gegebenen Zeitpunkt drei Schichten auf dem Bildschirm: der „Statusbalken“ oben im Bildschirm, der „Navigationsbalken“ unten oder auf der Seite und die Benutzeroberfläche und/oder der Anzeigeinhalt der Anwendung. Bestimmte Anwendungen werden mehr oder weniger aufweisen, z. B. hat die Vorgabe-Startanwendung eine getrennte Schicht für das Hintergrundbild, während ein Vollbildschirmspiel den Statusbalken verbergen könnte. Jede Schicht kann unabhängig aktualisiert werden. Der Status- und Navigationsbalken werden durch einen Systemprozess gerendert, während die Anwendungsschichten durch die Anwendung gerendert werden, ohne Koordination zwischen den beiden.
Geräteanzeigen werden mit einer bestimmten Rate aufgefrischt, typischerweise 60 Einzelbilder pro Sekunde (fps) auf Smartphones und Tablets. Wenn die Anzeigeinhalte in der Mitte des Auffrischens aktualisiert werden, wird „reißen“ sichtbar; es ist also wichtig, die Inhalte nur zwischen Zyklen zu aktualisieren. Das System empfängt ein Signal von der Anzeige, wenn die Inhalte ohne Risiko aktualisiert werden können. Dies wird als das VSYNC-Signal bezeichnet.
Die Auffrischrate kann mit der Zeit variieren, z. B. reichen einige mobile Geräte von 58 bis 62 fps, abhängig von den aktuellen Bedingungen. Bei einem per HDMI angeschlossenen Fernseher könnte dies theoretisch auf 24 oder 48 Hz abfallen, um mit einem Video übereinzustimmen. Da der Bildschirm nur einmal pro Auffrischzyklus aktualisiert werden kann, wäre das Abgeben von Puffern zur Anzeige mit 200 fps eine verschwendete Mühe, da der größte Teil der Einzelbilder niemals gesehen würde. Statt immer dann etwas zu unternehmen, wenn eine App einen Puffer abgibt, wacht SurfaceFlinger auf, wenn die Anzeige für etwas Neues bereit ist.
Wenn das VSYNC-Signal ankommt, durchläuft SurfaceFlinger seine Liste von Schichten, um nach neuen Puffern zu suchen. Wenn es einen neuen findet, beschafft es ihn; wenn nicht, verwendet es weiter den zuvor beschafften Puffer. SurfaceFlinger möchte immer etwas anzuzeigen haben, es lässt also einen Puffer nicht los. Wenn niemals Puffer auf einer Schicht abgegeben wurden, wird die Schicht ignoriert.
Nachdem SurfaceFlinger alle Puffer für sichtbare Schichten gesammelt hat, fragt es den Hardware-Zusammensteller, wie die Zusammenstellung durchgeführt werden soll. Der Hardware-Zusammensteller 1026 wurde zuerst in Android 3.0 eingeführt und hat sich mit den Jahren stetig weiterentwickelt. Sein Hauptzweck ist das Bestimmen der effizientesten Weise, Puffer mit der verfügbaren Hardware zusammenzustellen. Als HAL-Komponente ist seine Implementierung gerätespezifisch und wird gewöhnlich durch den Anzeiger Hardware-OEM implementiert.
Der Wert dieses Ansatzes ist leicht zu erkennen, wenn man „Überlagerungsebenen“ betrachtet. Der Zweck von Überlagerungsebenen ist das Zusammenstellen mehrerer Puffer miteinander, aber in der Anzeigehardware, statt in der GPU. Man nehme zum Beispiel an, dass man über ein typisches Android-Telefon in Hochformatorientierung verfügt, wobei sich der Statusbalken oben und der Navigationsbalken unten befindet und App-Inhalt überall sonst. Die Inhalte für jede Schicht befinden sich in getrennten Puffern (d. h. auf getrennten Oberflächen). Man könnte die Zusammenstellung handhaben durch Rendern des App-Inhalts in einen Scratch-Puffer, dann Rendern des Statusbalkens darüber, dann Rendern des Navigationsbalkens darüber und schließlich Leiten des Scratch-Puffers zur Anzeigehardware. Oder man könnte alle drei Puffer zur Anzeigehardware leiten und ihr befehlen, für verschiedene Teile des Bildschirms Daten von verschiedenen Puffern zu lesen. Der letztere Ansatz kann signifikant effizienter sein.
Wie zu erwarten wäre, sind die Fähigkeiten verschiedener Anzeigeprozessoren sehr unterschiedlich. Die Anzahl der Überlagerungen, ob Schichten gedreht oder gemischt werden können, und Beschränkungen bezüglich Positionierung und Überlappung können mittels einer API schwierig auszudrücken sein. Somit arbeitet der Hardware-Zusammensteller 1026 folgendermaßen.
Als Erstes stellt SurfaceFlinger 1022 dem Hardware-Zusammensteller 1026 eine volle Liste von Schichten bereit und fragt „Wie möchtest Du damit umgehen?“. Der Hardware-Zusammensteller 1026 antwortet, indem er jede Schicht als „Überlagerung“ oder „OpenGL-ES- bzw. GLES-Zusammenstellung“ markiert. SurfaceFlinger 1022 übernimmt jegliche GLES-Zusammenstellung, leitet den Ausgangspuffer zu dem Hardware-Zusammensteller 1026 und überlässt den Rest dem Hardware-Zusammensteller 1026.
Eine beispielhafte Android-Grafik-Werfer-Fänger-Architektur ist in 8a mit einem hybriden Android-Werfergerät 800a gezeigt, das Android-Grafikbefehle und -inhalte über eine Verbindung 804 zu einem Android-Fängergerät 802a wirft. Verschiedene Aspekte der Android-Grafik-Werfer-Fänger-Architektur von 8a sind den in der oben besprochenen 8 gezeigten ähnlich, darunter verschiedene Komponenten, die sich in beiden 8 und 8a dieselben Bezugszahlen teilen. Dementsprechend konzentriert sich das Folgende auf Implementierungsdetails, die der Implementierung eines Android-Grafik-Werfers und -Fängers eigen sind.
Wie oben besprochen verwenden Android-Anwendungen 910 Canvas-Zeichnungsbefehle und OpenGL-Zeichnungsbefehle zur Erzeugung von Grafikinhalt, der durch eine Android-Anwendung angezeigt wird. Die Canvas- und OpenGL-Befehle werden mittels Android-Grafik-APIs 816 implementiert, die anfänglich den Befehl für OpenGL-Befehle auf den Hardware-Rendering-Pfad und für Canvas-Befehle auf den Software-Rendering-Pfad aufteilen. Ausgewählte Canvas-Befehle werden über einen Skia-zu-OpenGL-Block 818 von Skia- in OpenGL-äquivalente Befehle umgesetzt, und diese OpenGL-Befehle werden über den Hardware-Rendering-Pfad weitergeleitet.
Die Android-Grafik-Rendering-Subsysteme 806a und 706Ra umfassen einen Software-Rendering-Block 712a, der eine Skia-Laufzeitbibliothek 944 zum Rendern von Skia-Befehlen als zugeordneten Inhalt (z. B. Bildinhalt) über den Software-Rendering-Pfad verwendet. Weitere Komponenten umfassen Bitmap-Puffer 716a, SurfaceFlinger 1022, eine GPU 714 und einen Hardware-Zusammensteller 1026.
8a zeigt ferner einen Android-Grafik-Werfer 808a und einen Android-Grafik-Fänger 810a. Diese Komponenten sind dem nativen Grafik-Werfer 808 und nativen Grafik-Fänger 810 ähnlich, mit der Ausnahme, dass sie dafür ausgelegt sind, Android-Grafikbefehle und zugeordneten Inhalt, darunter OpenGL-Befehle, und Canvas- und/oder Skia-Befehle und zugeordneten Inhalt zu werfen.
12a zeigt eine Android-Werfer-Fänger-Architektur, die OpenGL- und Android-Skia-Grafikinhalt parallel über mehrere Sockets wirft. Auf der Werferseite umfassen die Komponenten einen Wurf-Manager 1200, einen lokalen Grafiktreiber 1202, einen Betriebsystemkern 1204 und eine Anwendung 1206. Auf der Fängerseite umfassen die Komponenten ein entferntes Gerät / einen entfernten Bildschirm 1208 mit einer nativen Anwendung 1210 und SurfaceFlinger 1022. Das entfernte Gerät / der entfernte Bildschirm 1208 repräsentiert im Allgemeinen eine beliebige Art von Gerät, die als Fänger konfiguriert werden kann.
Um Grafik zu werfen, muss zuerst eine Verbindung zwischen dem Werfer und Fänger initialisiert werden, wie durch den Verbindungskommunikations-Initialisierungsaustausch 1212 abgebildet, der durch einen zweiseitigen Pfeil abgebildet ist, um anzugeben, dass ein Austausch von Kommunikation zwischen dem Werfer und Fänger besteht. Die konkreten Verbindungsinitialisierungsoperationen werden im Allgemeinen eine Funktion der konkreten physischen Verbindung und des verwendeten Protokolls sein, wobei solche Operationen Fachleuten auf dem Gebiet der Kommunikationstechnik wohlbekannt sind und außerhalb des Umfangs der vorliegenden Patentschrift liegen.
Sobald die Verbindung initialisiert wurde, sendet der lokale Grafiktreiber 1202 eine Nachricht 1214 zu dem entfernten Gerät/Bildschirm 1208, die nach seinen Grafikparametern und Fähigkeiten fragt. Dabei handelt es sich zum Beispiel, aber ohne Beschränkung darauf, um Bildschirmgröße, Auflösung, Datenformate des entfernten Geräts/Bildschirms 1208, welche Arten von Grafik es bzw. er unterstützt, wie etwa OpenGL und DirectX, und potentiell andere Informationen in Bezug auf Grafikparameter und Fähigkeiten des entfernten Geräts/Bildschirms 1208, die über eine Nachricht 1216 zurückgegeben werden.
Bei Empfang der Nachricht 1216 wertet als Entscheidungsblock 1218 in dem lokalen Grafiktreiber 1202 abgebildete Logik die Daten aus und bestimmt, ob sie in Ordnung sind oder ob sie repariert werden müssen. Wenn die Daten als in Ordnung betrachtet werden, werden sie zu dem OS-Kern 1204 weitergeleitet. Andernfalls werden sie in einem Datenreparaturblock 1220 repariert, bevor sie zu dem OS-Kern 1204 weitergeleitet werden.
An diesem Punkt sind mehrere Sockets geöffnet, wie durch einen Nachrichtenaustausch 1222 abgebildet. Mit den mehreren Sockets werden dann parallel mehrere OpenGL-Befehle und native Android-Rastergrafikbefehle transportiert.
Die Anwendung 1206 gibt wie abgebildet mehrere native Android-Grafikbefehle 1222 und 1223 an den lokalen Grafiktreiber 1202 aus. Zu den nativen Android-Grafikbefehlen 1222 können OpenGL-Befehle und Anwendungs-Grafikbefehle, die durch den lokalen Grafiktreiber 1202 in OpenGL-Befehle umgesetzt werden, und native Grafikbefehle 1223 auf Rasterbasis gehören, die nicht in OpenGL-Befehle umgesetzt werden können und als Rastergrafikbefehle 1226 gesendet werden, um durch das entfernte Gerät/den entfernten Bildschirm 1208 unter Verwendung eines Software-Rendering-Pfads gerendert zu werden.
Bei Echtzeit-Grafik-Rendering-Unterstützung werden das Senden und Verarbeiten der OpenGL-Befehle 1224 und Rastergrafikbefehle 1226 unter Verwendung eines Sequenzierungsschemas in Kombination mit Statusinformationen orchestriert. Bei einer Ausführungsform umfasst jeder OpenGL-Befehl 1224, der über eine Nachricht 1228 gesendet wird, um durch die native Anwendung 1210 empfangen zu werden, eine Sequenznummer. Wie ferner durch Blöcke in der nativen Anwendung 1210 dargestellt, umfassen ablaufende Operationen, die durch die native Anwendung ausgeführt werden, das Empfangen von OpenGL-Befehlen in einem Block 1230, Gruppieren von Sequenzen von OpenGL-Befehlen in einem Block 1232 und Abgeben der gruppierten Sequenzen von OpenGL-Befehlen an die GPU in einem Block 1234.
Native Rastergrafikbefehle 1226 werden parallel mit den OpenGL-Befehlen gesendet. Abhängig davon, ob mehrere Sockets zum Transport nativer Rastergrafikbefehle verwendet werden, können diese sequenziert werden oder nicht. Bei Empfang durch die native Anwendung 1210 werden die nativen Rastergrafikbefehle 1226 auf ähnliche Weise abgewickelt, wie sie unter Verwendung eines auf Software basierenden Rendering-Pfads auf einem Android-Hostgerät gerendert werden. Es gibt jedoch einige zusätzliche Gesichtspunkte.
Unter einem herkömmlichen Ansatz greift der Android-Grafiksoftware-Rendering-Pfad auf Rastergrafikobjekte in lokalem Speicher zu, was unter den heutigen Hardwarefähigkeiten im Wesentlichen augenblicklich ist. Der Inhalt dieser selben Rastergrafikobjekte wird jedoch über die Verbindung vom Werfer zum Fänger gesendet, was einige endliche Latenz (wenn auch klein) erfordert. Für OpenGL-Befehle, die keine Texturdaten enthalten (oder relativ kleine Texturen enthalten) ist dagegen die sich aus dem Senden der OpenGL-Befehle über die Verbindung ergebende Latenz im Wesentlichen nicht wahrnehmbar, und kombiniert mit auf Hardware basierender Rendering-Unterstützung für OpenGL (z. B. durch eine GPU) ist die Echtzeit-Fern-Grafik-Rendering-Leistungsfähigkeit unter der Android-Werfer-Fänger-Architektur sehr gut und ist im Wesentlichen schneller als Verwendung eines Screencasting-Ansatzes wie Miracast.
Um das Timing der Anzeige von gerendertem Inhalt auf dem Fänger zu orchestrieren, verarbeitet SurfaceFlinger 1022 in Kombination mit dem (nicht gezeigten) Hardware-Zusammensteller, wie oben beschrieben, OpenGL-Befehlsstatusinformationen, die VSYNC-Timinginformationen umfassen, und Einzelbildpuffer werden umgewechselt, nachdem Ereignisse abgeschlossen sind, wie durch einen Block 1236 abgebildet. Zum Beispiel wird gewünscht, dass jeder neue Einzelbildpuffer eine vollständige Menge von Grafikinhalt enthält, wie etwa Vollbildinhalt und korrekt geordnete Sequenzen von OpenGL-Befehlsinhalt, der durch die GPU gerendert wurde. Wenn der Grafikinhalt eines Einzelbildpuffers unvollständig ist, wird er nicht zur Verwendung als der Anzeigepuffer umgewechselt, was dazu führt, dass der existierende Anzeigepufferinhalt unter Verwendung der Anzeigeauffrischrate von dem entfernten Gerät/Bildschirm 1208 mehrmals angezeigt wird.
12b zeigt eine zu der Ausführungsform von 12a alternative Implementierung. Unter dieser Ausführungsform wird ein einziges Socket zum Transport der OpenGL-Befehlssequenz über die Verbindung verwendet. Die nativen Rastergrafikbefehle und/oder OpenGL-Befehlsstatusinformationen können über das selbe Socket wie die OpenGL-Befehlssequenz oder getrennte Sockets transportiert werden.
Windows-Grafikarchitektur
Zusätzlich zu dem Werfen von Android-Grafikinhalt können Werfer-Fänger-Fernanzeigeschemata implementiert werden, die nativen Microsoft-Windows-Grafikinhalt werfen. Microsoft Windows stellt mehrere C++/COM-APIs für Grafik bereit, wie in 13 gezeigt. Auf der linken Seite der Darstellung befindet sich die Legacy-GDI (Graphics Device Interface) 1300, die ursprüngliche Grafikschnittstelle für Windows. GDI+ 1302 wurde in Windows XP als Nachfolger von GDI 1300 eingeführt. Auf die GDI+-Bibliothek wird mittels einer Menge von C++-Klassen zugegriffen, die flache C-Funktionen einwickeln, wie durch die GDI+-flat-API 1304 abgebildet. Der .NET-Rahmen stellt auch eine verwaltete Version von GDI+ in dem Namenraum System.Drawing bereit.
Die DirectX-APIs 1306 umfassen Direct2D 1308, DirectWrite 1310, Direct3D 1312, DXGI (Direct Graphics Infrastructure) 1314 und einen Software-Rasterer 1316. Direct2D 1308 ist eine API für 2D-Grafik und ist der Nachfolger sowohl von GDI als auch von GDI+. Direct3D 1312 wird für 3D-Grafik verwendet. DirectWrite 1310 ist eine Textlayout- und Rasterungsengine. Zum Zeichnen des gerasterten Text kann man entweder GDI 1300 oder Direkt2D 1308 verwenden. DXGI 1314 führt Aufgaben auf niedriger Ebene aus, wie etwa Präsentieren von Einzelbildern zur Ausgabe. Die meisten Anwendungen verwenden DXGI nicht direkt. Stattdessen dient es als eine Zwischenschicht zwischen dem Grafiktreiber und Direct3D. Die Windows-Grafikarchitektur umfasst außerdem eine Grafiktreiberschicht, die eine GDI-DDI (Display Device Interface) 1318 und eine DirectX (DX) DDI 1320 umfasst.
Obwohl GDI 1300 und GDI+ 1302 weiter in Windows unterstützt werden, werden für neue Programme Direct2D 1308 und DirectWrite 1310 empfohlen. In einigen Fällen könnte eine Mischung von Technologien praktikabler sein. Für diese Situationen sind Direct2D 1308 und DirectWrite 1310 dafür ausgelegt, mit GDI 1300 zusammenzuwirken.
Der moderne Grafikansatz ist das wirksame Einsetzen von durch die Grafikverarbeitungseinheit (GPU) statt die CPU ausgeführten Grafikberechnungen. Moderne GPUs sind stark für die Arten von beim Rendern von Grafik verwendete Berechnung optimiert. Im Allgemeinen ist es umso besser, je mehr dieser Arbeit von der CPU auf die GPU verlagert wird.
Während GDI 1300 Hardwarebeschleunigung für bestimmte Operationen unterstützt, sind viele GDI-Operationen an die CPU gebunden. Direct2D 1308 wird über Direct3D 1312 geschichtet und nutzt durch die GPU bereitgestellte Hardwarebeschleunigung voll aus. Wenn die GPU die für Direct2D 1308 benötigten Merkmale nicht unterstützt, fällt Direct2D 1308 auf Software-Rendering unter Verwendung des Software-Rasterers 1316 zurück. Insgesamt arbeitet Direct2D 1308 in den meisten Situationen besser als GDI 1300 und GDI+ 1302. Direct2D unterstützt auch Vektorgrafik, die mathematische Formeln verwendet, um Linienwerk zu repräsentieren. Diese Formeln sind nicht von der Bildschirmauflösung abhängig, so dass sie auf beliebige Dimensionen skaliert werden können. Vektorgrafik ist besonders nützlich, wenn ein Bild skaliert werden muss, um verschiedene Monitorgrößen oder Bildschirmauflösungen zu unterstützen.
14 zeigt die Architektur 1400 des Windows-Anzeigetreibermodells (WDDM). Die Architektur ist wie gezeigt zwischen Benutzermoduskomponenten und Kernmoduskomponenten aufgeteilt. Zu den Benutzermoduskomponenten gehören eine Anwendung 1402 (die tatsächlich nicht Teil der WDDM-Architektur ist sondern stattdessen Eingaben in die WDDM-Architektur bereitstellt), ein Direct3D-Laufzeitmodul 1404, ein Benutzermodus-Anzeigetreiber 1406, ein OpenGL-Laufzeitmodul 1408, ein Win32-GDI-Modul 1010, eine DLL (Dynamic Link Library) 1412 des Kernmoduszugriffs und ein OpenGL-installierbarer Client-Treiber (ICD) 1414. Zu den Kernmoduskomponenten gehören ein DirectX-Grafikkernsubsystem (Dxgkml.sys) 1416, ein Win32K.sys-Modul 1418 und ein Anzeige-Miniporttreiber 1420. Dxgkml.sys 1416 umfasst einen Anzeigeporttreiber, einen Videospeichermanager und einen GPU-Scheduler.
15 zeigt eine Ausführungsform einer Windows-Grafik-Fänger-Werfer-Architektur 1500, unter der ein Windows-Grafikwerfer 1502 native Windows-Grafikbefehle und -inhalte über eine Verbindung 1506 zu einem Windows-Grafikfänger 1504 wirft. Wie in dem oberen Teil von 15 gezeigt umfasst der Windows-Grafikwerfer 1502 die Benutzermodus-Grafikkomponenten der in 14 gezeigten Windows-Grafikarchitektur. In der Zwischenzeit umfasst unter dieser aufgeteilten Grafikarchitekturimplementierung der Windows-Fänger 1504 die Kernmodus-Grafikkomponenten von 14.
Um das Werfen von nativem Windows-Grafikinhalt zu ermöglichen, umfasst der Windows-Grafikwerfer 1502 einen nativen Windows-Grafikwerfer 1508, während der Windows-Grafikfänger 1504 einen nativen Windows-Grafikfänger 1510 umfasst. Bei der dargestellten Ausführungsform ist der native Windows-Grafikwerfer 1506 als ein virtueller Gerätetreiber implementiert, der dafür ausgelegt ist, vom Standpunkt der Benutzermoduskomponenten aus gesehen als ein herkömmlicher Windows-Grafikgerätetreiber wirkend zu scheinen, der GDI DDI 1318 und DX DDI 1320 von 13 umfasst. Es werden jedoch stattdessen ein ergänztes GDI DDI 1318a und DX DDI 1320a implementiert, die dafür ausgelegt sind, den Grafikinhalt, den sie empfangen, zur passenden ergänzten GDI DDI 1318b und DX DDI 1320b auf dem nativen Windows-Grafikfänger 1510 weiterzuleiten. GDI DDI 1318b und DX DDI 1320b sind virtuelle Gerätetreiber, die dafür ausgelegt sind, eine Schnittstelle mit den unten in 15 abgebildeten Kernmodus-Windows-Grafikkomponenten aufzuweisen. Bei der dargestellten Ausführungsform ist der native Windows-Grafikfänger 1510 als eine Windows-Anwendung implementiert, die entweder Softwaremodule zur Implementierung von virtueller GDI DDI 1318b und DX DDI 1320b umfasst oder Schnittstellen mit Softwaremodulen aufweist, die getrennt implementiert sind (wie etwa Dienste).
16 zeigt eine andere Ausführungsform einer nativen Grafik-Werfer-Fänger-Architektur, unter der das Windows-Werfergerät 1600 Android-Grafikbefehle und -Inhalte zu einem Android-Fängergerät 802a wirft. Unter einer Ausführungsform teilen sich das Android-Fängergerät 1802a in 8a und 16a dieselben Komponenten (angewandt auf Android-Grafikfangen und -rendern). Wie dargestellt sind die Benutzermodus-Komponenten für das Windows-Werfergerät 1600 die in 14 und 15 gezeigten herkömmlichen Windows-Benutzermodus-Grafikkomponenten wie oben besprochen. Ein Windows-zu-Android-Grafikumsetzer und -werfer 1602 dient zum Umsetzen von Windows-Grafikbefehlen und -inhalten in entsprechende Android-Grafikbefehle und -inhalte und dann zum Werfen der umgesetzten Android-Grafikbefehle und -inhalte. Der Windows-zu-Android-Grafikumsetzer und -werfer 1602 umfasst einen ergänzten nativen Windows-Grafikwerfer 1508a, der DX DDI 1320a und GDI DDI 1318a umfasst. Er umfasst außerdem einen Windows-zu-Android-Grafikumsetzer 1604 mit einem DirectX-zu-OpenGL-Umsetzer 1606 und einem GDI/GDI+-zu-Skia-Grafikumsetzer 1608.
Wie der Name sagt empfängt der DirectX-zu-OpenGL-Umsetzer 1606 DirectX-Befehle, die durch DX DDI 1320a geleitet werden, und setzt diese Befehle in entsprechende OpenGL-Befehle um. Für diesen Zweck können ein oder mehrere verschiedene existierender DirectX-zu-OpenGL-Umsetzer verwendet werden. Zum Beispiel kann bei einer Ausführungsform die Open-Source-Direct3D-zu-OpenGL-Übersetzungsschicht von Dota 2 der Valve Corporation verwendet werden. Der Code, namentlich „ToGL“, ist von GitHub verfügbar. Ein anderer Open-Source-DirectX-zu-OpenGL-Umsetzer ist von dem Grafikchiphersteller ATI Technologies verfügbar.
Der GDI /GDI+-zu-Skia-Grafikumsetzer empfängt GDI- und/oder GDI+-Grafikbefehle über GDI DDI 1318 und setzt diese in äquivalente Skia-Grafikbefehle um. Im Allgemeinen betreffen die GDI/GDI+Grafikbefehle tendenziell Rasterinhalt wie Bilder, obwohl es auch anderen Inhalt umfassen kann. Bildinhalt basiert typischerweise an einer DDI entweder als Zeiger auf Bitmapinhalt, der bereits in einem Bitmappuffer geschrieben ist, oder ein Zeiger auf den Bildinhalt in seiner gespeicherten Form, die typischerweise einen herkömmlichen Grafikstandard umfassen kann, wie etwa, aber ohne Beschränkung darauf, JPEG, PNG, GIF usw. Der Bildinhalt kann auch in einem proprietären komprimierten Format, wie etwa einer komprimierten Form auf Wavelet-Basis, gespeichert werden. Einige Anwendungen wie Google Chrome verwenden intern Skia zum Rendern von Inhalt. Wenn diese Anwendungen auf Windows-Plattformen (wie etwa Windows 7, Windows 8.1 usw.) eingesetzt werden, werden die Skia-Befehle in Windows-Zeichnungsbefehle umgesetzt, die GDI/GDI+-Zeichnungsbefehle umfassen können. Umsetzung in der anderen Richtung (z. B. von GDI/GDI+) beinhaltet im Allgemeinen den umgekehrten Prozess.
Der Windows-zu-Android-Grafikumsetzer und -werfer gibt OpenGL-Befehle und Skia-Grafikbefehle (je nach Fall) aus und wirft diese zu dem Android-Grafikfänger 810a auf dem Android-Fängergerät 802a. Der Android-Grafikfänger 810a leitet die OpenGL- und Skia-Grafikbefehle dann auf ähnliche Weise wie oben mit Bezug auf 8a besprochen zu dem Android-Grafik-Rendering-Subsystem 706Ra weiter.
17a und 17b zeigen alternative Ausführungsformen zum Aufbauen einer Verbindung und Werfen von nativen Android-Grafikbefehlen und -inhalten gemäß der Ausführungsform von 16. Wie durch gleichbezifferte Komponenten in 12a, 12b, 17a und 17b abgebildet, sind viele der Komponenten in 17a und 17b den oben mit Bezug auf 12a und 12b besprochenen ähnlich. Zusätzlich zu diesen Komponenten zeigt 17a einen Windows-zu-Android-Grafikumsetzer und -werfer 1602, der einen Windows-zu-Android-Grafikumsetzer 1604, einen OS-Kern 1700, eine Windows-Anwendung 1702 und Windows-Grafikbefehle 1704, darunter DirectX-Befehle 1706 und GDI/GDI+-Befehle 1708, umfasst.
Der Windows-zu-Android-Grafikumsetzer ist dafür ausgelegt, DirektX-Befehle 1706 in OpenGL-Befehle 1710 und GDI/GDI+-Befehle 1708 in native Android-Nativrastergrafikbefehle 1712 (z. B. Skia-Befehle) auf die oben mit Bezug auf 16 beschriebene Weise umzusetzen. Die OpenGL-Befehle 1710 und nativen Android-Rastergrafikbefehle werden dann auf ähnliche Weise wie oben für 12a und 12b beschrieben zu dem entfernten Gerät/Bildschirm 1208 gesendet, wobei die Ausführungsform von 17a mehrere Sockets zum Transport von OpenGL-Befehlen 1710 verwendet, während die Ausführungsform von 17b ein einziges Socket verwendet.
Als Alternative dazu, dass die Windows-zu-Android-Grafikbefehl- und -Inhaltsumsetzung auf dem Werfer geschieht, werden bei einer Ausführungsform diese Operationen durch den Fänger ausgeführt. Eine beispielhafte Implementierung dieses Ansatzes ist in 18 gezeigt, wobei ein Windows-Werfergerät 1800 DirectX- und GDI /GDI+-Grafikbefehle und -inhalte zu einem Android-Fängergerät 1802 wirft, das einen Windows-zu-Android-Grafikumsetzer und -fänger 1804 umfasst. Diese Komponente umfasst denselben Windows-zu-Android-Grafikumsetzer 1604 wie in 16 gezeigt, mit der Ausnahme, dass sich nun der Windows-zu-Android-Grafikumsetzer auf dem Fängergerät befindet, statt auf dem Werfergerät.
Anzeige und Interaktion von Windows-Anwendungen auf dem Android-Gerät
Wie oben mit Bezug auf 1 und 2 besprochen, ist das Android-Gerät 102 dafür ausgelegt, es einem Benutzer zu ermöglichen, Windows-Anwendungen 132 zu betrachten und mit diesen in Interaktion zu treten, während es auch fungiert, um herkömmliche Android-Anwendungen und -funktionalität zu unterstützen. Bei einer Ausführungsform wird dies mittels Verwendung von Windows-Remote-Desktop-Komponenten ermöglicht, darunter die GPU des Android-Remote-Desktop-Clients 146 und ein Remote-Desktop-Server 1900, der eine Komponente im Windows-OS 126 ist, wie in 19 gezeigt.
Windows-Remote-Desktop verwendet ein Server-Client-Modell, unter dem der Server Windows-Anzeigeinhalt auf einem „entfernten“ Computer, in dem der Server implementiert ist, erfasst und diesen entfernten Anzeigeinhalt zu einer Remote-Desktop-Client-Anwendung sendet, die auf einem „lokalen“ Hostcomputer läuft, der den entfernten Anzeigeinhalt rendert. Um es einem Benutzer zu ermöglichen, mit dem entfernten Computer in Interaktion zu treten, detektiert der Remote-Desktop-Client über die Remote-Desktop-Client-Anwendung auf dem lokalen Computer getätigte Benutzereingaben, setzt diese in entsprechende Eingabegerätebefehle/-ereignisse um und sendet diese zu dem Remote-Desktop-Server auf dem entfernten Computer. Der Remote-Desktop-Server stellt die Eingaben dann dem Windows-OS 126 so bereit, als wären die Eingaben durch ein oder mehrere mit dem entfernten Computer gekoppelte Eingabegeräte getätigt worden. Somit wird einem Benutzer ermöglicht, Windows-Anwendungen zu betrachten und mit diesen in Interaktion zu treten, die auf einem entfernten Computer laufen.
Ein ähnliches Paradigma wird in der Ausführungsform von 19 implementiert. In diesem Fall ist der entfernte Computer jedoch die Datenverarbeitungskarte 100, die physisch mit dem Android-Hostgerät 102 kolokalisiert ist. Da die Datenverarbeitungskarte 100 keine physische Anzeige aufweist, wird zusätzlich stattdessen eine virtuelle Anzeige verwendet, die einen virtuellen Anzeigepuffer 134 umfasst.
Unter der herkömmlichen Windows-Remote-Desktop-Implementierung (sowie sie derzeit implementiert ist) umfasst durch den entfernten Server-Hostcomputer erzeugter Anzeigeinhalt Einzelbilder von Anzeigeinhalt, die dynamisch erfasst, unter Verwendung eines Videocodecs zur Erzeugung eines Bitstroms, der in eine Sequenz von Paketen eingekapselt wird, komprimiert und zu der Remote-Desktop-Client-Anwendung gesendet werden. Bei Empfang durch den Host des RD-Clients wird der codierte Bitstrom ent-eingekapselt und decodiert, um die ursprünglichen Einzelbilder zu extrahieren, die dann mittels Verwendung des Hosts des RD-Clients durch die RD-Client-Anwendung gerendert werden.
Bei einer Ausführungsform umfasst der RD-Client 146 einen Android-RD-Client, der von Microsoft entwickelt wurde, um es Benutzern von Android-Geräten zu ermöglichen, auf entfernte Windows-Computer zuzugreifen. Dementsprechend werden bei dieser Ausführungsform der Android-RD-Client 146 und der Remote-Desktop-Server 1900 auf die herkömmliche Weise implementiert.
Der Prozess beginnt mit dem Aufbauen einer RDP-Verbindung (Remote Desktop Protokoll) 1902. RDP ist ein wohlbekanntes Protokoll, das öffentlich verfügbar und durch Microsoft sowie andere Softwarefirmen implementiert ist. Zum Beispiel gibt es eine Anzahl von RD-Clients, die mit einem Microsoft-RD-Server in Interaktion treten, die entwickelt wurden, darunter RD-Clients, die auf Android laufen. Wenn RD-Server und -Clients verwendet werden, die beide von Microsoft entwickelt wurden, sind Einrichtungen zum Aufbauen einer RDP-Verbindung bereits implementiert.
Sobald die RDP-Verbindung 1902 hergestellt ist, kann der Remote-Desktop-Server 1900 damit beginnen, Einzelbilder von Anzeigeinhalt als einen Stream von Grafikpaketen 1904 zu dem Android-RD-Client 146 zu senden. Die ursprünglichen Einzelbilder werden durch den Android-RD-Client 146 regeneriert, der Android-Grafikbefehle an das Android-Grafik-Rendering-Subsystem 706a ausgibt, das dann die Einzelbilder rendert, um somit das Aussehen der Windows-Schnittstelle auf dem entfernten Computer/Gerät zu replizieren. Wie oben angegeben wird bei der in 19 gezeigten Implementierung (und anderen hier vorliegenden) die Windows-Schnittstelle und Anwendungsanzeigeinhalt dem virtuellen Anzeigepuffer 134 „angezeigt“, und die Einzelbilder des Anzeigeinhalts werden aus diesem Anzeigepuffer erfasst.
Um Benutzerinteraktion mit dem Host der RD-Server 1900 (Datenverarbeitungskarte 100) zu ermöglichen, erfasst der Android-RD-Client 146 Benutzereingaben in seiner Anwendung und setzt die Benutzereingaben in entsprechende Windows-Eingabegerätebefehle und -ereignisse um. Diese Befehle und Ereignisse werden dann über die RDP-Verbindung 1902 wie durch eine Sequenz von UI-Paketen 1908 abgebildet, zu dem RD-Server 1900 gesendet. Nach dem Empfang gibt der RD-Server 1900 die UI-Befehle/-ereignisse an das Windows-OS 126 ab, das entsprechende Aktionen unternimmt.
20 zeigt eine beispielhafte Bildschirmanzeige eines Windows-Betriebssystems und eine Anwendung, die auf einer Datenverarbeitungskarte 100 läuft, die über ihren Micro-USB-Verbinder mit der Prozessorplatine eines Android-Smartphones gekoppelt ist. Wie oben besprochen wird dies mittels Verwendung des Android-RD-Clients 146 ermöglicht, und die Anzeige in 20 ist die auf dem Android-Smartphone laufende Anwendung des Android-RD-Clients 146. In diesem konkreten Beispiel ist die Windows-Anwendung Microsoft Office Outlook, aber es kann im Wesentlichen jede beliebige Windows-Anwendung, die auf der Datenverarbeitungskarte 100 laufen kann, auf ähnliche Weise angezeigt werden und es kann auf ähnliche Weise mit ihr in Interaktion getreten werden.
Gemäß weiteren Aspekten einiger Ausführungsformen wird eine vereinigte Schnittstelle bereitgestellt, die gleichzeitig Zugang sowohl zu Android- als auch Windows-Anwendungen ermöglicht. Beispiele für die vereinigte Schnittstelle sind in 21a und 21b gezeigt. Die vereinigte Schnittstelle umfasst wie dargestellt ein Panel 2100 von Android-Anwendungen und ein Panel 2102 von Windows-Anwendungen. Zusätzlich enthält ein drittes Panel 2104 Symbole zum Zugreifen auf Aggregationen von Dateien über beide Betriebssysteme hinweg, darunter alle Dateien, alle Kontakte und alle Email.
Obwohl Windows-Remote-Desktop viele Jahre lang erfolgreich verwendet wurde, lässt seine Leistungsfähigkeit für einige Klassen von Anwendungen, insbesondere diejenigen mit viel Bewegung, etwas zu wünschen übrig. Der Grund dafür ist zweifach. Wie oben besprochen verwendet Windows-Remote-Desktop einen Bildschirm-Casting-Ansatz, bei dem Einzelbilder von Anzeigeinhalt erfasst, in ein Video-Stream-Format umgesetzt, über eine Verbindung gesendet und durch den Remote-Desktop-Client verarbeitet werden, um die Einzelbilder zu regenerieren. Der Inhalt, der transferiert wird, ist somit im Wesentlichen gerasterter Inhalt, der komprimiert wurde, was verglichen mit nativen Grafikbefehlen relativ ineffizient ist.
Der zweite Gesichtspunkt betrifft, wie die Einzelbilder erzeugt werden.
Wenn die Windows-Anwendung kein Video ist, verwendet Remote Desktop einen Differenz- oder „diff“-Ansätz. Unter dieser Technik wird periodisch Inhalt erzeugt, der die Differenz zwischen Einzelbildern umfasst. Dies führt bei einer Anwendung mit relativ viel Bewegung von mehr zu einer sehr merklichen Verzögerung. Im Wesentlichen können Teile von Einzelbildern in einer gegebenen diff erzeugt werden und Rasterinhalt für ein gesamtes Einzelbild kann periodisch übertragen werden. Unter diesem Ansatz versucht Microsoft nicht, auf die Auffrischrate des empfangenden Geräts oder auch nur dieser nahezukommen, und die Menge an transferierten Daten wäre selbst bei Komprimierung überwältigend.
Als Vergleich betrachte man, wie Video-Streaming arbeitet. Auf einem grundlegenden Niveau wird Streaming-Video-Inhalt auf einer Anzeige als eine Sequenz von „Einzelbildern“ oder „Bildern“ wiedergegeben. Jedes Einzelbild umfasst, wenn es gerendert wird, ein Array von Pixeln mit Abmessungen entsprechend einer Wiedergabeauflösung. Zum Beispiel hat volles HD-Video (hohe Auflösung) eine Auflösung von 1920 horizontalen Pixeln mal 1080 vertikalen Pixeln, was gewöhnlich als 1080p (progressiv) bekannt ist. Die Einzelbilder werden der Reihe nach mit einer Einzelbildrate angezeigt, unter der die Daten des Einzelbilds mit der Einzelbildrate aufgefrischt (oder je nach Fall neu gerendert) werden. Es wird angemerkt, dass viele der heutigen Smartphones und Tablets eine Bildschirmpixelauflösung von 1920x1080 oder sogar mehr aufweisen.
Bei einer Auflösung von 1080p umfasst jedes Einzelbild ungefähr 2,1 Millionen Pixel. Verwendung lediglich einer 8-Bit-Pixelcodierung würde eine Daten-Streaming-Rate von nahezu 17 Millionen Bit pro Sekunde (mbps) erfordern, um eine Einzelbildrate von nur 1 Einzelbild pro Sekunde zu unterstützen, wenn der Videoinhalt als Rohpixeldaten abgeliefert würde. Da dies impraktikabel wäre, wird Videoinhalt in einem stark komprimierten Format codiert.
Standbilder, sowie sie etwa unter Verwendung eines Internet-Browsers betrachtet werden, werden typischerweise unter Verwendung von JPEG-Codierung (Joint Photographic Expert Groups) oder PNG-Codierung (Portable Network Graphics) codiert. Der ursprüngliche JPEG-Standard definiert ein „verlustbehaftetes“ Komprimierungsschema, unter dem sich die Pixel in dem decodierten Bild vom Originalbild unterscheiden können. Im Gegensatz dazu verwendet PNG ein „verlustloses“ Komprimierungsschema. Da verlustloses Video auf vielen Ebenen impraktikabel wäre, verwenden die verschiedenen Videokomprimierungs-Standardinstitute wie MPEG (Motion Photographic Expert Group), die den ersten MPEG-1-Komprimierungsstandard (1993) definiert haben, verlustbehaftete Komprimierungstechniken, einschließlich Standbildcodierung von Intra-Einzelbildern („I-Frames“) (auch als „Schlüssel-Einzelbilder bekannt) in Kombination mit Bewegungsprädiktionstechniken, die verwendet werden, um andere Arten von Einzelbildern zu erzeugen, wie etwa Prädiktions-Einzelbilder („P-Frames“) und bidirektionale Einzelbilder („B-Frames“). Ähnlich verwendet H.264 auch I-Frames, P-Frames und B-Frames, wobei angemerkt wird, dass es Unterschiede zwischen MPEG und H.264 gibt, zum Beispiel dahingehend, wie der Einzelbildinhalt erzeugt wird.
Während sich Video- und Standbild-Komprimierungsalgorithmen viele Komprimierungstechniken teilen, besteht ein Schlüsselunterschied darin, wie mit Bewegung umgegangen wird. Ein extremer Ansatz wäre das Codieren jedes Einzelbildes unter Verwendung von JPEG oder eines ähnlichen Standbild-Komprimierungsalgorithmus mit anschließendem Decodieren der JPEG-Einzelbilder zur Erzeugung von Einzelbildern in der Wiedergabevorrichtung. JPEGs und ähnliche Standbild-Komprimierungsalgorithmen können bei Komprimierungsverhältnissen von etwa 10:1 qualitativ hochwertige Bilder produzieren, während fortschrittliche Komprimierungsalgorithmen ähnliche Qualität bei Komprimierungsverhältnissen von sogar 30:1 produzieren können. Während 10:1 und 30:1 beträchtliche Komprimierungsverhältnisse sind, können Videokomprimierungsalgorithmen bei Komprimierungsverhältnissen von bis zu ungefähr 200:1 Video mit relativ guter Qualität bereitstellen. Dies wird erreicht durch Verwendung von videospezifischen Komprimierungstechniken wie Bewegungsschätzung und Bewegungskompensation in Kombination mit Standbild-Komprimierungstechniken.
Für jeden Makroblock in einem aktuellen Einzelbild (typischerweise einem 8×8- oder 16×16-Pixel) versucht Bewegungsschätzung eine Region in einem zuvor codierten Einzelbild (das als Referenzeinzelbild bezeichnet wird) zu finden, das eine gute Übereinstimmung ist. Das räumliche Offset zwischen dem aktuellen Block und dem ausgewählten Block aus dem Referenzeinzelbild wird als „Bewegungsvektor“ bezeichnet. Der Codierer berechnet die pixelweise Differenz zwischen dem ausgewählten Block aus dem Referenzeinzelbild und dem aktuellen Block und überträgt diesen „Prädiktionsfehler“ zusammen mit dem Bewegungsvektor. Die meisten Videokomprimierungsstandards erlauben auf Bewegung basierende Prädiktion zu umgehen, wenn der Codierer keine gute Übereinstimmung für den Makroblock findet. In diesem Fall wird anstelle des Prädiktionsfehlers der Makroblock selbst codiert.
Es wird angemerkt, dass das Referenzeinzelbild nicht immer das unmittelbar vorhergehende Einzelbild in der Sequenz angezeigter Videoeinzelbilder ist. Stattdessen codieren Videokomprimierungsalgorithmen gewöhnlich Einzelbilder in einer anderen Reihenfolge als der Reihenfolge, in der sie angezeigt werden. Der Codierer kann mehrere Einzelbilder nach vorne springen und ein zukünftiges Videoeinzelbild codieren und dann zurückspringen und das nächste Einzelbild in der Anzeigesequenz codieren. Dies geschieht, damit Bewegungsschätzung zeitlich rückwärts durchgeführt werden kann, wobei das codierte zukünftige Einzelbild als Referenzeinzelbild verwendet wird. Videokomprimierungsalgorithmen erlauben gewöhnlich auch die Verwendung von zwei Referenzeinzelbildern - eines zuvor angezeigten Einzelbildes und eines zuvor codierten zukünftigen Einzelbildes.
Videokomprimierungsalgorithmen codieren periodisch Intra-Einzelbilder unter Verwendung nur von Standbild-Codierungstechniken, ohne sich auf zuvor codierte Einzelbilder zu verlassen. Wenn ein Einzelbild in dem komprimierten Bitstrom (z. B. aufgrund fallengelassener Pakete oder anderer Transportfehler) durch Fehler verfälscht ist, kann der Videodecodierer am nächsten I-Frame „neu starten“, was kein Referenzeinzelbild zur Rekonstruktion erfordert.
22 zeigt ein beispielhaftes Einzelbildcodierungs- und - anzeigeschema, das aus I-Frames 2200, P-Frames 2202 und B-Frames 2204 besteht. Wie oben besprochen werden I-Frames periodisch auf ähnliche Weise wie Standbilder codiert und sind nicht von anderen Einzelbildern abhängig. P-Frames (vorhergesagte Einzelbilder) werden nur unter Verwendung eines zuvor angezeigten Referenzeinzelbildes codiert, wie durch ein vorheriges Einzelbild 2206 abgebildet. In der Zwischenzeit werden B-Frames (bidirektionale Einzelbilder) unter Verwendung sowohl von zukünftigen als auch zuvor angezeigten Referenzeinzelbildern codiert, wie durch ein vorheriges Einzelbild 2208 und ein zukünftiges Einzelbild 2210 abgebildet.
Der untere Teil von 22 zeigt eine (nach unten voranschreitende) beispielhafte Einzelbildcodierungssequenz und eine (von links nach rechts voranschreitende) entsprechende Anzeigewiedergabereihenfolge. In diesem Beispiel folgen den P-Frames jeweils drei B-Frames in der Codierungsreihenfolge. In der Zwischenzeit wird in der Anzeigereihenfolge jedes P-Frame nach drei B-Frames angezeigt, wodurch demonstriert wird, dass die Codierungsreihenfolge und die Anzeigereihenfolge nicht dieselbe sind. Zusätzlich wird angemerkt, dass das Auftreten von P-Frames und B-Frames im Allgemeinen abhängig davon, wie viel Bewegung in dem erfassten Video anwesend ist, unterschiedlich sein wird; die Verwendung eines P-Frames, dem drei B-Frames folgen, erfolgt hier der Einfachheit und des leichteren Verständnisses halber, wie I-Frames, P-Frames und B-Frames implementiert werden.
Ohne H.264-Verarbeitungslatenzen auch nur zu betrachten, bedingt der Umstand, dass I-Frames, P-Frames und B-Frames von H.264 in einer anderen Reihenfolge als bei der Wiedergabe codiert werden, signifikante Latenzen. Bei einer nominalen Einzelbildrate von 30 Einzelbildern pro Sekunde (fps) kann zum Beispiel ein Abschnitt von Video mit viel Bewegung P-Frames erfordern, die durch Betrachtung von 15 oder mehr vorherigen Einzelbildern verarbeitet werden. Dies führt nur auf der H.264-Codiererseite zu einer Latenz von einer halben Sekunde oder mehr. Addition der sich aus zusätzlichen Verarbeitungsoperationen ergebenden Latenzen kann eine Verzögerung von mehr als einer Sekunde oder für Quellen, die niedrigere Einzelbildraten (z. B. 15 fps) und/oder Inhalt mit höherer Auflösung unterstützen, sogar mehreren Sekunden führen. Solche Latenzen sowie merkliche Artefakte im Wiedergabe-Anzeigeinhalt werden für Inhalt mit viel Bewegung verschlimmert. Verwendung herkömmlicher Remote-Desktop-Techniken ist folglich zur Fernanzeige von Echtzeit-Rückmeldung erforderndem Inhalt, wie etwa bei Spielanwendungen, nicht praktikabel.
Die obigen Unzulänglichkeiten werden durch die Ausführungsformen in 19b und 19c angegangen, die nativen Windows-Grafikinhalt bzw. nativen Android-Grafikinhalt werfen. Jede dieser Ausführungsformen verwendet ein aufgeteiltes natives Grafik-/RDP-Benutzereingabeschema, wobei nativer Grafikinhalt unter Verwendung einer oder mehrerer anwendbarer Verbindungen geworfen wird, während Benutzereingaben unter Verwendung des herkömmlichen RDP-Schemas zum Zurückgeben von Benutzereingaben an den Remote-Desktop-Server 1900 zurückgegeben werden.
Wie in 19b gezeigt, implementiert die Computerkarte 100 einen nativen Windows-Grafikwerfer 1508 zum Werfen von Windows-Grafikinhalt, der DirectX- und GDI/GDI+-Befehle (je nach Fall mit zugeordnetem Rasterinhalt) umfasst, zu einem Windows-zu-Android-Grafikumsetzer und -fänger 1804, abgebildet durch DirectX-Pakete 1910 und GDI-Pakete 1912. Es wird angemerkt, dass ein gegebenes Paket einen oder mehrere Grafikbefehle enthalten kann und es Fälle geben kann, in denen einige Arten von Inhalt betreffender Grafikinhalt unter Verwendung mehrerer Pakete (wie etwa eines großen Rasterbildes) transportiert werden kann. Obwohl es nicht gezeigt ist, um ein Durcheinander zu vermeiden, ist das Aufbauen der Verbindung und wie der native Windows-Grafikinhalt transferiert würde, ähnlich wie in 17b gezeigt und oben besprochen.
Unter 19c implementiert die Computerkarte 100 einen Widows-zu-Android-Grafikumsetzer und -werfer 1602, der als OpenGL-Pakete 1914 und Skia-Pakete 1916 abgebildeten Android-Grafikinhalt zu einem Android-Grafikfänger 810a auf einem Android-Hostgerät 102 wirft. Obwohl es nicht gezeigt ist, um ein Durcheinander zu vermeiden, ist das Aufbauen der Verbindung und wie der native Android-Grafikinhalt transferiert würde, ähnlich wie in 17a gezeigt und oben besprochen.
Zusätzlich zu dem Werfen von nativen Grafikbefehlen und - inhalten von einer Datenverarbeitungskarte zu einem Android-Hostgerät wird das Android-Hostgerät ferner befähigt, Android-Grafikbefehle und -inhalte zu werfen, damit sie entfernt angezeigt werden. Zum Beispiel zeigt 23 eine Konfiguration, unter der eine Datenverarbeitungskarte 100 native Windows- oder native Android-Grafikbefehle und -inhalte zu einem Android-Hostgerät 102 wirft, das seinerseits native Android-Grafikbefehle und -inhalte zu einem Android-TV 2300 wirft.
Vor Kurzem hat Google auf Google I/O 2014 Android TV eingeführt. Android-TVs sind intelligente TV-Plattformen, die von Google entwickelte Android-Software verwenden (insbesondere läuft auf den Android-TV-Plattformen das Betriebssystem Android 5.0 („Lollipop“)). Die Android-TV-Plattform ist dafür ausgelegt, in beiden TVs (z. B. HDTVs und UHDTVs), Beistellgeräten sowie Streaming-Mediengeräten wie Blu-ray-Playern, die Streaming-Medien unterstützen, implementiert zu werden.
Unter der Android-TV-Architektur ist das Android-TV-Gerät dafür ausgelegt, Chromecast-Inhalt zu empfangen, der von einem Chromecast-Castinggerät gesendet wird, das typischerweise ein Android-Mobilgerät oder ein Chromebook sein wird. Unter dem Chromecast-Ansatz wird ein Chrome-Browser auf dem Empfangsgerät implementiert und dient zum Rendern des Chromecast-Inhalts. Angewandt auf eine oder mehrere hier besprochene Android-Ausführungsformen bedeutet dies, dass die Android-TV-Geräte bereits die Android-Grafikkomponenten (sowohl Software- als auch Hardwarekomponenten) aufweisen, die zum Rendern von Android-Grafikbefehlen und -inhalten verwendet werden.
Wohlbekannte HDTV- und UHDTV-Hersteller, darunter Sony und Sharp, bilden Partnerschaften mit Google, um 2015 HDTV- und UHDTV-Plattformen zu implementieren und anzubieten, während Razer und Asus planen, in der nahen Zukunft Beistellgeräte herauszugeben, die Android TV unterstützen. Das erste Gerät, das Android TV verwendet, ist der Nexus Player, der von Google und Asus zusammen entwickelt und im November 2014 herausgegeben wurde.
Integrierte Kapselungsbeispiele
Eine Datenverarbeitungskarte kann unter Verwendung verschiedener Kapselungsschemata in ein Android-Gerät (seine Prozessorplatine) eingebettet oder anderweitig damit kommunikativ gekoppelt werden. 24a und 24b zeigen ein integriertes Android/Windows-Gerät 2400 mit einem Backpack 2402, in dem ein Android-Telefon 2404 installiert ist. Viele Android-Smartphones umfassen im Allgemeinen einen weiblichen Mikro-USB-Port, der dafür ausgelegt ist, mit einem männlichen Mikro-USB-Verbinder in Verbindung zu treten, wie etwa wenn das Android-Telefon aufgeladen wird. Bei einer Ausführungsform ist ein männlicher Mikro-USB-Verbinder 2406 im unteren Teil des Backpack 2402 angeordnet und dafür ausgelegt, mit einem weiblichen Mikro-USB-Port an dem Android-Telefon 2404 in Verbindung zu treten. Zusätzlich umfasst das Backpack 2402 ferner einen weiblichen Mikro-USB-Port 2408 und eine Einschalttaste 2510. Der weibliche Mikro-USB-Port 2408 ist intern mit dem männlichen Mikro-USB-Verbinder 2406 gekoppelt, um somit Laden und Anbinden des Android-Telefons 2404, wenn es in dem Backpack 2402 installiert ist, zu ermöglichen.
Bei einigen Ausführungsformen kann eine Prozessorplatine, wie etwa die Prozessorplatine 300 von 3, in einem Backpack untergebracht sein, mit internen Verbindern und Verdrahtung, die Komponenten auf der Prozessorplatine mit einem beliebigen Verbinder koppelt, der zum Koppeln mit dem Android-Gerät verwendet wird. Bei einigen Ausführungsformen kann ein Backpack somit eine eingebaute Prozessorplatine umfassen, die physisch an dem Backpack angebracht ist.
Bei anderen Ausführungsformen kann eine Prozessorplatine in einem Gehäuse angeordnet sein, wie etwa durch die Datenverarbeitungskarte 2500 von 25a, 25b und 25c abgebildet. Die Kapselung für Datenverarbeitungskarte 2500 umfasst ein Gehäuse mit einer Gehäuseschale 2502, woran eine Abdeckplatte 2504 angebracht ist. Wie in 25b gezeigt ist eine Prozessorplatine 2600 in dem Gehäuse angeordnet und umfasst einen Randverbinder 2602, der extern zugänglich (d. h. nicht im Gehäuse angeordnet) ist. Wie in 25c gezeigt umfasst bei einer Ausführungsform die Datenverarbeitungskarte 2500 eine Taste 2506 und optionale LEDs 2508. Bei einer Ausführungsform ist die Datenverarbeitungskarte 2500 in dem Backpack 2402 angeordnet und ihr Randverbinder 2602 ist mit einem passenden Verbinder gekoppelt, der im unteren Teil des Backpack 2402 (nicht gezeigt) angeordnet ist. Bei einer alternativen Konfiguration kann eine Datenverarbeitungskarte in die Rückseite eines Backpack oder einer ähnlichen Vorrichtung eingefügt werden, wodurch die Datenverarbeitungskarte vom Backpack entfernt werden kann, ohne Entfernung des Android-Telefons vom Backpack zu erfordern. Unter verschiedenen Optionen kann ein Backpack zusätzliche Ressourcen umfassen, wie etwa eine Batterie und eine zugeordnete Batteriestromversorgung und Ladeschaltkreise. Zusätzlich kann die Datenverarbeitungskarte selbst eine Batterie umfassen.
26 zeigt eine Ausführungsform einer Prozessorplatine 2600, die in der Datenverarbeitungskarte 2500 verwendet wird. Die Prozessorplatine 2600 umfasst einen Randverbinder 2602, mit dem eine I/O-Signal- und Spannungsschnittstelle mit anderen Komponenten bereitgestellt wird. Die Prozessorplatine 2600 umfasst ferner ein Prozessor-SoC 2604, zwei DRAM-Chips 2606 und 2608, nichtflüchtige Speicherung mit einem Flash-Chip 2610, einen PMIC-Chip (Power Management Integrated Circuit) 2612 und einen BIOS-Chip 2614. Zusätzlich würde eine Prozessorplatine verschiedene andere Komponenten und Schaltungselemente umfassen, die Fachleuten wohlbekannt sind und somit nicht getrennt identifiziert werden.
Little-Datenengine
Es gibt verschiedene Domänen, in denen Sensoren und Geräte eingerichtet sind oder deren Einrichtung erwartet wird. Mit dem Kauf von Nest, der Hausautomatisierungsfirma, ist zu erwarten, dass unsere Häuser letztendlich voll automatisiert und mit den Clouds verbunden werden. Gesundheit ist eine andere große Domäne, in denen Wearable-Sensortechnologien eingerichtet werden. Heutzutage verbinden sich die meisten dieser sich auf die Gesundheit konzentrierenden Wearables entweder direkt mit der Cloud oder verwenden für einen Teil ihrer Berechnung und Analyse und als Verbindungsmedium mit der Cloud ein zugeordnetes Smartphone. Kraftfahrzeug-IVI und Fahrzeugwirkungsgrad ist eine andere Domäne, in der mehr und mehr Firmen Cloud-Konnektivität ankündigen und anbieten, verschiedene kritische Parameter in Echtzeit zu überwachen (Verkehr, fahrzeugkritische Betriebssensoren) und Benutzern mit verschiedenen Angeboten und Hilfseinrichtungen helfen. Der Einzelhandel und die Bestellungsbezahlung ist eine andere große Domäne für Datensammlung und -analytik.
Obwohl viele Staaten daran arbeiten, Standard-Privatsphärenrichtlinien für auf Cloudberechnung basierende Organisationen zu entwerfen, fehlt immer noch Bewusstheit und Implementierung dieser Richtlinien (selbst wenn sie existieren). Sensoren und Cloud-Konnektivität weisen wesentliche Einschränkungen bezüglich Privatsphäre, Flexibilität und Fairness auf. Die aktuellen Industrieansätze haben Funktionalität gegenüber Privatsphäre und Sicherheit favorisiert.
Das Sammeln der Daten von Sensoren und Geräten auf sichere Weise ist eine problematische Aufgabe. Heutzutage schieben die meisten der Geräte ihre Daten entweder auf einen bestimmten zentralen Punkt (wie etwa ein zugeordnetes Smartphone, Home-Gateway usw.) unter Verwendung drahtloser Verbindung (z. B. BLUETOOTH) oder sprechen direkt mit der Cloud (z. B. Google Glass) unter Verwendung eines Mobilnetzes. Ein großer Teil des Datentransfers geschieht in unverschlüsselter Form. Direkte Cloud-Konnektivität erfordert hohen Stromverbrauch von dem Gerät. Außerdem erfordert es, dass jedes Gerät eine einzigartige Internetverbindung aufweist. Die Zentralpunktverbindung (Gateway-Modell) erfordert dagegen nur eine Internetverbindung für mehrere Geräte und kann ein energiesparendes Sensornetzwerk zur Verbindung mit dem Gateway verwenden und verbraucht daher weniger Strom pro Gerät. Verschlüsselung führt zu Energie-, Leistungsfähgkeits- und Kostentaxen an den Sensoren.
Der größte Teil der Daten wird aus zwei Gründen in der Cloud gespeichert: universeller Zugriff und Abtragen von Daten. In der letzten Zeit wurden mehr Fragen über die Privatsphäre der Daten gestellt, wie etwa: (a) wer kann die Daten verwenden; und (b) welche Daten können von der äußeren Community gesehen werden. Ein Teil dieser Daten ist sehr heikel und Ausnutzung kann zu Missbrauch und großem finanziellen Verlust führen. Die Gesundheitsdaten eines Individuums sind ein Bespiel für die privatesten Daten, die sorgfältige Zugangskontrolle erfordern. Das größte Problem für die medizinische Industrie ist, die Gesundheitsdaten abzutragen, ohne sie zu sehen. Einige Vorschläge für das anonyme Datenabtragen kamen sowohl von wohlbekannten als auch weniger bekannten Firmen und Organisationen. Die Effektivität dieser Systeme muss jedoch immer noch validiert werden.
In den meisten dieser Fälle müssen nicht alle Daten in unverschlüsselter Form in die öffentliche Domäne gelegt werden. Zum Beispiel möchten Fahrer von Automobilen ihre Fahrgeschwindigkeitsaufzeichnungen und Autowartungsaufzeichnungen nicht mit der öffentlichen Domäne teilen. Viele Menschen teilen ungern ihre Markenpräferenzen, wobei erkannt wird, dass diese Art von Informationen oft von Vermarktungsfirmen und dergleichen missbraucht wird. Ähnlich können Menschen nicht wünschen, ihre Ernährungs- und Nahrungsmittelpräferenzen mit der Öffentlichkeit zu teilen. Die Little-Datenengine behandelt dieses Problem auf einzigartige Weise - durch lokale sichere Verarbeitung.
Datenverarbeitung kann in zwei Kategorien aufgeteilt werden: erstens die Verarbeitung, die die Sensordaten mit dem Rest der Community-Daten kombiniert und dann daraus einige interessante und heikle Informationen erstellt. Zum Beispiel wie unsere Stromrechnung im Vergleich mit unseren Nachbarn aussieht, die wahrscheinlich dasselbe Wetter erfahren. Zweitens die Integration neuer lokaler Daten mit zuvor hergestellten Daten des Typs Einzelhandel, Gesundheit, Automobil und Haus.
Little-Datenkombinieren und -integrieren ist ein Teil der Datenverarbeitung, Verarbeitung mit Big-Daten ein anderer. Big-Datenverarbeitung kann ferner in zwei Kategorien eingeteilt werden: erstens lokales Kombinieren und Verarbeiten. Zweitens Kombinieren mit öffentlichen Daten und Verarbeitung. Abhängig von der Benutzerpräferenz kann man an lokalen privaten Daten lokale Verarbeitung und für öffentliche Daten Cloud- oder Fernverarbeitung wählen. Aktuelle Systeme stellen solche Flexibilität leider nicht bereit. Die gesamte Verarbeitung geschieht in der Cloud. Die Little-Datenengine wird es Benutzern ermöglichen, lokale Verarbeitung und Privatsphäre zu wählen, während ein offener Innovation-Sandkasten bereitgestellt wird.
Datenempfehlung kann in beliebiger Form erfolgen, wie Angebote, Vorschläge, Warnung usw., damit das Leben der Kunden bequemer wird. Datenempfehlungen können für ein Individuum oder auf großer Ebene für eine Region oder für die Community verwendet werden. Datenempfehlung kann an ein Individuum oder an interessierte Käufer verkauft werden. Die große Frage, die entsteht, ist, ob Individuen ihre Empfehlungsangebote anderen zeigen und diese sie wirksam einsetzen lassen möchten. Über welche Art von Diskretheit kann ein Endbenutzer diesbezüglich verfügen? Über welche Art von Diskretheiten können Individuen verfügen? Vielleicht kann es erwünscht sein, einigen der Abtragungsinformationen zu erlauben, der äußeren Community zu zeigten, dass sie Individuen oder Gruppen indirekt helfen kann, während es erwünscht sein kann, andere Teile niemals mit der Öffentlichkeit zu teilen. Zum Beispiel würde man seine unterdurchschnittliche Fahrerfahrung verglichen mit der äußeren Community nicht teilen wollen, aber gleichzeitig seinen überdurchschnittlichen Autowartungsverlauf teilen wollen.
Aktuelle Datenarchitekturen führen zu zu vielen Endbenutzerbesorgnissen und anderen Beschränkungen. Stattdessen sollte ein ideales Datenökosystem Folgendes bereitstellen:
ein hochflexibles und anpassbares System vom Standpunkt aller interessierten Teilnehmer aus gesehen.
Endbenutzer können den Privatsphärenknopf auf der Basis verschiedener Daten ändern.
Ein Benutzer kann ändern, in welcher Cloud er speichern möchte und wo er Datenverarbeitung wünscht (z. B. lokale oder entfernte Verarbeitung).
Ein hochsicheres und zuverlässiges System, das vertrauenswürdig ist.
Vorzugsweise vertrauen alle Teilnehmer einander auf der Basis des Systementwurfs des Informationsflusses.
Gleiche Interessenvertreter aller Teilnehmer, um zu vermeiden, dass irgendeiner dieser zu viel Aufmerksamkeit erhält.
Benutzer halten ihre Daten und können sie an beliebige verkaufen, gleichgültig, wessen Sensoren und Gerät in dem persönlichen Ökosystem installiert sind oder eine lose Bindung zwischen Gerät und Cloud aufweisen.
Auf der Basis von Benutzerpräferenz können Daten gespeichert, abgetragen werden und Informationen können ohne Beschränkung von der Benutzerseite an mehrere Käufer verkauft werden.
Der optimale Auslastungsgrad der verbundenen Ressource im System zum Vermindern der Kosten.
Verringern der erforderlichen Internetverbindung und somit der Energie zum Transfer der Daten.
Vorzugsweise ein Gerät zum Verwalten aller Sensoren in verschiedenen Domänen.
Vermeidung des Missbrauchs der abgetragenen Daten auf direkte oder indirekte Weise.
Alle Daten sollten ein bestimmtes zentrales Gerät durchlaufen, das der Benutzer besitzt und wartet, mit strikter Sicherheit und bevorzugten konfigurierten Privatsphären-, Flexibilitätsoptionen.
Die Little-Datenengine (LDE) ist ein Manager für das Sensor-Cloud-Konnektivitätsökosystem von Benutzern, der Datensammlung, Datenspeicherung, Datenverarbeitung und Datenempfehlung verwaltet. Er ist ein zentrales Gerät, das ein Individuum besitzt und wartet. Die Engine ist im Hinblick auf Privatsphäre und Flexibilität voll anpassbar. Auf der Basis der erforderlichen Merkmale und angepassten Benutzerkonfiguration kann Datenspeicherung, -verarbeitung und -empfehlung gleichzeitig durch die LDE und in der Cloud geschehen oder kann gänzlich lokal in der LDE auf vom Benutzer bevorzugte definierte Weise geschehen. Die LDE respektiert die Endbenutzerpräferenzen und -diskretheiten. Sie erlaubt dem Benutzer, mit der verschiedenartigen Cloud als Datenspeicherung, Datenabtrager oder Informationskäufer zu verbinden und treibt somit den fairen Wettbewerb voran, um optimale Ressourcenauslastung und Ablieferung billiger Lösungen an die Community sicherzustellen.
Die LDE-Architektur ist dafür ausgelegt, Benutzern maximale Flexibilität im Hinblick auf Merkmale, Verwaltung und Privatsphäre des Systems zu geben. Dies wird mittels einer Engine zur Verwaltung der gesamten Sensoren und Geräte eines Benutzers unterstützt. Die Architektur ist auch im Hinblick auf Privatsphäre und Merkmale hoch flexibel, wodurch es Benutzern ermöglicht wird, die LDE an ihre Bedürfnisse anzupassen. Die LDE unterstützt Offline-Merkmale und - Funktionalität, so dass sie in unverbundenen Umgebungen benutzt werden kann.
27 zeigt eine Übersicht auf hoher Ebene über ausgewählte Komponenten in einer LDE-Architektur 2700 gemäß einer Ausführungsform. Beispielhafte Mengen von Daten sind an der obersten Position der Architektur 2700 abgebildet, darunter Gesundheitsversorgungsdaten 2702, Hausdaten 2704, Internet-Geschmacksdaten 2706, Kaufmusterdaten 2708 und Reisedaten 2710. Es versteht sich, dass diese lediglich einige wenige Arten von Daten sind, die durch eine LDE gespeichert werden können.
Wie durch eine lokale Integration 2712 gezeigt, sind alle Daten entsprechend den Gesundheitsversorgungsdaten 2702, den Hausdaten 2704, den Internet-Geschmacksdaten 2706, den Kaufmusterdaten 2708 und den Reisedaten 2710 in einem Ort, z. B. auf dem einen Gerät, integriert. Durch einen Lokalanalyseblock 2714 kann eine lokale Analyse an den Daten ausgeführt werden, was zu einer oder mehreren persönlichen Empfehlungen führen kann, wie nachfolgend ausführlicher beschrieben wird. Ein Benutzer kann auch wählen, ausgewählte Daten mit anderen und/oder verschiedenen Datendiensten, wie etwa Cloud-gehosteten Datendiensten, zu teilen. Dies wird durch einen Block 2716 mit der Bezeichnung „minimales Publizieren“ und einen mit Analyse bezeichneten Block 2718 in der Cloud unterstützt.
28 zeigt eine Architektur 2800 für den analytischen Stapel der LDE in Bezug auf Sensordaten-Verarbeitung. Die Architektur 2800 umfasst Rohsensordaten 2802, Sensordatenbibliotheken 2804, LDE-Bibliotheken 2806. Die LDE-Bibliotheken ermöglichen Integration mit Anwendungen Dritter, darunter Einzelhandels-Apps 2808, Haus-Apps 2810 und Gesundheits-Apps 2812, die jeweils als Einzelhandelsempfehlungen 2814, Hausempfehlungen 2816 bzw. Gesundheitsempfehlungen 2818 bereitstellend gezeigt sind.
Im Allgemeinen kann die LDE-Architektur-Datensammlung von den Sensoren auf ablaufender Echtzeitbasis und/oder periodisch (z. B. über Abfragen oder dergleichen) durchgeführt werden. Bei einer Ausführungsform hängt dies von der Nähe der LDE zu den Sensoren ab. Zum Beispiel kann ein Benutzer die Daten von Automobilsensoren abrufen, während er sich im Auto befindet, und von Haussensoren, wenn er sich zu Hause befindet. Ein gegebener Sensor umfasst im Allgemeinen minimale lokale Speicherung für Rohdaten oder halbverarbeitete Daten, abhängig vom Sensortyp. Bei einer Ausführungsform wird jeder Sensor unter Verwendung eines Sicherheitsauthentifizierungs- und autorisierungsprotokolls im Voraus bei der LDE registriert, und heikle Daten werden in verschlüsselter Form zur LDE transferiert.
Bei einer Ausführungsform umfasst die LDE ITB oder mehr Speicherung in dem Gerät selbst. Im Allgemeinen ist es nicht notwendig, die Rohsensordaten auf der LDE zu speichern; stattdessen müssen nur die verarbeiteten Daten gespeichert werden. Zum Beispiel wird eine Echtzeitbestimmung von im Verlauf des Tages verbrannten Kalorien von einem Kaloriensensorgerät nicht gespeichert, stattdessen kann die LDE pro Tag oder pro Stunde verbrannte Kalorien abspeichern. Die LDE kann auch als Cache in einer insgesamten Datenspeicherungsarchitektur, einschließlich Speicherung auf Cloud-Basis, wirken. Zum Beispiel werden durch die LDE von Sensoren gesammelte Daten verschlüsselt und zu der bevorzugten öffentlichen Cloud des Benutzers gesendet, und der Verschlüsselungsschlüssel kann über den sicheren Schlüsselbund eines Benutzers oder andere wohlbekannte Techniken in einer Sicherheits-Cloud gespeichert werden.
Bei einer Ausführungsform umfasst die LDE eine Hardware-Analytik-SoC-Engine und eine wohldefinierte API, worauf ein App-Ökosystem aufgebaut werden kann. Wie in 27 gezeigt, kann Datenverarbeitung abhängig von Benutzerkonfiguration, Internetverbindung und Abfragetyp in zwei Teile aufgeteilt werden, lokal und entfernt (in der Cloud). Verarbeitung öffentlicher Daten kann in der Cloud oder lokal geschehen. Privatdatenverarbeitung geschieht immer lokal. Lokale Verarbeitung umfasst Datenintegration von verschiedenen Sensoren und Durchführen von Analytik an integrierten Daten. Zum Beispiel können, während man nach einem Ort zum Mittagessen sucht, nahegelegene Restaurants aus der öffentlichen Cloud abgerufen werden, während die Ernährungspräferenz und Fahrgeschwindigkeit eines Benutzers lokal aus privaten Daten abgerufen werden können und Empfehlungen können erzeugt werden, indem identifiziert wird, welche Restaurants geeignet sind (um die Ernährungspräferenzen zu erfüllen) und wieviel Zeit es kostet, sie zu erreichen. Als mobiles Gerät hat die LDE den Vorteil, mit mehreren Bereichen zu reden, und ist dazu in der Lage, Informationen viel besser als andere existierende Lösungen zu synthetisieren.
Ähnlich wie bei der Datenverarbeitung kann eine Datenempfehlung aus einer öffentlichen Cloud oder aus der LDE entnommen werden, oder sie kann eine Mischung aus beidem sein. Auf der Basis des Anfragetyps wird die LDE die Verarbeitung zur Cloud oder lokal zur Analyse verlagern und die Empfehlung aus der Cloud nehmen und sie mit lokalen Empfehlungsdaten integrieren und sie zum Benutzer senden.
29 zeigt eine Software-API 2900 für die LDE gemäß einer Ausführungsform. In ihrem Kern umfasst die Software-API 2900 eine Integrierer- und Analytikengine 2902, die Eingangseinstellungen 2904 empfängt, wie etwa Privatsphäreneinstellungen, Speicherungseinstellungen, Cloud-Einstellungen und Analytik-Einstellungen. Die Integrierer- und Analytikengine 2902 empfängt Eingaben von Haussensoren 2906, Gesundheitssensoren 2908, Autosensoren 2910 und Einzelhandelssensoren 2912, wobei zu beachten ist, dass andere als die Integrierer- und Analytikengine Eingaben von anderen Arten von Sensoren (nicht gezeigt) empfangen können. Die Integrierer- und Analytikeingine 2902 führt einer Haus-API 2914, einer Gesundheits-API 2916, einer Auto-API 2918 und einer Einzelhandels-API 2920 Eingaben zu. Jede dieser APIs stellt eine Programmierschnittstelle zu einer damit zusammenhängenden Dritt-Anwendungsklasse bereit, die ihrerseits zugeordnete Empfehlungen bereitstellt. Die Dritt-Anwendungen umfassen z. B. Haus-Apps 2922, Gesundheits-Apps 2924, Auto-Apps 2926 und Einzelhandels-Apps 2928, die jeweils eine jeweilige Empfehlung geben, abgebildet als HausEmpfehlung 2930, Wearable-Empfehlung 2932, Auto-Empfehlung 2934 und Einzelhandels-Empfehlung 2936.
30 zeigt ein persönliches Analytik-Benutzungsmodell 3000 gemäß einer Ausführungsform. Das persönliche Analytik-Benutzungsmodell 3000 ist als ein Tabelle angelegt, die eine Einzelhandelsspalte 3002, eine Hausspalte 3004 und eine Gesundheitsspalte 3006, eine Erfassungszeile 3008, eine Integrationszeile 3010 und eine Empfehlungszeile 3012 umfasst. Der Prozessfluss verläuft nach unten vom Empfangen von Sensordaten (d. h. wie in der Erfassungszeile 3008 abgebildet), Integrieren der Daten (Integrationszeile 3010) und Erzeugen einer Empfehlung (Empfehlungszeile 3012). Beispielsweise kann das Analytik-Benutzungsmodell für Gesundheit eines Benutzers Erfassen des Pulses, der Hauttemperatur, der Bewegungsaktivität (z. B. Gehen, Fahrradfahren usw.), Schlaf- und Ernährungsinformationen des Benutzers umfassen. Die Informationen werden mit Eingaben aus der Einzelhandelsspalte 3002 und 3004 integriert und verarbeitet, um einen Kalender, Ausgehoptionen, Hausumgebungsdaten und Wetterdaten zu produzieren. Es werden dann Empfehlungen bereitgestellt, darunter Empfehlungsübungen, Ernährungsverbesserungen und reguläre Aktivitäten.
31 zeigt eine Implementierungsarchitektur 3100, die weitere Integration von oben besprochenen Komponenten veranschaulicht. Die Implementierungsarchitektur 3100 umfasst Haussensoren 3102, Wearable-Sensoren 3104, Auto-Sensoren 3106, Einzelhandels-Sensoren 3108, sichere Datensammler 3110, 3112, 3114 und 3116, sichere Datenspeicherung 3118, Datenintegrierer und -kombinieren 3120, Prozessdaten 3122, eine Analytik-Engine 3124, eine Hausempfehlung 3126, eine Wearable-Empfehlung 3128, eine Auto-Empfehlung 3130, eine Einzelhandels-Empfehlung 3132, eine Haus-API 3134, eine Wearable-API 3136, eine Auto-API 3138, eine Einzelhandels-API 3140, Anwendungen Dritter 3142 und eine Cloud 3144.
Die Prozessdaten 3122 repräsentieren Daten, die mittels Verarbeitung verschiedener Sensoreingaben und anderer Eingangsdaten erzeugt werden. Wie oben mit Bezug auf 27 besprochen, kann ein Benutzer selektiv einen beliebigen Teil der Prozessdaten 3122, den der Benutzer wünscht, auf die Cloud 3144 publizieren. Dies ermöglicht auf der Cloud basierende Analytik der Daten, die durch die Analytik-Engine 3124 empfangen werden. Die Analytik-Engine 3124 erzeugt Empfehlungen, darunter eine oder mehrere von Hausempfehlung 3126, Wearable-Empfehlung 3128, Auto-Empfehlung 3130 und Einzelhandels-Empfehlung 3132 entweder gänzlich lokal oder in Kombination mit Empfehlungen auf Cloud-Basis.
Datenverarbeitungskarte mit USB-Typ-C-Verbinder
32 zeigt eine Ausführungsform einer Datenverarbeitungskarte 3200, die einen USB-Typ-C-Verbinder 3202 als einzige vereinigte Schnittstelle verwendet. Die Datenverarbeitungskarte 3200 umfasst ferner eine interne Stromversorgungsschnittstelle 3204, eine USB-3-Schnittstelle 3206 und eine DisplayPort-Schnittstelle 3208, ein Subsystem 3210 für PMIC (Power Management IC) und Stromversorgung, eine SSD-BGA-Speicherungsvorrichtung (Solid-State Drive Ball Grid Array) 3212, ein SoC 3214 mit Intel®-Architektur (IA) mit dynamischem Direktzugriffsspeicher (DRAM), der unter Verwendung von PoP-Kapselung (Packet-on-Package) mit dem SoC gekoppelt ist, eine System-Sleep-Batterie 3216, einen Finterabdruckleser 3218 und LEDs 3220.
Zusätzlich zu den in 32 gezeigten Komponenten kann eine Datenverarbeitungskarte, die einen USB-Typ-C-Verbinder verwendet, andere Schaltkreise umfassen, sowie etwa in anderen vorliegenden Datenverarbeitungskartenausführungsformen dargestellt sind, einschließlich der Datenverarbeitungskarte 300 von 3. Statt einen Dock-Verbinder mit mehreren Verbindern zu verwenden, wird jedoch ein einziger USB-Typ-C-Verbinder verwendet.
33 zeigt eine Ausführungsform von Schnittstellenschaltkreisen zwischen einem USB-Typ-C-Verbinder 3300, einer CPU 3302 und einem PMIC 3304. Die vier Hochgeschwindigkeits-USB-Typ-C-Spuren 3306 werden über einen Multiplexer 3308 gemultiplext, wobei zwei Leitungen auf der linken Seite des Multiplexers 3308 mit einer USB-3.0-Schnittstelle 3310 gekoppelt sind, während vier Leitungen mit einer DisplayPort-Schnittstelle 3312 gekoppelt sind. Die zwei SBU-Signale (Sideband Use) 3314 sind mit einem Multiplexer 3316 gekoppelt, mit dem selektiv eine 12C-Hilfsschnittstelle 3318 zur Kommunikation mit mit dem USB-Verbinder 3300 gekoppelten Geräten freigegeben wird. Die USB-2.0-Signale 3320 werden mit einer USB-2.0-Schnittstelle 3322 gekoppelt. In der Zwischenzeit werden die zwei Steuerkanal- bzw. CC-Signale 3324 mit einer Typ-C-PD-Schnittstelle 3326 auf dem PMIC 3304 gekoppelt.
34a und 34b zeigen perspektivische Ansichten einer Datenverarbeitungskarte 3400, die einen USB-Typ-C-Verbinder 3402 und einen Fingerabdruckleser 3404 umfasst. Die Datenverarbeitungskarte 3400 umfasst ferner eine Leiterplatte, die die Schaltkreise und Komponenten der Datenverarbeitungskarte 3200 umfasst. Bei einer Ausführungsform sind die Höhe (H) und Breite (B) der Datenverarbeitungskarte ungefähr die gleichen Abmessungen wie eine Standard-Kreditkarte, während die Dicke ungefähr vier Kreditkarten beträgt.
35a und 35b zeigen jeweils isometrische Ansichten einer Ausführungsform eines Mobiltelefons 3500, das mit einer Datenverarbeitungskarte 3400 verbunden ist. Bei einer Ausführungsform wird die Datenverarbeitungskarte 3200 in einen Steckplatz in der Rückseite des Mobiltelefons 3500 eingefügt, wie in 35b abgebildet. Gegebenenfalls kann die Datenverarbeitungskarte 3400 in einem Gehäuse eines Mobiltelefons enthalten, wie etwa unter einer Rückplatte des Mobiltelefons (nicht gezeigt) angeordnet, sein.
Die hier offenbarten Ausführungsformen stellen gegenüber existierenden Ansätzen, die mehrere Geräte zur Unterstützung des Zugangs zu Lieblings-Android-Anwendungen eines Benutzers erfordern, signifikante Vorteile bereit, während auch Zugang zu nativer Windows-Anwendung, im Gegensatz zu serverseitigen Anwendungen auf Cloud-Basis, unterstützt wird. Die Grundbeschränkung von Android, virtualisierte Umgebungen nicht zu unterstützen, wird überwunden, indem Windows auf physischer Hardware laufengelassen wird, die nicht nur volle Desktop-Versionen von Windows unterstützt. Das heißt, dass jede durch das Desktop-OS unterstützte Windows-Anwendung über die hier bereitgestellten integrierten Android/Windows-Lösungen verfügbar ist.
Weitere Aspekte des hier beschriebenen Gegenstands werden in den folgenden nummerierten Klauseln dargelegt:

1. Vorrichtung, umfassend:
- eine erste Prozessorplatine, umfassend:
  - einen ersten Prozessor;
  - eine entweder in den ersten Prozessor eingebaute oder wirksam mit dem ersten Prozessor gekoppelte Grafikprozessoreinheit bzw. GPU;
  - wirksam mit dem ersten Prozessor gekoppelten ersten Speicher;
  - entweder in den ersten Prozessor oder die GPU eingebaute oder wirksam mit dem ersten Prozessor oder der GPU gekoppelte Anzeigeausgangsschaltkreise;
  - eine kommunikativ mit den Anzeigeausgangsschaltkreisen gekoppelte Touchscreen-Anzeige; und
  - nichtflüchtige Speicherung, in der erste Anweisungen gespeichert werden, die ein Android-Betriebssystem und mehrere Android-Anwendungen umfassen;
- eine kommunikativ mit der ersten Prozessorplatine gekoppelte zweite Prozessorplatine, umfassend:
  - einen zweiten Prozessor;
  - wirksam mit dem zweiten Prozessor gekoppelten zweiten Speicher; und
  - nichtflüchtige Speicherung, ihn der zweite Anweisungen gespeichert werden, die ein Windows-Betriebssystem und mehrere Windows-Anwendungen umfassen,
  - wobei beim Betrieb die Vorrichtung einem Benutzer ermöglicht, selektiv die mehreren Android-Anwendungen und die mehreren Windows-Anwendungen laufenzulassen, und wobei die mehreren Windows-Anwendungen auf der zweiten Prozessorplatine ausgeführt werden.
2. Vorrichtung nach Klausel 1, wobei eine der Android-Anwendungen eine Android-Remote-Desktop-Client-Anwendung umfasst, wobei das Windows-Betriebssystem einen Remote-Desktop-Server umfasst und wobei der Remote-Desktop-Server und der Android-Remote-Desktop-Client einem Benutzer ermöglichen, über Benutzereingaben in die Touchscreen-Anzeige aus der Ferne Windows-Anwendungen auf der zweiten Prozessorplatine laufenzulassen.
3. Vorrichtung nach Klausel 1 oder 2, wobei die erste Prozessorplatine ein Android-Grafik-Rendering-Subsystem umfasst, das die GPU umfasst, wobei die zweiten Anweisungen Software zum Implementieren eines nativen Grafikbefehlwerfers umfassen, die zweite Prozessorplatine dafür ausgelegt ist, native Grafikbefehle zu der ersten Prozessorplatine zu werfen und die ersten Anweisungen einen nativen Grafikbefehlsfänger umfassen, der dafür ausgelegt ist, die nativen Grafikbefehle von der ersten Prozessorplatine zu fangen und diese an das Android-Grafik-Rendering-Subsystem abzugeben.
4. Vorrichtung nach Klausel 3, wobei die ersten Anweisungen einen Remote-Desktop-Client umfassen und die zweiten Anweisungen einen Remote-Desktop-Server umfassen und wobei der Remote-Desktop-Client dafür ausgelegt ist, über die Touchscreen-Anzeige getätigte Benutzereingaben zu erfassen und entsprechende Benutzereingabebefehle und/oder -ereignisse zu dem Remote-Desktop-Server weiterzuleiten.
5. Vorrichtung nach einer der vorhergehenden Klauseln, wobei die zweite Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, zu einem auf der ersten Prozessorplatine laufenden Fänger zu werfen, und der Fänger dafür ausgelegt ist, die DirectX-Befehle zu empfangen und sie in entsprechende OpenGL-Befehle umzusetzen.
6. Vorrichtung nach einer der vorhergehenden Klauseln, wobei die zweite Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, in native Android-Grafikbefehle umzusetzen, die OpenGL-Befehle umfassen, und die OpenGL-Befehle zu einem auf der ersten Prozessorplatine laufenden Android-Grafikfänger zu werfen, und der Android-Grafikfänger dafür ausgelegt ist, die OpenGL-Befehle an ein auf der ersten Prozessorplatine implementiertes Android-Grafiksubsystem abzugeben.
7. Vorrichtung nach einer der vorhergehenden Klauseln, wobei die erste Prozessorplatine über eine USB-Verbindung (Universal Serial Bus) mit der zweiten Prozessorplatine gekoppelt ist und wobei Daten über ein über die USB-Verbindung implementiertes Internetprotokoll (IP) zur Bildung einer IP/USB-Verbindung zwischen der ersten Prozessorplatine und der zweiten Prozessorplatine ausgetauscht werden.
8. Vorrichtung nach einer der vorhergehenden Klauseln, wobei die Vorrichtung ein Android-Gerät umfasst, das ein Gehäuse umfasst, in dem sowohl die erste als auch die zweite Prozessorplatine installiert sind.
9. Vorrichtung nach einem der vorhergehenden Klauseln, wobei die Vorrichtung ein Android-Gerät umfasst, das die erste Prozessorplatine enthält, die mit einem die zweite Prozessorplatine enthaltenden Backpack gekoppelt ist.
10. Vorrichtung nach Klausel 9, wobei die erste Prozessorplatine in dem Backpack untergebracht ist.
11. Vorrichtung nach Klausel 9, wobei die erste Prozessorplatine in ein Gehäuse eingekapselt und Teil einer Datenverarbeitungskarte ist, die einen Verbinder umfasst, der dafür ausgelegt ist, mit einem passenden Verbinder an dem Backpack in Verbindung zu treten, um Installation der Datenverarbeitungskarte in dem Backpack zu ermöglichen.
12. Vorrichtung nach einer der vorhergehenden Klauseln, wobei der zweite Prozessor Ausführung von x86-Anweisungen unterstützt.
13. Vorrichtung nach einer der vorhergehenden Klauseln, wobei der zweite Prozessor mehrere Little-Kerne und mindestens einen Big-Kern umfasst und der zweite Prozessor dafür ausgelegt ist, in einem Modus mit verringertem Stromverbrauch zu arbeiten, unter dem Ausführung von Anweisungen durch mindestens einen der mehreren Litte-Kerne ausgeführt wird, und wobei der zweite Prozessor ferner dafür ausgelegt ist, in einem Hochleistungsmodus zu arbeiten, unter dem Ausführung von Anweisungen durch mindestens einen Big-Kern ausgeführt wird.
14. Vorrichtung nach einer der vorhergehenden Klauseln, wobei der zweite Prozessor mehrere energiesparende Kerne umfasst.
15. Vorrichtung nach einer der vorhergehenden Klauseln, wobei die zweite Prozessorplatine Breiten- und Höhenabmessungen aufweist, die ungefähr die Größe einer Kreditkarte oder kleiner sind, und das Windows-Betriebssystem eine Vollversion eines Windows-Betriebssystems ist, die dafür ausgelegt ist, auf einem Desktop- oder Laptop-Computer implementiert zu werden.
16. Vorrichtung nach einer der vorhergehenden Klauseln, wobei die ersten Anweisungen einen Android-Grafikwerfer umfassen, der dafür ausgelegt ist, OpenGL-Befehle zu einem entfernten Anzeigegerät zu werfen, und wobei, wenn ein Benutzer eine Windows-Anwendung ausführt, das Anzeigen einer Anzeige der Windows-Anwendung auf dem entfernten Anzeigegerät ermöglicht wird.
17. Vorrichtung, umfassend:
- ein Backpack, das dafür ausgelegt ist, mit einem Android-Gerät gekoppelt zu werden, das einen ersten USB-Verbinder (Universal Serial Bus) umfasst, wobei das Backpack-Gehäuse einen zweiten USB-Verbinder umfasst, der dafür ausgelegt ist, mit dem ersten USB-Verbinder an dem Android-Gerät in Verbindung zu treten, wenn das Android-Gerät mit dem Backpack gekoppelt wird;
- eine kommunikativ mit dem zweiten USB-Verbinder in dem Backpack-Gehäuse gekoppelte Prozessorplatine, umfassend:
  - einen Prozessor;
  - wirksam mit dem Prozessor gekoppelten Speicher; und
  - nichtflüchtige Speicherung, in der Anweisungen gespeichert sind, die ein Windows-Betriebssystem und mehrere Windows-Anwendungen umfassen,
  - wobei im Betrieb, wenn das Android-Gerät mit dem Backpack gekoppelt ist, einem Benutzer des Android-Geräts ermöglicht wird, selektiv mehrere Android-Anwendungen auf dem Android-Gerät laufenzulassen und aus der Ferne die mehreren Windows-Anwendungen über das Android-Gerät laufenzulassen, und wobei die mehreren Windows-Anwendungen auf der Prozessorplatine ausgeführt werden.
18. Vorrichtung nach Klausel 17, wobei das Android-Gerät eine Touchscreen-Anzeige aufweist und eine Android-Remote-Desktop-Client-Anwendung umfasst, wobei das Windows-Betriebssystem einen Remote-Desktop-Server umfasst und wobei der Remote-Desktop-Server und der Android-Remote-Desktop-Client einem Benutzer ermöglichen, aus der Ferne Windows-Anwendungen über Benutzereingaben in die Touchscreen-Anzeige auf der Prozessorplatine laufenzulassen.
19. Vorrichtung nach Klausel 17 oder 18, wobei das Android-Gerät einen nativen Grafikfänger umfasst, wobei die Anweisungen Software zum Implementieren eines nativen Grafikbefehlwerfers umfassen und wobei die Prozessorplatine dafür ausgelegt ist, native Grafikbefehle zu dem Android-Gerät zu werfen.
20. Vorrichtung nach Klausel 19, wobei das Android-Gerät einen Remote-Desktop-Client umfasst und die Anweisungen einen Remote-Desktop-Server umfassen und wobei der Remote-Desktop-Server dafür ausgelegt ist, durch den Remote-Desktop-Client erzeugte Benutzereingabebefehle und/oder -ereignisse zu empfangen und die Benutzereingabebefehle und/oder -ereignisse an das Windows-Betriebssystem abzugeben.
21. Vorrichtung nach einer der Klauseln 17-20, wobei die Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, zu einem auf dem Android-Gerät laufenden Windows-Grafikcatcher zu werfen.
22. Vorrichtung nach einer der Klauseln 17-21, wobei die Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, in native Android-Grafikbefehle, die OpenGL-Befehle umfassen, umzusetzen und die OpenGL-Befehle zu einem auf dem Android-Gerät laufenden Android-Grafikfänger zu werfen.
23. Vorrichtung nach einer der Klauseln 17-22, wobei Daten über ein über eine USB-Verbindung implementiertes Internetprotokoll (IP) zur Bildung einer IP/USB-Verbindung zwischen der Prozessorplatine und dem Android-Gerät ausgetauscht werden.
24. Vorrichtung nach einer der Klauseln 17-23, wobei die Prozessorplatine dergestalt in dem Backpack untergebracht ist, dass sie nicht nach außen exponiert wird, wenn das Android-Gerät mit dem Backpack gekoppelt ist.
25. Vorrichtung nach einer der Klauseln 17-24, wobei die Prozessorplatine in ein Gehäuse eingekapselt und Teil einer Datenverarbeitungskarte ist, die einen Verbinder umfasst, der dafür ausgelegt ist, mit einem passenden Verbinder an dem Backpack in Verbindung zu treten, um Installation der Datenverarbeitungskarte in dem Backpack zu ermöglichen.
26. Vorrichtung nach einer der Klauseln 17-25, wobei der Prozessor Ausführung von x86-Anweisungen unterstützt.
27. Vorrichtung nach einer der Klauseln 17-26, wobei der Prozessor mehrere Little-Kerne und mindestens einen Big-Kern umfasst und der Prozessor dafür ausgelegt ist, in einem Modus mit verringertem Stromverbrauch zu arbeiten, unter dem Ausführung von Anweisungen durch mindestens einen der mehreren Little-Kerne ausgeführt wird, und wobei der Prozessor ferner dafür ausgelegt ist, in einem Hochleistungsmodus zu arbeiten, unter dem Ausführung von Anweisungen durch mindestens einen Big-Kern ausgeführt wird.
28. Vorrichtung nach einer der Klauseln 17-27, wobei der Prozessor mehrere energiesparende Kerne umfasst.
29. Vorrichtung nach einer der Klauseln 17-28, wobei die zweite Prozessorplatine Breiten- und Höhenabmessungen aufweist, die ungefähr die Größe einer Kreditkarte oder kleiner sind, und das Windows-Betriebssystem eine Vollversion eines Windows-Betriebssystems ist, die dafür ausgelegt ist, auf einem Desktop- oder Laptop-Computer implementiert zu werden.
30. Vorrichtung, umfassend:
- eine Prozessorplatine, umfassend:
  - einen Prozessor;
  - eine wirksam mit dem Prozessor gekoppelte USB-Schnittstelle (Universal Serial Bus);
  - wirksam mit dem Prozessor gekoppelten Speicher; und
  - nichtflüchtige Speicherung, in der Anweisungen gespeichert sind, die ein Windows-Betriebssystem und mehrere Windows-Anwendungen umfassen,
  - wobei die USB-Schnittstelle der Prozessorplatine dafür ausgelegt ist, kommunikativ mit einem USB-Verbinder an einem Android-Gerät gekoppelt zu werden, und
  - wobei im Betrieb, wenn der USB-Verbinder des Android-Geräts kommunikativ mit der USB-Schnittstelle der Prozessorplatine gekoppelt ist, einem Benutzer des Android-Geräts ermöglicht wird, aus der Ferne die mehreren Windows-Anwendungen über das Android-Gerät laufenzulassen, wobei die mehreren Windows-Anwendungen auf der Prozessorplatine ausgeführt werden.
31. Vorrichtung nach Klausel 30, wobei das Android-Gerät eine Touchscreen-Anzeige aufweist und eine Android-Remote-Desktop-Client-Anwendung umfasst, wobei das Windows-Betriebssystem einen Remote-Desktop-Server umfasst, wobei im Betrieb, wenn der USB-Verbinder des Android-Geräts kommunikativ mit der USB-Schnittstelle der Prozessorplatine gekoppelt ist, der Remote-Desktop-Server und der Android-Remote-Desktop-Client einem Benutzer ermöglichen, aus der Ferne Windows-Anwendungen über Benutzereingaben in die Touchscreen-Anzeige auf der Prozessorplatine laufenzulassen.
32. Vorrichtung nach Klausel 30 oder 31, wobei das Android-Gerät einen nativen Grafikfänger umfasst, wobei die Anweisungen Software zum Implementieren eines nativen Grafikbefehlwerfers umfassen und wobei die Prozessorplatine dafür ausgelegt ist, native Grafikbefehle zu dem Android-Gerät zu werfen.
33. Vorrichtung nach Klausel 32, wobei das Android-Gerät einen Remote-Desktop-Client umfasst und die Anweisungen einen Remote-Desktop-Server umfassen und wobei der Remote-Desktop-Server dafür ausgelegt ist, durch den Remote-Desktop-Client erzeugte Benutzereingabebefehle und/oder -ereignisse zu empfangen und die Benutzereingabebefehle und/oder -ereignisse an das Windows-Betriebssystem abzugeben.
34. Vorrichtung nach einer der Klauseln 30-33, wobei die Prozessorplatine dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, zu dem Android-Gerät zu werfen.
35. Vorrichtung nach einer der Klauseln 30-34, wobei das Android-Gerät einen Android-Grafikfänger umfasst und wobei die Prozessorplatine dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, in native Android-Grafikbefehle, die OpenGL-Befehle umfassen, umzusetzen und die OpenGL-Befehle im Betrieb, wenn der USB-Verbinder des Android-Geräts kommunikativ mit der USB-Schnittstelle der Prozessorplatine gekoppelt ist, zu dem Android-Grafikfänger zu werfen.
36. Vorrichtung nach einer der Klauseln 30-35, wobei Daten über ein über eine USB-Verbindung implementiertes Internetprotokoll (IP) zur Bildung einer IP/USB-Verbindung zwischen der Prozessorplatine und dem Android-Gerät ausgetauscht werden.
37. Vorrichtung nach einer der Klauseln 30-36, wobei die Vorrichtung eine Datenverarbeitungskarte umfasst, die ein Gehäuse umfasst, in dem die Prozessorplatine angeordnet ist, wobei die Prozessorplatine einen Randverbinder umfasst und das Gehäuse so ausgelegt ist, dass der Randverbinder außerhalb des Gehäuses ist, und die Datenverarbeitungskarte Breiten- und Höhenabmessungen aufweist, die ungefähr so groß wie die Breite und Höhe einer Kreditkarte oder kleiner sind.
38. Vorrichtung nach einer der Klauseln 30-37, wobei der Prozessor Ausführung von x86-Anweisungen unterstützt.
39. Vorrichtung nach einer der Klauseln 30-38, wobei der Prozessor mehrere Little-Kerne und mindestens einen Big-Kern umfasst und der Prozessor dafür ausgelegt ist, in einem Modus mit verringertem Stromverbrauch zu arbeiten, unter dem Ausführung von Anweisungen durch mindestens einen der mehreren Little-Kerne ausgeführt wird, und wobei der Prozessor ferner dafür ausgelegt ist, in einem Hochleistungsmodus zu arbeiten, unter dem Ausführung von Anweisungen durch mindestens einen Big-Kern ausgeführt wird.
40. Vorrichtung nach einer der Klauseln 30-39, wobei der Prozessor mehrere energiesparende Kerne umfasst.
41. Vorrichtung nach einer der Klauseln 30-40, wobei die Prozessorplatine Breiten- und Höhenabmessungen aufweist, die ungefähr so groß wie die Breite und Höhe einer Kreditkarte oder kleiner sind, und das Windows-Betriebssystem eine Vollversion eines Windows-Betriebssystems ist, die dafür ausgelegt ist, auf einem Desktop- oder Laptop-Computer implementiert zu werden.

Obwohl einige Ausführungsformen in Bezug auf konkrete Implementierungen beschrieben wurden, sind gemäß einigen Ausführungsformen andere Implementierungen möglich. Zusätzlich muss die Anordnung und/oder Reihenfolge von in den Zeichnungen dargestellten und/oder hier beschriebenen Elementen oder anderen Merkmalen nicht auf die spezielle dargestellte und beschriebene Weise eingerichtet sein. Viele andere Anordnungen sind gemäß einigen Ausführungsformen möglich.
In jedem in einer Figur gezeigten System können die Elemente in einigen Fällen jeweils eine selbe Bezugszahl oder eine andere Bezugszahl aufweisen, um nahezulegen, dass die repräsentierten Elemente verschieden und/oder ähnlich sein könnten. Ein Element kann jedoch flexibel genug sein, um verschiedene Implementierungen aufzuweisen und mit einigen oder allen der hier gezeigten oder beschriebenen Systeme zu arbeiten. Die verschiedenen in den Figuren gezeigten Elemente können gleich oder verschieden sein. Welches als ein erstes Element bezeichnet und welches ein zweites Element genannt wird, ist willkürlich.
In der Beschreibung und in den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ zusammen mit ihren Ableitungen verwendet werden. Es sollte klargestellt werden, dass diese Begriffe nicht als Synonyme füreinander beabsichtigt sind. Stattdessen kann bei bestimmten Ausführungsformen „verbunden“ verwendet werden, um anzugeben, dass sich zwei oder mehr Elemente in direktem physikalischen oder elektrischen Kontakt miteinander befinden. „Gekoppelt“ kann bedeuten, dass sich zwei oder mehr Elemente in direktem physikalischen oder elektrischen Kontakt befinden. Allerdings kann „gekoppelt“ auch bedeuten, dass sich zwei oder mehr Elemente nicht in direktem Kontakt miteinander befinden, aber dennoch zusammenwirken oder miteinander interagieren.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Ein Verweis in der Beschreibung auf „eine Ausführungsform“, „(genau) eine Ausführungsform“ „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Charakteristik, das bzw. die in Verbindung mit den Ausführungsformen beschrieben wird, in wenigstens einigen Ausführungsformen, aber nicht notwendigerweise allen Ausführungsformen der Erfindungen enthalten ist. Die verschiedenen Erscheinungen von „einer Ausführungsform“, „(genau) einer Ausführungsform“ oder „einigen Ausführungsformen“ beziehen sich nicht notwendigerweise alle auf die gleichen Ausführungsformen.
Nicht alle hier beschriebenen und veranschaulichten Komponenten, Merkmale, Strukturen, Charakteristiken, usw. müssen in einer bestimmten Ausführungsform oder bestimmten Ausführungsformen enthalten sein. Falls die Spezifikation angibt, dass zum Beispiel eine Komponente, ein Merkmal, eine Struktur oder eine Charakteristik enthalten sein „kann“ oder „könnte“, muss diese bestimmte Komponente, das bestimmte Merkmal, die bestimmte Struktur oder die bestimmte Charakteristik nicht enthalten sein. Falls sich die Beschreibung oder der Anspruch auf „ein“ Element bezieht, bedeutet dies nicht, dass es nur eines von dem Element gibt. Falls sich die Beschreibung oder die Ansprüche auf „ein zusätzliches“ Element beziehen, schließt dies nicht aus, dass es mehr als eines des zusätzlichen Elements gibt.
Ein Algorithmus wird hier und allgemein als eine selbstkonsistente Sequenz von Vorgängen oder Operationen betrachtet, die zu einem angestrebten Ergebnis führt. Diese beinhalten physikalische Manipulationen physikalischer Größen. Üblicherweise, jedoch nicht notwendigerweise, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Es hat sich bisweilen, hauptsächlich aus Gründen der üblichen Verwendung, als zweckmäßig erwiesen, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen zu bezeichnen. Es sollte jedoch klargestellt werden, dass alle diese und ähnliche Begriffe den geeigneten physikalischen Größen zugeordnet werden sollen und lediglich auf diese Größen angewendete zweckmäßige Bezeichnungen sind.
Wie oben diskutiert, können verschiedene Aspekte der Ausführungsformen hier durch entsprechende Software- und/oder Firmwarekomponenten und -Anwendungen, wie zum Beispiel von einem eingebetteten Prozessor oder dergleichen ausgeführte Software und/oder Firmware, ermöglicht werden. Somit können Ausführungsformen dieser Erfindung als ein Softwareprogramm, Softwaremodule, Firmware und/oder verteilte Software, die auf einer Art von Prozessor, Verarbeitungskern oder eingebetteter Logik einer virtuellen Maschine, die auf einem Prozessor oder Kern läuft oder auf oder in einem computerlesbaren oder maschinenlesbaren nichtflüchtigen Speicherungsmedium anderweitig implementiert oder realisiert ist, verwendet werden oder diese unterstützen. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium beinhaltet jeglichen Mechanismus zur Speicherung oder zum Übertragen von Informationen in einer Form, die von einer Maschine (zum Beispiel einem Computer) gelesen werden kann. Zum Beispiel beinhaltet ein computerlesbares oder maschinenlesbares, nichtflüchtiges Speicherungsmedium einen beliebigen Mechanismus, der Informationen in einer Form bereitstellt (das heißt speichert und/oder überträgt), auf die ein Computer oder eine Rechnermaschine (zum Beispiel Rechnergerät, elektronisches System, usw.), wie zum Beispiel beschreibbare/nicht beschreibbare Medien (zum Beispiel Read-Only-Memory (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeicherungsmedien, optische Speicherungsmedien, Flash-Speichergeräte, usw.), zugreifen kann. Der Inhalt kann direkt ausführbar („Objekt-“ oder „ausführbare“ Form), Quellcode oder Differenzcode („Delta“- oder „Patch“-Code) sein. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium kann auch eine Speicherung oder eine Datenbank beinhalten, von der Inhalt heruntergeladen werden kann. Das computerlesbare oder maschinenlesbare nichtflüchtige Speicherungsmedium kann auch ein Gerät oder ein Produkt beinhalten, auf dem zum Zeitpunkt des Verkaufs oder der Lieferung Inhalt gespeichert ist. Somit kann das Liefern eines Geräts mit gespeichertem Inhalt oder das Anbieten von Inhalt zum Herunterladen über ein Kommunikationsmedium so verstanden werden, dass ein Herstellungsartikel bereitgestellt wird, der ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium mit solchem hier beschriebenen Inhalt umfasst.
Verschiedene Komponenten, die oben als Prozesse, Server oder Werkzeuge bezeichnet werden, können ein Mittel zum Ausführen der beschriebenen Funktionen sein. Die von verschiedenen hier beschriebenen Komponenten ausgeführten Operationen und Funktionen können durch Software implementiert werden, die auf einem Verarbeitungselement, über eingebettete Hardware oder dergleichen, oder einer beliebigen Kombination von Hardware und Software läuft. Solche Komponenten können als Softwaremodule, Hardwaremodule, Spezialhardware (zum Beispiel anwendungsspezifische Hardware, ASICs, DSPs, usw.), eingebettete Steuerungen, fest verdrahtete Schaltungen, Hardwarelogik, usw. implementiert werden. Softwareinhalt (zum Beispiel Daten, Anweisungen, Konfigurationsinformationen, usw.) können über einen Herstellungsartikel bereitgestellt werden, der ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium beinhaltet, das Inhalt bereitstellt, der Anweisungen darstellt, die ausgeführt werden können. Der Inhalt kann zur Folge haben, dass ein Computer verschiedene hier beschriebene Funktionen/Operationen durchführt.
Wie hier verwendet, kann eine Auflistung von durch den Ausdruck „wenigstens eines von“ verbundenen Gegenständen jegliche Kombination der aufgelisteten Begriffe bedeuten. Beispielsweise kann die Phrase „wenigstens eines von A, B oder C“ A; B; C; A und B; A und C; B und C oder A, B und C bedeuten.
Die obige Beschreibung veranschaulichter Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, soll nicht erschöpfend sein oder die Erfindung auf die offenbarten präzisen Formen beschränken. Obgleich spezielle Ausführungsformen und Beispiele für die Erfindung hier zu veranschaulichenden Zwecken beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Geltungsbereichs der Erfindung möglich, wie Fachleute auf dem betreffenden Gebiet erkennen werden.
Diese Modifikationen können angesichts der obigen ausführlichen Beschreibung an der Erfindung vorgenommen werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so ausgelegt werden, dass sie die Erfindung auf die bestimmten in der Beschreibung und den Zeichnungen offenbarten Ausführungsformen beschränken. Vielmehr soll der Geltungsbereich der Erfindung vollständig durch die folgenden Ansprüche bestimmt werden, die gemäß eingeführter Lehren für die Anspruchsinterpretation betrachtet werden sollen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62159932 [0001]

Claims

Vorrichtung, umfassend: eine erste Prozessorplatine, umfassend: einen ersten Prozessor; eine entweder in den ersten Prozessor eingebaute oder wirksam mit dem ersten Prozessor gekoppelte Grafikprozessoreinheit bzw. GPU; wirksam mit dem ersten Prozessor gekoppelten ersten Speicher; entweder in den ersten Prozessor oder die GPU eingebaute oder wirksam mit dem ersten Prozessor oder der GPU gekoppelte Anzeigeausgangsschaltkreise; eine kommunikativ mit den Anzeigeausgangsschaltkreisen gekoppelte Touchscreen-Anzeige; und nichtflüchtige Speicherung, in der erste Anweisungen gespeichert werden, die ein Android-Betriebssystem und mehrere Android-Anwendungen umfassen; eine kommunikativ mit der ersten Prozessorplatine gekoppelte zweite Prozessorplatine, umfassend: einen zweiten Prozessor; wirksam mit dem zweiten Prozessor gekoppelten zweiten Speicher; und nichtflüchtige Speicherung, in der zweite Anweisungen gespeichert werden, die ein Windows-Betriebssystem und mehrere Windows-Anwendungen umfassen, wobei beim Betrieb die Vorrichtung einem Benutzer ermöglicht, selektiv die mehreren Android-Anwendungen und die mehreren Windows-Anwendungen laufenzulassen, und wobei die mehreren Windows-Anwendungen auf der zweiten Prozessorplatine ausgeführt werden.
Vorrichtung nach Anspruch 1, wobei eine der Android-Anwendungen eine Android-Remote-Desktop-Client-Anwendung umfasst, wobei das Windows-Betriebssystem einen Remote-Desktop-Server umfasst und wobei der Remote-Desktop-Server und der Android-Remote-Desktop-Client einem Benutzer ermöglichen, über Benutzereingaben in die Touchscreen-Anzeige aus der Ferne Windows-Anwendungen auf der zweiten Prozessorplatine laufenzulassen.
Vorrichtung nach Anspruch 1 oder 2, wobei die erste Prozessorplatine ein Android-Grafik-Rendering-Subsystem umfasst, das die GPU umfasst, wobei die zweiten Anweisungen Software zum Implementieren eines nativen Grafikbefehlwerfers umfassen, die zweite Prozessorplatine dafür ausgelegt ist, native Grafikbefehle zu der ersten Prozessorplatine zu werfen und die ersten Anweisungen einen nativen Grafikbefehlsfänger umfassen, der dafür ausgelegt ist, die nativen Grafikbefehle von der ersten Prozessorplatine zu fangen und diese an das Android-Grafik-Rendering-Subsystem abzugeben.
Vorrichtung nach Anspruch 3, wobei die ersten Anweisungen einen Remote-Desktop-Client umfassen und die zweiten Anweisungen einen Remote-Desktop-Server umfassen und wobei der Remote-Desktop-Client dafür ausgelegt ist, über die Touchscreen-Anzeige getätigte Benutzereingaben zu erfassen und entsprechende Benutzereingabebefehle und/oder -ereignisse zu dem Remote-Desktop-Server weiterzuleiten.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die zweite Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, zu einem auf der ersten Prozessorplatine laufenden Fänger zu werfen, und der Fänger dafür ausgelegt ist, die DirectX-Befehle zu empfangen und sie in entsprechende OpenGL-Befehle umzusetzen.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die zweite Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, in native Android-Grafikbefehle umzusetzen, die OpenGL-Befehle umfassen, und die OpenGL-Befehle zu einem auf der ersten Prozessorplatine laufenden Android-Grafikfänger zu werfen, und der Android-Grafikfänger dafür ausgelegt ist, die OpenGL-Befehle an ein auf der ersten Prozessorplatine implementiertes Android-Grafiksubsystem abzugeben.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die erste Prozessorplatine über eine USB-Verbindung (Universal Serial Bus) mit der zweiten Prozessorplatine gekoppelt ist und wobei Daten über ein über die USB-Verbindung implementiertes Internetprotokoll (IP) zur Bildung einer IP/USB-Verbindung zwischen der ersten Prozessorplatine und der zweiten Prozessorplatine ausgetauscht werden.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Vorrichtung ein Android-Gerät umfasst, das ein Gehäuse umfasst, in dem sowohl die erste als auch die zweite Prozessorplatine installiert sind.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Vorrichtung ein Android-Gerät umfasst, das die erste Prozessorplatine enthält, die mit einem Backpack gekoppelt ist, das die zweite Prozessorplatine enthält, und wobei die erste Prozessorplatine in ein Gehäuse eingekapselt und Teil einer Datenverarbeitungskarte ist, die einen Verbinder umfasst, der dafür ausgelegt ist, mit einem passenden Verbinder an dem Backpack in Verbindung zu treten, um Installation der Datenverarbeitungskarte in dem Backpack zu ermöglichen.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die zweite Prozessorplatine Breiten- und Höhenabmessungen aufweist, die ungefähr die Größe einer Kreditkarte oder kleiner sind, und das Windows-Betriebssystem eine Vollversion eines Windows-Betriebssystems ist, die dafür ausgelegt ist, auf einem Desktop- oder Laptop-Computer implementiert zu werden.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die ersten Anweisungen einen Android-Grafikwerfer umfassen, der dafür ausgelegt ist, OpenGL-Befehle zu einem entfernten Anzeigegerät zu werfen, und wobei, wenn ein Benutzer eine Windows-Anwendung ausführt, das Anzeigen einer Anzeige der Windows-Anwendung auf dem entfernten Anzeigegerät ermöglicht wird.
Vorrichtung, umfassend: ein Backpack, das dafür ausgelegt ist, mit einem Android-Gerät gekoppelt zu werden, das einen ersten USB-Verbinder (Universal Serial Bus) umfasst, wobei das Backpack-Gehäuse einen zweiten USB-Verbinder umfasst, der dafür ausgelegt ist, mit dem ersten USB-Verbinder an dem Android-Gerät in Verbindung zu treten, wenn das Android-Gerät mit dem Backpack gekoppelt wird; eine kommunikativ mit dem zweiten USB-Verbinder in dem Backpack-Gehäuse gekoppelte Prozessorplatine, umfassend: einen Prozessor; wirksam mit dem Prozessor gekoppelten Speicher; und nichtflüchtige Speicherung, in der Anweisungen gespeichert sind, die ein Windows-Betriebssystem und mehrere Windows-Anwendungen umfassen, wobei im Betrieb, wenn das Android-Gerät mit dem Backpack gekoppelt ist, einem Benutzer des Android-Geräts ermöglicht wird, selektiv mehrere Android-Anwendungen auf dem Android-Gerät laufenzulassen und aus der Ferne die mehreren Windows-Anwendungen über das Android-Gerät laufenzulassen, und wobei die mehreren Windows-Anwendungen auf der Prozessorplatine ausgeführt werden.
Vorrichtung nach Anspruch 12, wobei das Android-Gerät eine Touchscreen-Anzeige aufweist und eine Android-Remote-Desktop-Client-Anwendung umfasst, wobei das Windows-Betriebssystem einen Remote-Desktop-Server umfasst und wobei der Remote-Desktop-Server und der Android-Remote-Desktop-Client einem Benutzer ermöglichen, aus der Ferne Windows-Anwendungen über Benutzereingaben in die Touchscreen-Anzeige auf der Prozessorplatine laufenzulassen.
Vorrichtung nach Anspruch 12 oder 13, wobei das Android-Gerät einen nativen Grafikfänger umfasst, wobei die Anweisungen Software zum Implementieren eines nativen Grafikbefehlwerfers umfassen und wobei die Prozessorplatine dafür ausgelegt ist, native Grafikbefehle zu dem Android-Gerät zu werfen.
Vorrichtung nach Anspruch 14, wobei das Android-Gerät einen Remote-Desktop-Client umfasst und die Anweisungen einen Remote-Desktop-Server umfassen und wobei der Remote-Desktop-Server dafür ausgelegt ist, durch den Remote-Desktop-Client erzeugte Benutzereingabebefehle und/oder -ereignisse zu empfangen und die Benutzereingabebefehle und/oder -ereignisse an das Windows-Betriebssystem abzugeben.
Vorrichtung nach einem der Ansprüche 12-15, wobei die Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, zu einem auf dem Android-Gerät laufenden Windows-Grafikfänger zu werfen.
Vorrichtung nach einem der Ansprüche 12-16, wobei die Prozessorplatine eine Datenverarbeitungskarte umfasst, die dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, in native Android-Grafikbefehle, die OpenGL-Befehle umfassen, umzusetzen und die OpenGL-Befehle zu einem auf dem Android-Gerät laufenden Android-Grafikfänger zu werfen.
Vorrichtung nach einem der Ansprüche 12-17, wobei Daten über ein über eine USB-Verbindung implementiertes Internetprotokoll (IP) zur Bildung einer IP/USB-Verbindung zwischen der Prozessorplatine und dem Android-Gerät ausgetauscht werden.
Vorrichtung nach einem der Ansprüche 12-18, wobei der Prozessor Ausführung von x86-Anweisungen unterstützt.
Vorrichtung nach einem der Ansprüche 12-19, wobei die Prozessorplatine Breiten- und Höhenabmessungen aufweist, die ungefähr die Größe einer Kreditkarte oder kleiner sind, und das Windows-Betriebssystem eine Vollversion eines Windows-Betriebssystems ist, die dafür ausgelegt ist, auf einem Desktop- oder Laptop-Computer implementiert zu werden.
Vorrichtung, umfassend: eine Prozessorplatine, umfassend: einen Prozessor; eine wirksam mit dem Prozessor gekoppelte USB-Schnittstelle (Universal Serial Bus); wirksam mit dem Prozessor gekoppelten Speicher; und nichtflüchtige Speicherung, in der Anweisungen gespeichert sind, die ein Windows-Betriebssystem und mehrere Windows-Anwendungen umfassen, wobei die USB-Schnittstelle der Prozessorplatine dafür ausgelegt ist, kommunikativ mit einem USB-Verbinder an einem Android-Gerät gekoppelt zu werden, und wobei im Betrieb, wenn der USB-Verbinder des Android-Geräts kommunikativ mit der USB-Schnittstelle der Prozessorplatine gekoppelt ist, einem Benutzer des Android-Geräts ermöglicht wird, aus der Ferne die mehreren Windows-Anwendungen über das Android-Gerät laufenzulassen, und wobei die mehreren Windows-Anwendungen auf der Prozessorplatine ausgeführt werden.
Vorrichtung nach Anspruch 21, wobei das Android-Gerät eine Touchscreen-Anzeige aufweist und eine Android-Remote-Desktop-Client-Anwendung umfasst, wobei das Windows-Betriebssystem einen Remote-Desktop-Server umfasst, wobei im Betrieb, wenn der USB-Verbinder des Android-Geräts kommunikativ mit der USB-Schnittstelle der Prozessorplatine gekoppelt ist, der Remote-Desktop-Server und der Android-Remote-Desktop-Client einem Benutzer ermöglichen, aus der Ferne Windows-Anwendungen über Benutzereingaben in die Touchscreen-Anzeige auf der Prozessorplatine laufenzulassen.
Vorrichtung nach Anspruch 21 oder 22, wobei das Android-Gerät einen nativen Grafikfänger umfasst, wobei die Anweisungen Software zum Implementieren eines nativen Grafikbefehlwerfers umfassen und wobei die Prozessorplatine dafür ausgelegt ist, native Grafikbefehle zu dem Android-Gerät zu werfen.
Vorrichtung nach Anspruch 23, wobei das Android-Gerät einen Remote-Desktop-Client umfasst und die Anweisungen einen Remote-Desktop-Server umfassen und wobei der Remote-Desktop-Server dafür ausgelegt ist, durch den Remote-Desktop-Client erzeugte Benutzereingabebefehle und/oder -ereignisse zu empfangen und die Benutzereingabebefehle und/oder -ereignisse an das Windows-Betriebssystem abzugeben.
Vorrichtung nach Anspruch 24, wobei das Android-Gerät einen Android-Grafikfänger umfasst und wobei die Prozessorplatine dafür ausgelegt ist, native Windows-Grafikbefehle, die DirectX-Befehle umfassen, in native Android-Grafikbefehle, die OpenGL-Befehle umfassen, umzusetzen und die OpenGL-Befehle im Betrieb, wenn der USB-Verbinder des Android-Geräts kommunikativ mit der USB-Schnittstelle der Prozessorplatine gekoppelt ist, zu dem Android-Grafikfänger zu werfen.