15.6 Zoll eingebettetes Android-Display für OEM-Projekte: RK3568, Kiosk und kundenspezifische Hardware

Ein 15,6-Zoll-Android-Touchscreen kann als Tablet, als integriertes Android-Display oder als Android-Panel-PC konfiguriert werden. Obwohl diese Produkte ähnliche Bildschirmgrößen und Android-Plattformen gemeinsam haben können, dienen sie unterschiedlichen Integrationsstufen. Diese Unterscheidung wird wichtig, wenn ein OEM-Projekt über die Anwendungsprüfung hinausgeht. Ein Gerät, das eine kontinuierliche Stromversorgung, einen dedizierten Anwendungsstart, angepasste Hardware, eine kontrollierte Android-Konfiguration und eine integrierte Installation benötigt, ist nicht mehr einfach nur ein Tablet mit einem anderen Gehäuse.

Wir haben kürzlich eine OEM-Anforderung eines in Norwegen ansässigen Systemintegrators bewertet, die diesen Übergang veranschaulicht.

Das Projekt erforderte ein 15,6-Zoll-RK3568-Android-Tablet mit 4 GB/32 GB, WLAN, Kiosk-Modus, ohne Kamera oder Mikrofon, einem Umgebungslichtsensor und integrierter Installation. Der Kunde wünschte sich außerdem eine Konfiguration ohne GMS-Anwendungen.

Die Anwendung war für ein Smart-Home-Tablet gedacht, aber die Anforderungen entsprachen nicht denen eines typischen Verbraucher-Tablets. Der Bildschirm musste als dedizierter Teil eines fertigen Produkts funktionieren, mit definiertem Softwareverhalten, einer projektspezifischen Hardwarekonfiguration und einer festen Installationsmethode.

Das führt zu einer nützlicheren Frage für OEM-Käufer: Wann muss ein fest installierter Android-Touchscreen über ein Standard-Tablet hinausgehen, und bedeutet das automatisch die Verwendung eines Panel-PCs?

Wenn ein Tablet nicht mehr der richtige Ausgangspunkt ist

Ein Tablet ist oft der effizienteste Weg, eine Android-Anwendung zu validieren. Es integriert bereits Display, Touch-Schnittstelle, Prozessor, Speicher, Massenspeicher, drahtlose Konnektivität, Gehäuse und Betriebssystem.

Für einen frühen Prototyp kann dies ein Vorteil sein. Der OEM kann die Anwendung testen, ohne unnötige Hardwareentwicklung betreiben zu müssen.

Die Situation ändert sich, wenn das Tablet selbst modifiziert werden muss.

Ein fest installiertes Produkt benötigt möglicherweise keine Batterie. Es benötigt möglicherweise eine kontinuierliche Stromversorgung und einen automatischen Anwendungsstart nach dem Booten. Die endgültige Stückliste erfordert möglicherweise keine Kamera oder kein Mikrofon. Ein projektspezifischer Sensor muss möglicherweise hinzugefügt werden, während das Gehäuse in eine bestimmte Wand- oder Panelstruktur passen muss. Solche festen Terminals existieren bereits in unserem Sortiment – das 14-Zoll-POE-Restaurant-Tablet zum Beispiel ist für den kontinuierlichen Betrieb auf der Theke ohne Batterie konzipiert.

Wenn mehrere dieser Anforderungen zusammen auftreten, wählt der OEM nicht mehr einfach ein fertiges Verbrauchergerät aus. Die Hardwareplattform selbst wird Teil des Produktdesigns.

Das macht ein Tablet nicht ungeeignet für feste Anwendungen. Ein Tablet kann sicherlich an der Wand montiert werden und eine Kiosk-Anwendung ausführen; unser 15,6-Zoll-POE-Wandmontage-Android-Tablet ist ein solches fest installiertes Gerät. Die Frage ist, ob der OEM die exakte Hardwarekonfiguration, das Softwareverhalten und die mechanische Integration erhalten kann, die für das fertige Produkt erforderlich sind, ohne das ursprüngliche Tablet-Design umgehen zu müssen.

Für das Projekt in Norwegen war dies der Punkt, an dem die Diskussion von der Suche nach einem geeigneten Tablet zur Definition einer dedizierten Android-Terminalkonfiguration überging.

Was eine 15,6-Zoll-Anforderung einem OEM sagt

Die 15,6-Zoll-Spezifikation ist wichtig, aber sie bestimmt nicht allein die Hardwarearchitektur.

Für ein fest installiertes interaktives Terminal bietet eine Größe von 15,6 Zoll mehr Schnittstellenfläche als ein Handheld-Gerät und bleibt gleichzeitig praktisch für die Integration in Wände, Schränke, Theken und andere Strukturen. Es kann daher Anwendungen aufnehmen, bei denen das Display an einem Ort bleibt und Benutzer aus normaler Raum- oder Stehdistanz damit interagieren.

Aber derselbe 15,6-Zoll-Bildschirm kann in sehr unterschiedlichen Produkten vorkommen.

Ein 15,6-Zoll-Android-Tablet-PC kann angebracht sein, wenn der OEM ein weitgehend vollständiges mobiles Computergerät wünscht. Ein 15,6-Zoll-integriertes Android-Display wird relevanter, wenn der Bildschirm in ein dediziertes Produkt mit angepasster Hardware oder Installationsanforderungen integriert wird. Ein 15,6-Zoll-Panel-PC wird relevanter, wenn das Terminal auch mit Industrieanlagen kommunizieren oder eine breitere I/O-Unterstützung bieten muss.

Die wichtige Unterscheidung ist daher: 15,6 Zoll definieren die Benutzeroberfläche; es definiert nicht die Architektur.

Für OEM-Projekte müssen die umgebende Software, Hardware und Installationsanforderungen berücksichtigt werden, bevor die Produktkategorie ausgewählt wird.

RK3568, Kiosk und kein GMS sind separate Konfigurationsentscheidungen

Die norwegische Anforderung kombiniert mehrere Spezifikationen, die leicht als eine generische Anfrage nach "Android-Anpassung" behandelt werden können. Sie sind tatsächlich unterschiedliche Teile des Systems.

Der RK3568 definiert die Computerplattform. 4 GB/32 GB definieren Speicher und Massenspeicher. WLAN bietet drahtlose Konnektivität. Kiosk-Modus definiert, wie die Anwendung präsentiert und gesteuert wird. Kamera, Mikrofon und Umgebungslichtsensor gehören zur Hardwarekonfiguration. Die Anforderung "Kein GMS" gehört zur Softwarekonfiguration und benötigt eine eigene Definition.

Eine einzelne Plattform kann sehr unterschiedliche Konfigurationen tragen: Hopestarmonitor liefert RK3568 auch in einem wandmontierten Display und einem Desktop-Kiosk-Tablet sowie 15,6-Zoll-Touchscreens.

Das ist wichtig, da ein Lieferant den richtigen Prozessor unterstützen kann, ohne unbedingt die erforderliche Softwarekonfiguration oder die Hardware-Stückliste zu unterstützen. Ebenso kann ein Lieferant Kiosk-Funktionalität bieten, während er wenig Flexibilität bei der zugrunde liegenden Hardware bietet.

Für einen OEM müssen die Anforderungen daher als ein System und nicht als unabhängige Produktspezifikationen überprüft werden.

Definition von "Kein GMS" richtig

"Kein GMS" kann in einer RFQ einfach klingen, beschreibt aber keine einzelne Implementierungsmethode.

Für die in diesem Fall diskutierte Konfiguration können GMS-Anwendungen auf der Software-/Anwendungskonfigurationsebene gemäß den Projektanforderungen entfernt werden. Dies sollte nicht als reine AOSP-Firmware-Build oder als Entfernung jeder Google-Komponente auf Firmware-Ebene dargestellt werden.

Diese Unterscheidung ist wichtig beim Vergleich von Lieferanten.

Wenn der OEM einfach eine Android-Umgebung ohne die Standard-GMS-Anwendungen benötigt, kann eine Software-Konfiguration ausreichend sein. Wenn das Projekt eine grundlegend andere Firmware-Architektur auf Basis eines reinen AOSP-Builds erfordert, sollte dies als separate Anforderung spezifiziert werden.

Die praktische Lektion ist, den Lieferanten zu fragen, was "Kein GMS" tatsächlich im gelieferten Software-Image bedeutet, anstatt die Phrase selbst als vollständige technische Spezifikation zu behandeln.

Kiosk-Modus wird wichtig, wenn das Gerät eine einzige Aufgabe hat

Der Kiosk-Modus ist eine weitere Anforderung, die die Art und Weise ändert, wie ein Android-Gerät bewertet werden sollte.

Ein Allzweck-Tablet ist dafür konzipiert, Zugriff auf Android-Anwendungen und Systemfunktionen zu bieten. Ein dediziertes Terminal hat normalerweise ein viel engeres Betriebsmodell:

Einschalten → Android-Boot → designierte APK wird gestartet → Benutzer bleibt innerhalb der beabsichtigten Anwendung – das Betriebsmodell, das wir in Einzweck-Terminals wie unserer Konferenzraum-Buchungs-Tablet-Serie entwickeln.

Die Beschaffungsfrage ist daher nicht einfach, ob der Kiosk-Modus verfügbar ist.

Der OEM muss das vollständige Verhalten verstehen. Was passiert nach einem Stromausfall? Startet die designierte Anwendung automatisch neu? Können Benutzer die Anwendung verlassen? Können unnötige Systemoberflächen erscheinen? Wie wird die APK des Kunden bereitgestellt und aktualisiert?

Diese Details sind wichtig, da das Android-Gerät nicht mehr als Allzweckcomputer verwendet wird. Sein Boot- und Anwendungsverhalten wird Teil des fertigen Produkts.

Für das hier diskutierte Projekt wurde der Kiosk-Modus daher als Teil des Betriebsverhaltens des Geräts und nicht als isoliertes Software-Feature behandelt.

Hardware-Anpassung ändert die Produktdefinition

Die Anforderung nach keiner Kamera, keinem Mikrofon und einem Umgebungslichtsensor ändert auch, wie das Projekt spezifiziert werden sollte.

Ein Verbraucher-Tablet hat normalerweise eine vordefinierte Stückliste. Wenn eine Anwendung die Kamera oder das Mikrofon nicht verwendet, können diese Komponenten physisch vorhanden sein, da sie Teil des Standardprodukts sind.

Eine OEM-Plattform kann stattdessen um die tatsächliche Anwendung herum konfiguriert werden.

Das Entfernen ungenutzter Komponenten kann helfen, die Hardware an die beabsichtigten Produktanforderungen anzupassen. Bei einer datenschutzsensiblen Anwendung kann der Ausschluss unnötiger Erfassungs-Hardware auch Teil des Produktdesigns sein.

Der Umgebungslichtsensor dient einem anderen Zweck. Bei einem fest installierten Display kann die Umgebungsbeleuchtung erheblich variieren. Ein Lichtsensor kann Umgebungsdaten für ein automatisches Helligkeitsverhalten liefern.

Für OEM-Projekte sind diese Anforderungen daher keine optionalen Features. Sie sind Teil der Hardwarekonfiguration, die vor der Produktion vereinbart werden muss.

Dies ist auch der Grund, warum die Stücklistenanpassung zusammen mit der Android-Plattform bewertet werden sollte, anstatt nachdem ein Standard-Tablet bereits ausgewählt wurde.

Integriertes Android-Display vs. Panel-PC: Schauen Sie auf die I/O vor dem Etikett

Die Unterscheidung zwischen einem Direkte Kommunikation mit externen Geräten und einem Android-Panel-PC wird oft zu breit als "Verbraucher vs. Industrie" beschrieben. Ein nützlicherer Ausgangspunkt ist die Rolle, die das Android-Gerät im System spielen soll.

Wenn der Touchscreen hauptsächlich eine Anwendung ausführt, Touch-Eingaben akzeptiert, sich mit einem Netzwerk verbindet und als dediziertes Terminal fungiert, kann ein integriertes Android-Display ausreichend sein.

Die Architektur wird eher Panel-PC-orientiert, wenn das Android-Terminal auch direkt mit externen Geräten kommunizieren muss. Dies kann Anforderungen wie RS232- oder RS485-Kommunikation, Ethernet-Verbindungen für die Geräteintegration, GPIO-Signale, SPS-Kommunikation oder breitere I/O-Anpassungen umfassen.

Zu diesem Zeitpunkt fungiert das Gerät nicht mehr nur als interaktiver Bildschirm. Es wird Teil der Computer- und Kommunikationsarchitektur des Geräts.

LCD-Touchscreen-Monitor-Serie zum Beispiel umfasst RS232-Modelle, die immer noch Monitore und keine Panel-PCs sind. Der Punkt ist, dass Geräteintegration und I/O-Anforderungen stärkere Architektursignale sind als Bildschirmgröße oder Installationsmethode allein.Diese Unterscheidung war für das norwegische Projekt relevant. Die Anforderung beinhaltete eine integrierte Installation und Hardwareanpassung, aber die beschriebene Anwendung erforderte nicht zwangsläufig SPS-Kommunikation, RS232/RS485 oder breitere industrielle I/O.

Die geeignetere Architektur war daher ein integriertes Android-Display oder ein dediziertes Android-Terminal, anstatt automatisch zu einem Panel-PC zu wechseln, nur weil das Gerät fest installiert war.

Die 15,6-Zoll-Entscheidung beginnt mit dem fertigen Produkt

Die norwegische Anforderung bietet eine nützliche Möglichkeit, die Architektur vom fertigen Produkt rückwärts zu betrachten.

Die Display-Anforderung war 15,6 Zoll. Die Computerplattform war RK3568 mit 4 GB/32 GB und WLAN. Die Software benötigte Kiosk-Verhalten und eine Konfiguration ohne GMS-Anwendungen. Die Hardwarekonfiguration war ebenfalls spezifisch: keine Kamera, kein Mikrofon und ein Umgebungslichtsensor. Die mechanische Anforderung war die integrierte Installation.

Zusammengenommen beschreiben diese Anforderungen etwas anderes als einen herkömmlichen Tablet-Kauf. Gleichzeitig rechtfertigen sie nicht automatisch einen Panel-PC.

Dies ist eine wichtige Unterscheidung für die OEM-Beschaffung: Feste Installation und Hardwareanpassung machen ein Projekt nicht automatisch industriell.

Wenn das Projekt später SPS-Kommunikation, industrielle I/O oder direkte Geräteintegration hinzufügt, kann die Architektur in Richtung eines

Android-Panel-PCs neu bewertet werden.Dieser Anforderungs-zuerst-Ansatz gibt einem OEM auch mehr Flexibilität bei der Zusammenarbeit mit einem Lieferanten. Anstatt von einer Katalogkategorie auszugehen und zu versuchen, das Projekt darin unterzubringen, kann der Käufer vom fertigen Produkt ausgehen und die Android-Plattform identifizieren, die es am besten unterstützt.

Was vor der Genehmigung der OEM-Plattform zu überprüfen ist

Sobald die Architektur identifiziert ist, wird die Lieferantenbewertung viel konkreter.

Die Android-Plattform sollte anhand des erforderlichen Prozessors, der Android-Version, des Speichers, des Massenspeichers und der drahtlosen Konfiguration überprüft werden. Die Softwareanforderungen sollten die tatsächliche GMS-Entfernungsmethode, den APK-Bereitstellungsprozess, das Kiosk-Verhalten, den automatischen Start und das Neustartverhalten spezifizieren.

Die Hardware-Stückliste sollte bestätigen, ob Kamera und Mikrofon ausgeschlossen werden können und ob der Umgebungslichtsensor in die vereinbarte Produktionskonfiguration integriert werden kann.

Die mechanische Integration sollte Abmessungen, Montagekonstruktion, Steckverbinderpositionen, Stromeingang und die Gehäuseschnittstelle abdecken. Wenn das Terminal an externe Geräte angeschlossen wird, sollten die erforderlichen RS232-, RS485-, Ethernet-, GPIO- oder anderen Schnittstellen definiert werden, bevor die Architektur finalisiert wird.

Diese Details sind auch dort, wo ein OEM-Projekt von einer Standardproduktkonfiguration zu einer angepassten Plattform übergehen kann. Je mehr Anforderungen, die Software-, Hardware- und mechanische Grenzen überschreiten, desto wichtiger wird es, dass der Lieferant diese Elemente als eine Produktionskonfiguration koordinieren kann.

Die letzte Frage ist die Produktionskonsistenz. Ein Lieferant, der einen Prototyp modifizieren kann, ist nicht unbedingt in der Lage, dasselbe Software-Image, dieselbe Hardware-Stückliste und dieselbe mechanische Konfiguration während der Massenproduktion beizubehalten. Der OEM sollte daher bestätigen, wie die validierte Konfiguration kontrolliert wird, wenn das Projekt von der Prototypenvalidierung zur Produktionsskalierung übergeht.

Eine bessere RFQ beginnt mit dem fertigen Produkt

Die effektivste RFQ für diese Art von Projekt beschreibt das beabsichtigte Gerät, anstatt nur ein Produktmodell anzufordern.

Anstatt nach einem "

15,6-Zoll-Android-Tablet mit RK3568" zu fragen, kann der OEM die Anforderungen so definieren, dass der Lieferant die vollständige Konfiguration bewerten kann.RFQ-Bereich

Es gibt dem Lieferanten auch genügend Informationen, um festzustellen, ob das Projekt über eine bestehende Plattformkonfiguration abgewickelt werden kann oder weitere Hardware- und Softwareanpassungen erfordert.

Für ein OEM-Projekt, das diesem Fall ähnelt, kann dieselbe Spezifikation als Ausgangspunkt für eine technische Diskussion mit unserem Team dienen. Die anfängliche RFQ muss nicht jedes technische Detail enthalten; der Anforderungssatz kann zuerst verwendet werden, um die geeignete Android-Architektur zu bestimmen und die Bereiche zu identifizieren, die weitere Bestätigung erfordern.

Haben Sie ein 15,6-Zoll-Android-OEM-Projekt?

Ein fest installierter Android-Touchscreen muss nicht automatisch zu einem Panel-PC werden, genauso wenig wie eine Wandmontage-Anwendung automatisch ein Tablet erfordert.

Der bessere Ausgangspunkt ist das fertige Produkt: Definieren Sie Bildschirmgröße, Prozessor, Speicher, Android-Konfiguration, Anwendungsverhalten, Hardware-Stückliste und Installationsmethode und bestimmen Sie dann, welche Architektur diese Anforderungen erfüllt. Produkte wie unser

15,6-Zoll-Smart-Home-Android-Tablet zeigen, wie weit ein fest installierter Android-Touchscreen vor der Produktion konfiguriert werden kann.Wenn auch die Kommunikation mit Industrieanlagen erforderlich ist, sollten Schnittstellen wie RS232, RS485, Ethernet oder GPIO von Anfang an einbezogen werden.

Wenn Ihr Projekt Anforderungen hat, die diesem Fall ähneln, können Sie

uns kontaktieren und die grundlegenden Informationen senden, damit die Architektur von den Anforderungen ausgehend bewertet werden kann. Unser Team kann beurteilen, ob ein integriertes Android-Display oder ein Android-Panel-PC besser geeignet ist, und identifizieren, welche Software-, Hardware- oder Installationselemente vor der Produktion angepasst werden müssen.Das Ziel ist nicht, ein OEM-Projekt in eine Produktkategorie zu zwingen, sondern die Android-Hardwarearchitektur an die tatsächlichen Anforderungen des fertigen Produkts anzupassen.