A run you can trust
Host, device preparation, retries and incomplete modules are checked before any product defect is called.
Compatibility Test Suite
CTS testing,
as a service.
Send the device and the agreed build. B8N runs Android CTS, cuts through the noise and returns an engineer-reviewed account of what failed, why it matters and who should look at it next.
See what is included ↓01 WHAT YOU RECEIVE
More than a folder of
raw results.
A pass or fail total is not an engineering answer. The report ties each persistent failure to evidence, groups related tests into real problems, and keeps two things it never blurs: how sure a conclusion is, and how far the evidence has actually reached.
Grouped, not listed
Dozens of test methods become a smaller set of traceable engineering issues, with cascades separated from causes.
A responsible label
Every persistent failure is placed in one of seven ownership classes, from device configuration through to investigation required.
How far it reaches
A fixed ladder: subsystem, interface, cause, candidate defect, then a fix validated by re-test. The claim never runs ahead of the rung it has reached.
How sure it is
A separate dimension, from confirmed to unknown. A finding can pin the subsystem with confidence while the precise cause stays open.
Your original results
Raw CTS output, run identifiers and build context stay with you, for your own records and your own engineers.
A clear route forward
Each family names likely ownership and whether to configure, retest, investigate, escalate or ask the ODM to fix it.
02 CLASSIFICATION
Every failure gets a
responsible label.
One canonical set of seven classes, the same on the page, in the report and in the framework. Investigation required is an honest label, not a dead end; it is where deeper work can begin.
Device configuration
Properties, permissions, packages, overlays, features or manifests that do not match the required state.
Test environment
Host, USB, network, service or peripheral conditions, or a missing account, SIM or test medium, that affect a credible result.
Framework or system implementation
Framework or system integration that diverges from the API, the CDD or expected behaviour.
Vendor, BSP or HAL
Evidence reaches a hardware-specific boundary. Specialist review may be needed before a source-level cause is claimed.
Known CTS issue
A recognised test limitation or upstream suite issue, supported by credible version-specific evidence.
Intermittent or not currently reproducible
The result changes on controlled retry and no stable product defect has yet been established.
Investigation required
The evidence is not yet enough for a responsible cause. What is known, and what to do next, are reported; this is where a paid investigation picks up.
03 HOW IT WORKS
One build.
Four clear stages.
The engagement is deliberately small at the front door. It can end with a useful report, or continue into focused engineering when a failure genuinely needs it.
Scope
Agree the device, build, CTS release, test plan, prerequisites and what a comparable repeat build looks like.
Run
Prepare the device, execute CTS, protect test integrity and run controlled retries where they add evidence.
Interpret
Normalise, classify and trace persistent failures. Separate observed fact from inference and hypothesis.
Report
Deliver the raw artefacts, an engineer-reviewed report and a prioritised route to retest, investigate or remediate.
01 Scope02 Run03 Interpret04 Report
04 WHAT THIS IS, AND IS NOT
Clear about where
it stops.
B8N is an independent party: a separate resource that assesses the build, rather than the team that designed or built the device checking its own work. The value is that outside, interpreted read. The service is deliberately bounded, and the limits are stated up front so the fixed-fee report stays exactly that.
B8N is not an authorised Google certification laboratory. This service runs Android CTS and interprets the result; it does not promise GMS approval, or guarantee that a build will pass certification. Certification testing, certification readiness and formal certification are different things.
Not included
- Open-ended source review
- BSP, HAL, kernel or vendor debugging
- Patch development or fix implementation
- Changes to your or a supplier's source
- Extended reproducer development
- Formal certification or GMS approval
Shipping can be arranged for a fee. Otherwise customers are responsible for sending and collecting hardware for the period of the engagement.
05 ENGAGEMENT & PRICING
Test first.
Investigate only where needed.
Start with a fixed-fee test and report. Go deeper only where a failure genuinely calls for it, and validate the fix when it lands.
£595per device and build
CTS test & failure report
The fixed-fee starting point for an agreed device and build.
- CTS execution and run-integrity checks
- Retries where appropriate
- Failure grouping and classification
- Evidence, depth and confidence assessment
- Engineer review
- Original test artefacts
£600per half-day
Engineering investigation
Against a defined failure or engineering question.
- Focused diagnostics and logs
- AOSP and interface tracing
- Configuration or source analysis
- Evidence-backed likely cause
- A remediation path
£395per build
Repeat-build validation
For a comparable follow-on build and test conditions.
- Agreed rerun coverage
- Finding-by-finding status
- Build-to-build failure delta
- New regression identification
- Updated evidence pack
Know what is failing.
Know what happens next.
Send the device model, Android version, target build, intended market, CTS version if known and any deadline already in motion.