15.6 inch Embedded Android Display for OEM Projects: RK3568, Kiosk and Custom Hardware

A 15.6-inch Android touchscreen can be built as a tablet, an embedded Android display, or an Android Panel PC. Although these products may share similar screen sizes and Android platforms, they serve different levels of product integration. This distinction becomes important when an OEM project moves beyond application testing. A device that needs continuous power, dedicated application startup, customized hardware, a controlled Android configuration, and embedded installation is no longer simply a tablet with a different enclosure.

We recently evaluated an OEM requirement from a Norway-based system integrator that illustrates this transition

The project called for a 15.6-inch RK3568 android tablet with 4GB/32GB, WiFi, Kiosk Mode, no camera or microphone, an ambient light sensor, and embedded installation. The customer also requested a configuration without GMS applications.

The application was intended for a smart home tablet, but the requirements were not those of a typical consumer tablet. The screen needed to function as a dedicated part of a finished product, with defined software behavior, a project-specific hardware configuration, and a fixed installation method.

That leads to a more useful question for OEM buyers: When does a fixed Android touchscreen need to move beyond a standard tablet, and does that automatically mean using a Panel PC?

When a Tablet Stops Being the Right Starting Point

A tablet is often the most efficient way to validate an Android application. It already integrates the display, touch interface, processor, memory, storage, wireless connectivity, enclosure and operating system.

For an early prototype, this can be an advantage. The OEM can test the application without taking on unnecessary hardware development.

The situation changes when the tablet itself needs to be modified.

A fixed product may not need a battery. It may need continuous power and automatic application startup after boot. The final BOM may not require a camera or microphone. A project-specific sensor may need to be added, while the enclosure may need to fit a particular wall or panel structure. Fixed terminals of this kind already exist in our range — the 14 inch POE restaurant tablet, for example, is engineered without a battery for continuous countertop operation.

When several of these requirements appear together, the OEM is no longer simply selecting a finished consumer device. The hardware platform itself becomes part of the product design.

That does not make a tablet unsuitable for fixed applications. A tablet can certainly be wall-mounted and can run a kiosk application; our 15.6 inch POE wall mounted android tablet is one such permanently installed device. The question is whether the OEM can obtain the exact hardware configuration, software behavior and mechanical integration required for the finished product without working around the original tablet design.

For the Norway project, this was the point at which the discussion moved from finding a suitable tablet toward defining a dedicated Android terminal configuration.

What a 15.6-Inch Requirement Tells an OEM

The 15.6-inch specification is important, but it does not determine the hardware architecture by itself.

For a fixed interactive terminal, 15.6 inches provides more interface area than a handheld device while remaining practical for integration into walls, cabinets, counters and other structures. It can therefore fit applications where the display remains in one location and users interact with it from a normal room or standing distance.

But the same 15.6-inch screen can appear in very different products.

A 15.6-inch android tablet PC may be appropriate when the OEM wants a largely complete mobile computing device. A 15.6-inch embedded Android display becomes more relevant when the screen is being integrated into a dedicated product with customized hardware or installation requirements. A 15.6-inch Panel PC becomes more relevant when the terminal also needs to communicate with industrial equipment or provide broader I/O.

The important distinction is therefore: 15.6 inches defines the user interface; it does not define the architecture.

For OEM projects, the surrounding software, hardware and installation requirements need to be considered before selecting the product category.

RK3568, Kiosk and No GMS Are Separate Configuration Decisions

The Norway requirement combines several specifications that can easily be treated as one generic “Android customization” request. They are actually different parts of the system.

The RK3568 defines the computing platform. 4GB/32GB defines memory and storage. WiFi provides wireless connectivity. Kiosk Mode defines how the application is presented and controlled. The camera, microphone and ambient light sensor belong to the hardware configuration. The No GMS requirement belongs to the software configuration and needs its own definition.

A single platform can carry very different configurations: Hopestarmonitor also ships RK3568 in a wall-mounted display and a desktop kiosk tablet as well as 15.6-inch touchscreens.

This matters because a supplier can support the correct processor without necessarily supporting the required software configuration or hardware BOM. Similarly, a supplier may provide Kiosk functionality while offering little flexibility in the underlying hardware.

For an OEM, the requirements therefore need to be reviewed as one system rather than as independent product specifications.

Defining “No GMS” Correctly

“No GMS” can sound straightforward in an RFQ, but it does not describe a single implementation method.

For the configuration discussed in this case, GMS applications can be removed at the software/application configuration layer according to the project requirement. This should not be represented as a pure AOSP firmware build or as firmware-level removal of every Google component.

That distinction is important when comparing suppliers.

If the OEM simply requires an Android environment without the standard GMS applications, software-level configuration may be sufficient. If the project requires a fundamentally different firmware architecture based on a pure AOSP build, that should be specified as a separate requirement.

The practical lesson is to ask the supplier what “No GMS” actually means in the delivered software image rather than treating the phrase itself as a complete technical specification.

Kiosk Mode Becomes Important When the Device Has a Single Job

Kiosk Mode is another requirement that changes the way an Android device should be evaluated.

A general-purpose tablet is designed to provide access to Android applications and system functions. A dedicated terminal normally has a much narrower operating model:

Power on → Android boot → designated APK launches → user remains inside the intended application — the operating model we engineer into single-purpose terminals such as our conference room booking tablet range.

The procurement question is therefore not simply whether Kiosk Mode is available.

The OEM needs to understand the complete behavior. What happens after a power interruption? Does the designated application restart automatically? Can users exit the application? Can unnecessary system interfaces appear? How is the customer’s APK deployed and updated?

These details matter because the Android device is no longer being used as a general-purpose computer. Its boot and application behavior become part of the finished product.

For the project discussed here, Kiosk Mode was therefore treated as part of the device’s operating behavior rather than as an isolated software feature.

Hardware Customization Changes the Product Definition

The request for no camera, no microphone and an ambient light sensor also changes how the project should be specified.

A consumer tablet normally has a predefined BOM. If an application does not use the camera or microphone, those components may still be physically present because they are part of the standard product.

An OEM platform can instead be configured around the actual application.

Removing unused components can help align the hardware with the intended product requirements. In a privacy-sensitive application, excluding unnecessary capture hardware can also be part of the product design.

The ambient light sensor serves a different purpose. In a permanently installed display, surrounding illumination can vary considerably. A light sensor can provide environmental input for automatic brightness behavior.

For OEM projects, these requirements are therefore not simply optional features. They are part of the hardware configuration that needs to be agreed before production.

This is also why BOM customization should be evaluated together with the Android platform rather than after a standard tablet has already been selected.

Embedded Android Display vs. Panel PC: Look at the I/O Before the Label

The distinction between an Embedded Android Display and an Android Panel PC is often described too broadly as “consumer versus industrial.” A more useful starting point is the role the Android device needs to play in the system.

If the touchscreen mainly runs an application, accepts touch input, connects to a network and operates as a dedicated terminal, an embedded Android display may be sufficient.

The architecture becomes more Panel PC-oriented when the Android terminal also needs to communicate directly with external equipment. That can include requirements such as RS232 or RS485 communication, Ethernet connections for equipment integration, GPIO signals, PLC communication or broader I/O customization.

At that point, the device is no longer functioning only as an interactive screen. It becomes part of the equipment’s computing and communication architecture.

This does not mean that every device with RS232 or Ethernet must be a Panel PC; our LCD touch screen monitor range, for instance, includes RS232 models that are still monitors rather than panel PCs. The point is that equipment integration and I/O requirements are stronger architectural signals than screen size or installation method alone.

That distinction was relevant to the Norway project. The requirement called for embedded installation and hardware customization, but the described application did not inherently require PLC communication, RS232/RS485 or broader industrial I/O.

The more appropriate architecture was therefore an embedded Android display or dedicated Android terminal rather than automatically moving to a Panel PC simply because the device was permanently installed.

The 15.6-Inch Decision Starts With the Finished Product

The Norway requirement provides a useful way to approach the architecture from the finished product backward.

The display requirement was 15.6 inches. The computing platform was RK3568 with 4GB/32GB and WiFi. The software needed Kiosk behavior and a configuration without GMS applications. The hardware configuration was also specific: no camera, no microphone and an ambient light sensor. The mechanical requirement was embedded installation.

Taken together, these requirements describe something different from a conventional tablet purchase. At the same time, they do not automatically justify a Panel PC.

This is an important distinction for OEM procurement: fixed installation and hardware customization do not by themselves make a project industrial.

If the project later adds PLC communication, industrial I/O or direct equipment integration, the architecture can be reassessed toward an Android Panel PC.

This requirement-first approach also gives an OEM more flexibility when working with a supplier. Instead of starting with a catalogue category and trying to fit the project into it, the buyer can start with the finished product and identify the Android platform that best supports it.

What to Verify Before Approving the OEM Platform

Once the architecture has been identified, supplier evaluation becomes much more concrete.

The Android platform should be verified against the required processor, Android version, memory, storage and wireless configuration. Software requirements should specify the actual GMS-removal method, APK deployment process, Kiosk behavior, automatic startup and reboot behavior.

The hardware BOM should confirm whether the camera and microphone can be excluded and whether the ambient light sensor can be incorporated into the agreed production configuration.

Mechanical integration should cover dimensions, mounting structure, connector locations, power input and the enclosure interface. If the terminal connects to external equipment, the required RS232, RS485, Ethernet, GPIO or other interfaces should be defined before the architecture is finalized.

These details are also where an OEM project can move from a standard product configuration toward a customized platform. The more requirements that cross software, hardware and mechanical boundaries, the more important it becomes that the supplier can coordinate those elements as one production configuration.

The final question is production consistency. A supplier that can modify a prototype is not necessarily able to maintain the same software image, hardware BOM and mechanical configuration throughout volume production. The OEM should therefore confirm how the validated configuration will be controlled when the project moves from prototype validation to production scaling.

A Better RFQ Starts With the Finished Product

The most effective RFQ for this type of project describes the intended device rather than only requesting a product model.

Instead of asking for a “15.6-inch Android tablet with RK3568,” the OEM can define the requirements in a way that allows the supplier to evaluate the complete configuration.

This format makes supplier responses easier to compare because it separates the display requirement from the computing platform, software behavior, hardware BOM and mechanical integration.

It also gives the supplier enough information to determine whether the project can be handled through an existing platform configuration or requires further hardware and software customization.

For an OEM project similar to this case, the same specification can serve as the starting point for a technical discussion with our team. The initial RFQ does not need to contain every engineering detail; the requirement set can first be used to determine the appropriate Android architecture and identify the areas that need further confirmation.

Have a 15.6-Inch Android OEM Project?

A fixed Android touchscreen does not automatically need to become a Panel PC, just as a wall-mounted application does not automatically require a tablet.

The better starting point is the finished product: define the screen size, processor, memory, Android configuration, application behavior, hardware BOM and installation method, then determine which architecture fits those requirements. Products such as our 15.6 inch smart home android tablet show how far a fixed Android touchscreen can be configured before production.

If industrial equipment communication is also required, interfaces such as RS232, RS485, Ethernet or GPIO should be included from the beginning.

If your project has requirements similar to this case, you can send us the basic RFQ information and let the architecture be evaluated from the requirements outward. Our team can assess whether an embedded Android display or Android Panel PC is more appropriate and identify which software, hardware or installation elements need customization before production.

The objective is not to force an OEM project into one product category, but to match the Android hardware architecture to the way the finished product actually needs to work.