How to Compare Android TV Box OEM Quotations: What to Check Beyond Unit Price

Two Android TV box quotations may show a similar product and still cover different deliverables. A meaningful comparison starts by defining the purchasing requirement, then checking quotation scope, customization, sample approval, delivery conditions, warranty, and maintenance on the same basis.

1. Define the purchasing requirement first

Before asking for a quotation, describe the target market, sales channel, intended use, sample and expected order quantities, required timing, preferred configuration, accessories, packaging, software, branding, and evidence needed for the destination market.

The first inquiry does not need to be a full engineering specification. If a buyer has not selected a chipset, memory combination, wireless module, or software build, the answer can be “Not sure — supplier recommendation required.” The supplier can recommend a configuration and identify the points that must be confirmed before sampling.

Useful first-inquiry questions include:

• Where will the product be sold, and through which channel?
• What is the main use case and operating environment?
• How many samples, trial units, and bulk units are expected?
• Which hardware features and accessories are essential?
• What packaging, language, branding, and software changes are required?
• Which platform, service, or regulatory evidence is needed for the target market?
• What currency, delivery destination, and Incoterm should the quotation use?

Engineering details such as PCB revision, firmware identity, production-test program, and change-control records should be handled later, once a sample configuration is being evaluated.

2. Compare the quotation scope

Identify the base device by an exact model or SKU and an agreed configuration. Then compare whether each quotation covers:

• RAM and storage configuration;
• Wi-Fi/Bluetooth module and antennas;
• power adapter and plug;
• remote control and batteries;
• HDMI, AV, or other cables;
• retail box, inner tray, shipping carton, and labels;
• manuals, warranty documents, and technical documents;
• samples and sample shipping;
• freight, insurance, customs boundary, taxes, and duties;
• warranty, spare units, replacement handling, firmware maintenance, and issue fixes.

Use one of five statuses for every supplier and scope item:

• Included: expressly included in the supplier’s current quoted price and delivery scope.
• Extra cost: available, but outside the current base quotation. Record the amount, currency, charging method, and applicable quantity or period.
• Not offered / outside this supplier’s delivery scope: the supplier has explicitly stated that it will not deliver or take responsibility for the item.
• Not applicable: the confirmed project does not require the item.
• Unconfirmed: the buyer or supplier has not yet provided a clear answer.

These statuses are not interchangeable. “Not offered” describes the supplier’s scope. “Not applicable” describes the project requirement. “Extra cost” means the item may be supplied outside the base price. “Unconfirmed” means no conclusion has been reached. A blank cell should never be treated as included.

For each supplier, record the quotation basis separately: amount or price difference, currency, charging method, applicable quantity or validity period, and the quotation page, attachment, or written statement that supports the entry. If an accessory or service is already included in the base device price, mark it as included and do not add it again as a separate cost.

3. Separate customization from the base product

OEM/ODM work may include device logos, printing or labels, customized packaging, boot screens, launcher or user-interface changes, preloaded applications, store configuration, firmware engineering, or enclosure and tooling changes.

The quotation should identify whether each requested item is included, separately charged, not offered, not applicable, or unconfirmed. It should also identify whether a charge is:

• a one-time engineering or tooling charge;
• a per-unit charge;
• a recurring licence or service charge; or
• an estimate pending technical review.

Licensing, third-party testing, packaging changes, and ongoing software work should not be hidden inside a general statement such as “customization included.”

4. Separate first inquiry from sample approval

At the inquiry stage, the buyer needs enough information to compare viable configurations. At the sample stage, the parties need to record exactly what is being approved.

The sample baseline may include:

• sample ID or serial number;
• PCB and BOM versions;
• Android version, build ID, build fingerprint, and firmware image identity;
• launcher and application versions;
• accessories, packaging, labels, and documents;
• test plan, conditions, results, deviations, and approval status.

The purpose is to make later changes visible. Before bulk delivery, the buyer and supplier should know which component substitutions, hardware revisions, firmware changes, application changes, test-program revisions, or packaging changes require notification, retesting, or approval.

5. Check certification and service claims at the correct level

Android compatibility, Google commercial licensing, Play Protect certification status, Widevine integration or security level, support for a particular streaming service, and statutory market compliance are different questions. One claim should not be used as a substitute for another.

Where a claim affects purchasing, check the company or applicant, exact model or SKU, hardware version, firmware build, target market, date, document or record number, and permitted scope of disclosure. This is a purchasing-verification recommendation, not a claim that every platform officially requires the same record set. A chipset capability or generic Android version does not, by itself, prove a device-level licence, service approval, playback result, or market certification.

6. Compare warranty and maintenance on the same basis

Quotations should state what is covered by warranty, how spare or replacement units are handled, and whether firmware maintenance, OTA operation, issue investigation, or application updates are included, separately charged, not offered, or still unconfirmed.

The final comparison should also align currency, quotation validity, Incoterm and named place, freight, insurance, customs responsibility, taxes, duties, and exclusions. A low unit price can be misleading if another quotation includes items that are missing from it.

Illustrative example 1: Same product label, different delivery scope

Illustration only — not a real H96 customer, supplier, or quotation.

Quotation A identifies a model and memory configuration and states that the power adapter, remote control, batteries, and HDMI cable are included. Quotation B uses the same product-family name but does not identify RAM/storage and does not state whether the adapter or cable is included.

Why they cannot be compared directly: the model label does not establish the same hardware configuration or accessory scope.

What is missing: exact SKU, RAM/storage, wireless module if relevant, plug type, accessory list, packaging, and the basis of the quoted unit.

Questions to ask:

• Which exact configuration does each quotation cover?
• Are the adapter, plug, remote control, batteries, and cables included?
• If an item is extra cost, what are the amount, currency, unit, and applicable quantity?
• Which quotation page or attachment confirms the answer?

Illustrative example 2: “Customization included” without a defined boundary

Illustration only — not a real H96 customer, supplier, or quotation.

Quotation A says “customization included” but does not define whether this covers the boot screen, launcher, preloaded applications, firmware engineering, testing, third-party licences, or post-delivery maintenance. Quotation B marks firmware customization as extra cost but has not confirmed service licensing or the maintenance period.

Why they cannot be compared directly: the quotations use different boundaries for customization, licensing, and ongoing support.

What is missing: deliverables, one-time versus recurring charges, build and sample-approval criteria, third-party responsibilities, maintenance duration, and change-request treatment.

Questions to ask:

• Which customization deliverables are included in the base quotation?
• Which items are extra cost, and how are they charged?
• Which items are not offered by the supplier?
• Which licence or service statements apply to the exact model, build, region, and application version?
• What will be recorded at sample approval, and what changes require later approval?

How to use the companion worksheet

1. Define the requirement: complete the 12 Initial RFQ questions with confirmed information or “Not sure — supplier recommendation required.”
2. Record each supplier separately: for every comparison item, enter the supplier’s status, amount, currency, charging method, quantity or period, and quotation basis.
3. Flag differences: identify different configurations, missing accessories, exclusions, conditional charges, and unconfirmed claims.
4. Prepare follow-up questions: ask for the exact document, quotation line, model/build scope, or commercial condition needed to resolve each difference.

The current English template has not yet been completed with a real procurement project and is not presented as an industry standard.

Companion worksheet

Use the RFQ template with your next supplier comparison

Download the English worksheet, record each supplier separately, and turn unclear scope into follow-up questions.

Download the English RFQ Template
Submit Your Project Requirements

Method, scope, and evidence limits

This chapter provides a quotation-comparison method. It does not state H96 prices, MOQ, lead times, certifications, warranties, maintenance periods, or standard commercial terms. Those points must come from the quotation, contract, and model-level evidence for the actual project.

The sources below support specific parts of the method within their stated scope:

1. Request for Quotation — Georgian Digital Terrestrial Television Set-top Box Procurement (14 May 2014): official public PDF. The document covers test devices, quoted deliverables, modifications, acceptance, packaging, quality records, certificates, and quotation attachments. It is a historical Georgian DTT project used only as an example of explicit RFQ scope. It is not a current Android TV box industry standard.
2. U.S. Federal Acquisition Regulation, Part 9, Subpart 9.3 — First Article Testing and Approval: acquisition.gov/far/part-9. Used only as a reference for connecting an approved first article, test requirements, report data, contract quantity, and later changes. It does not automatically apply to commercial Android TV box orders.
3. FAR 52.209-3 — First Article Approval—Contractor Testing: acquisition.gov/far/52.209-3. Used only as a change-and-approval mechanism reference, not as H96 contract language or a consumer-electronics quality standard.
4. Android Compatibility FAQ: source.android.com/docs/compatibility/compatibility-faq. Used to distinguish Android compatibility from Google Play/GMS licensing. It does not prove any specific model or build is licensed.
5. Google Play Help — Check and fix Play Protect certification status: support.google.com/googleplay/answer/7165974. Used to describe device-level status checking. A screenshot does not prove all batches or future builds.
6. Widevine — Access and Device Integration: developers.google.com/widevine/access. Explains Widevine partner access, licensing agreements and the OEMCrypto dependency for Level 1 device integration. It does not verify any H96 device, firmware build or streaming-service support.
7. EU Radio Equipment Directive 2014/53/EU: EUR-Lex, and EU guidance on preparing technical documentation: Your Europe. Used to explain why the responsible entity, product identity, applicable rules, standards, risk assessment, labels, instructions, and evidence scope must be checked for the actual product and market. This chapter is not legal advice.
8. AOSP — Build OTA packages: source.android.com/docs/core/ota/tools, and Sign builds for release: source.android.com/docs/core/ota/sign_builds. Used to support recording non-sensitive build identity and release metadata. They do not prove that a product implements incremental OTA, A/B updates, rollback, or long-term maintenance.

Verification boundary: the linked sources were checked for accessibility and the cited methodological scope on 2026-09-23. No H96-specific commercial, certification, licence, warranty, lead-time, or maintenance claim was validated by these general sources.