As an open source platform, Android is customizable by design. This comes with advantages and disadvantages. The advantage is that custom Android products can be designed with flexibility to support countless applications. The disadvantage is that customization leads to inconsistency in specs and performance. Google manages the tradeoff by providing a readily available testing platform, the Android Compatibility Test Suite (CTS), that serves to ensure the core functionality of Android devices meet a standardized set of operational protocols. This means that whatever a custom Android device is used for, apps will all perform with consistency and as intended.

The CTS is a cornerstone of the Android ecosystem. Passing CTS is a prerequisite of obtaining the Google Mobile Services (GMS) certification, the required certificate for embedding Google’s apps into Android devices, but can also be run on non-GMS devices. Passing CTS is critical for aligning the multitude of developers and manufacturers that build custom Android hardware as it provides a robust framework for validating device quality, stability, and consistency. This article explains what CTS is, how it works, and why it is invaluable for testing custom Android hardware, regardless of whether they eventually get GMS certification or not.

What is Android CTS?

The Android Compatibility Test Suite (CTS) is a free, commercial-grade set of software tools and automated tests used to verify that Android devices meet compatibility standards defined by Google. The suite is intended for integration into the daily workflow of engineers and can be executed on a desktop machine, directing tests to attached devices or emulators. CTS is built to reveal incompatibilities early in the development process, ensuring that Android implementations remain compatible throughout the product lifecycle.

Key Components of CTS

• Trade Federation: A test harness and framework enabling automated execution of tests.
  
• CTS Automated Tests: Unit and functional tests that run using the Trade Federation framework.
  
• CTS Verifier (CTS-V): A set of manual tests (and an accompanying app) for features requiring human interaction, such as sensors, audio, and camera functions.
  
• Test Cases: Individual tests (usually JUnit-based, packaged as APKs) executed on the Device Under Test (DUT).
  
• Test Plans and Modules: Collections of test cases organized by feature area or specific use cases.
  

How Does CTS Work?

The workflow for running CTS is straightforward but rigorous:

1. Download and Install CTS: The test environment is set up on a workstation, and the device to be tested is connected.
   
2. Run Automated Tests: The CTS harness pushes test APKs to the device, executes them, and collects results.
   
3. Review and Troubleshoot: Results are stored, reviewed, and analyzed. Failed tests may be rerun or debugged as needed.
   
4. Iterate: The process is repeated throughout development to maintain compatibility and quality.
   

CTS automated tests cover a wide range of Android APIs and core platform features. They include unit tests (testing atomic code units), functional tests (combining APIs for real-world scenarios), robustness tests (system stress), and performance tests (benchmarking). The CTS Verifier app handles manual tests for features that cannot be automated, such as accelerometer or audio quality checks.

Why CTS is Essential for Custom Android Hardware Ensuring Platform Compatibility

Custom Android hardware—whether built for enterprise, industrial, or specialized consumer use—must still adhere to Android’s core standards to ensure reliable operation and compatibility with third-party applications. CTS provides a standardized benchmark for this compatibility, regardless of whether the device ships with GMS. By running CTS, manufacturers can identify and resolve issues early, reducing the risk of software bugs and incompatibilities that could undermine device performance or user experience.

Benefits for Non-GMS Android Hardware

Non-GMS Android hardware refers to devices that do not include Google Mobile Services—meaning they lack access to Google Play, Gmail, Maps, and other proprietary Google apps and Google’s APIs. Such devices are often deployed in closed environments, for specialized use cases (e.g., kiosks, digital signage, industrial controllers), or in regions where Google services are restricted.

Even without GMS, these devices must still run Android applications reliably, and CTS is the best tool to ensure this. Here’s why:

• API Consistency: CTS verifies that the device’s implementation of Android APIs matches the standard, so third-party apps (including those not reliant on GMS) will function as expected.
  
• Quality Assurance: CTS includes robustness and performance tests, helping to ensure that custom hardware is stable and efficient under various conditions.
  
• Future-Proofing: As Android evolves, CTS tests are updated to reflect new API requirements and best practices. Running CTS helps ensure that custom hardware remains compatible with future Android releases.
  

Flexibility and Control

For non-GMS and custom Android hardware, manufacturers have greater flexibility in provisioning, deploying, and updating devices. However, this flexibility also means taking on more responsibility for quality assurance. CTS provides a standardized, repeatable process for validating device software, reducing the risk of fragmentation and incompatibility that can plague custom Android implementations.

Integration with Development Workflows

CTS is designed to be integrated into continuous integration (CI) systems, allowing for automated, ongoing testing throughout the development lifecycle. This integration is especially valuable for custom hardware projects, where rapid iteration and validation are critical to meeting project timelines and quality goals.

CTS in Practice: Testing Non-GMS and Custom Hardware Setting Up and Running CTS

To run CTS on custom Android hardware (with or without GMS), follow these general steps:

1. Prepare the Environment: Install the required dependencies (Java, Python, ADB, AAPT) and download the appropriate CTS package for your Android version.
   
2. Connect the Device: Enable USB debugging and developer mode on the device.
   
3. Run CTS: Launch the CTS console and execute the desired test plan. For large test suites, consider using test sharding to distribute tests across multiple devices and reduce execution time.
   
4. Review Results: Analyze test results, rerun failed tests, and debug issues as needed.
   

Addressing Non-GMS Specifics

Since non-GMS devices do not include Google’s proprietary apps and services, some CTS tests that rely on GMS may fail or be irrelevant. However, the vast majority of CTS tests focus on core Android APIs and platform features, which are still critical for any custom hardware. Manufacturers can exclude GMS-specific tests or focus on the modules most relevant to their device’s use case.

Custom Test Plans

CTS allows for the creation of custom test plans, enabling manufacturers to focus on the specific features and APIs relevant to their hardware. This targeted approach saves time and ensures that testing resources are allocated efficiently.

The Broader Impact of CTS on the Android Ecosystem

CTS is more than just a tool for individual manufacturers. It is a key mechanism for maintaining consistency and quality across the diverse Android ecosystem. By requiring devices to pass CTS (and related suites like VTS for hardware abstraction and GTS for GMS compatibility), Google ensures that users and developers can rely on a consistent experience, regardless of the hardware or software customization.

For non-GMS and custom Android hardware, passing CTS is not a strict requirement (since GMS certification is not needed), but it remains the best practice for ensuring device quality and compatibility. Manufacturers who invest in CTS testing demonstrate a commitment to quality and are better positioned to succeed in competitive markets.

Conclusion

The Android Compatibility Test Suite (CTS) is an indispensable tool for anyone developing custom Android hardware—including non-GMS devices. By providing a comprehensive, standardized framework for testing Android compatibility, CTS helps manufacturers ensure that their products are stable, reliable, and compatible with the broader Android ecosystem. Even without Google Mobile Services, CTS remains the gold standard for quality assurance in custom Android hardware, enabling manufacturers to deliver high-quality products that meet both user expectations and industry standards.

Key Takeaways

• CTS is a free, commercial-grade test suite for verifying Android compatibility.
  
• It is essential for custom Android hardware, including non-GMS devices.
  
• CTS ensures API consistency, quality, and future-proofing for custom hardware.
  
• The suite is flexible, allowing for targeted testing and integration into development workflows.
  
• Even without GMS, CTS is the best tool for validating the quality and compatibility of custom Android hardware.
  

For manufacturers of non-GMS Android hardware and custom Android solutions, investing in CTS testing is a strategic decision that pays dividends in product quality, user satisfaction, and market success.

At Hatch, we manufacture custom Android hardware that adapts to a wide range of industries and applications. The Android platform’s open architecture and flexibility enable us to design custom Android tablets tailored to meet unique operational requirements. In this article, we highlight two diverse examples that showcase how custom Android tablets can be engineered to deliver exceptional value, functionality, and reliability across vastly different environments.

Custom Android Tablet for Laboratory and Product Inspection

One of the most compelling justifications for making a custom Android tablet is to facilitate the delivery of a high value service. Relative to the cost of the custom Android device, there’s a lot of money connected to laboratory testing and product quality inspection. One oversight that occurs when testing medications, chemicals, materials or inspecting high volume consumer products before they leave the port could cost millions of dollars in lost development, product, or reputation cost. Accuracy, accountability, and efficiency are critical.

Use Case and Value

This device is designed for use at elite laboratories across biology, chemistry, physics, and other scientific fields to document and verify experiment and inspection processes. This standing tablet has two cameras—one front-facing to capture the inspector’s identity via facial recognition, and an elevated camera, looking down, to record the item being inspected—the tablet ensures full transparency and traceability.

At a cost of less than $200 per unit in volumes above 5,000, this custom Android tablet offers a highly affordable solution in the world of thousand dollar tests and inspections in precision or medical equipment inspections. By video recording inspection workflows, it eliminates the risk of bribery or human error that historically plagued quality control, protecting companies from costly defective shipments and damaged business relationships.

Key Features

• Powerful Hardware: Eight-core Rockchip RK3576 CPU, 10″ IPS display, 4GB DDR RAM, 64GB flash storage, Wi-Fi and Bluetooth connectivity.
  
• Dual Cameras: Front camera for facial recognition and elevated camera for detailed inspection recording.
  
• AI-Driven Inspection: Machine learning algorithms confirm completed inspections, track inspection duration, and detect potential defects missed by inspectors.
  
• Accountability: Enhanced quality control through digital evidence and inspector verification.
  

Custom Android Tablet for Industrial Inspection and Patrol

In stark contrast, our second example is a rugged custom Android tablet built into a high power flash light. Engineered for frontline inspection and patrol operations in industries such as railway maintenance, chemical plants, security, and power grid monitoring, this custom Android device turns frontline workers into productivity powerhouses.

Use Case and Value

This custom Android device is a digital toolbox serving as a multifunctional inspection assistant that enhances worker safety, operational accuracy, and communication in hazardous and challenging environments. It integrates advanced high powered lighting, high-precision positioning technology, hazardous gas detection, and real-time voice and video communication into a single, ruggedized Android platform.

Detailed Specifications and Features

• Hardware Platform: MediaTek Helio G36 2.2GHz processor, paired with 3GB RAM + 32GB eMMC storage.
  
• Display: 2.8-inch IPS touchscreen (640×480 resolution) with 2-point touch capability.
  
• Cameras:
  
  • Main autofocus 13MP camera
    
  • Secondary 2MP fixed-focus macro camera for close-up detail.
    
• Lighting System:
  
  • White floodlight (≥5 Lux at 3 meters) with two brightness modes.
    
  • Powerful spotlight (>1500 Lux at 1 meter).
    
  • Warning lights with red and green LEDs for train alerts.
    
  • Red and blue strobe lights for emergency signaling.
    
  • Laser positioning module for precise location marking.
    
• Battery: Built-in 5000mAh battery (or an optional 10,000mAh for extended use), supporting over 8 hours of continuous video recording and over 6 hours of continuous lighting.
  
• Communication:
  
  • Wide cellular network support including TDD-LTE, FDD-LTE, GSM, and WCDMA bands.
    
  • Wi-Fi 802.11ac (2.4G/5G), Bluetooth 5.0, NFC support.
    
  • Dual microphones with noise cancellation and AI echo suppression for clear voice communication.
    
  • Push-to-talk (PTT) and real-time voice/video communication.
    
• Positioning:
  
  • Built-in GPS/Beidou module with RTK compatibility for centimeter-level accuracy (<1m).
    
  • Supports multiple Beidou frequency bands.
    
• Hazardous Gas Detection: Optional modular sensors for detecting gases such as CO2, ammonia, methane, hydrogen sulfide, carbon monoxide, and chlorine.
  
• Durability: IP65-rated rugged design, drop resistant up to 1.5 meters, operating temperature range -10°C to 55°C.
  
• Additional Features: Magnetic attachment for hands-free use, multiple physical buttons for quick operation (power, photo, video, PTT, flashlight), and a Type-C USB port supporting OTG.
  
• Software: Runs Android 10.0, enabling extensive customization and integration with third-party inspection and dispatch systems.
  

The Flexibility of Custom Android Hardware

These two products illustrate the incredible versatility of custom Android hardware. Whether it’s a sleek tablet designed for precise laboratory documentation or a rugged, multifunctional device built for frontline industrial use, Android’s open ecosystem allows Hatch to tailor devices to exacting specifications.

• Cost-Effective Innovation: Custom Android tablets bring proven enterprise-grade features at affordable prices, enabling industries to upgrade workflows without prohibitive costs.
  
• Hardware Customization: From specialized cameras and sensors to advanced positioning and communication modules, Android hardware can be adapted to any environment and use case.
  
• Software Integration: The Android platform supports machine learning, facial recognition, and real-time data processing, empowering smarter, more accountable operations.
  
• Scalability: Whether deploying hundreds or thousands of units, custom Android hardware solutions scale to meet growing business needs.
  

Why Choose Hatch for Your Custom Android Tablet Needs?

No two industries or applications are alike. Our experience in designing and manufacturing niche custom Android hardware enables us to deliver tailored solutions that maximize performance, reliability, and cost-efficiency. By leveraging the flexibility of the Android platform, we help businesses create value and drive innovation.

If you’re interested in exploring how a custom Android tablet can transform your operations—whether for laboratory testing, industrial inspection, or beyond—contact Hatch today. Let’s build the future of Android hardware together.

Custom Andriod hardware development includes a series of steps which, together, bring products from concept to reality.  The amount of time required to complete each step is generally predictable, but there are variables throughout the process that have a significant impact on the overall development timeline.  Therefore, it’s safer to calculate the upper estimate of how long a custom Android development project will take.  At the start of a project this is the number which matters the most.  Achieving a shorter timeline is a bonus, not an expectation.

As much as everyone wants to rush the development process, it’s more time efficient to get things right the first time.  Rushing through the process is likely to cause problems which will take longer to fix than doing it right the first time.  This doesn’t mean that all steps in the process are necessary.  Later, this article will talk about ways to and reasons for skipping some of the normal steps, but when a step is undertaken, it must be done correctly.  The value in most custom Android products comes from the software more than the hardware.  The hardware is a way to support the features of the software.  Unlike mass market retail products, a custom Android product doesn’t compete against other companies providing the same hardware using the same specs.  Custom Android devices need to deliver the best experience for the software running on the custom Android device.

There are a few specific parts of the development process where the length of time to finish is uncertain.  The first example is the industrial design (ID), which happens at the start of a project.  Firmware engineering and hardware architecture creation can be done in parallel, but other elements must wait until the ID is finished.  On the client’s side, app development usually takes longer than expected.  This is almost always related to aspects of the client’s actual apps, rather their compatibility with the custom Android OS.

Once the ID is finished, the engineering development work takes about 6-7 months from start to trial production.  This includes mechanical engineering (designing the inside of the case), electronic engineering (PCB layout), choosing peripheral components (the components which don’t go on the PCB, like camera, screen, touch panel, etc), making working prototypes, making the plastic injection molds for casing, and a small batch production of around 5 pcs.  Adding time necessary for testing, modifications, and shipping, the total timeline usually reaches 8-10 months.  The ID creation process, which includes designing the case, making case prototypes, and evaluating them, can take 2-3 months.

For clients with a tight go-to-market schedule, it’s important to accurately estimate the total time needed to develop a custom Android product so they know the reliability of meeting their scheduling goal.  When the timing looks impractical, we must consider solutions to reduce the development time.  The solutions often require compromises that involve completely skipping certain parts of the process.  This kind of a situation recently presented itself.

After 5+ years, a client wanted to update their product in order to introduce new features and a newer version of the Android OS.  While the product functionality and firmware requirements remain the same, the update called for a new case design, a new PCB, and new peripheral components.  The client wants the product to ship by September 2025.  With Chinese New Years happening later this month (meaning that companies in China will close for about 3 weeks) and the development process just starting, 9 months isn’t enough, especially since the ID hasn’t been started.

Hatch suggested to the client that we break the development into 2 stages.  This way they will have something new to promote next year, and then something new to promote the following year, without the stress or risk of rushing the development process.  For the first stage, we’ll develop a new PCB, using an updated CPU, that will use the same peripheral components and fit into the client’s existing casing.  We’ll design the new PCB so it can fit into their new casing, once that’s finished.  Then for the second stage, we’ll release the update with the new casing and peripheral components in 2026.

This two stage approach allows more scheduling flexibility for the most time consuming parts of the development process including ID creation, making the mold, and all the time spent testing these.  It also gives more time to choose new peripheral electronics.  Ultimately, we’ll have more than enough time to make the second stage product as perfect as possible, while reducing risk and having the benefit of learning from sales of the first stage version.  This staged approach reduces the development time from a year to about four months.

Ultimately, the two staged approach supports the client’s marketing efforts by having two updates over the course of two years to get customers excited about.  From the manufacturing side, the development process follows a reliable timeline, allowing for the ample attention to detail and time to make any necessary changes.

Similar principles apply to new product development as well.  When clients start their custom Android development with a long list of complicated customization requirements, researching the feasibility of their requirements and implementing them takes time and may increase cost.  The final product might actually be better if they refine the list, stick with just the most important customizations, and learn from the actual end user experience before trying to do everything at the beginning.  As much as we want to make the perfect product on the first try, there’s a reason that the biggest brands in the world continually release product updates.  Getting something finished in a timely manner, that has all the most important features, usually results in a better product that’s more efficiently developed.

Prototyping in Custom Android Development: Turning Concepts into Reality

Bringing a custom Android product to life is a journey filled with innovation, iteration, and discovery. At its core lies the process of prototyping—the creation of tangible, testable versions of your concept. Each prototype serves a distinct purpose, helping refine the product step by step until it’s ready for the hands of users.

In the world of custom Android development, prototyping takes many forms. It could be as simple as an app prototype created in design tools like Figma to test UI and UX, or as complex as a physical prototype, such as a working sample or a trial production unit. No matter the stage, the goal remains the same: bring ideas to reality for testing and improvement. Here’s how the magic unfolds.

App Prototyping Matters in Custom Android Development

Custom Android products almost always run unique software, meaning the development of hardware and apps must proceed hand-in-hand. For app developers, the process often starts with a UI/UX prototype—a digital mockup designed to test the user experience and interface flow. Once these designs are approved, programmers dive into coding.  This is not something Hatch works on, but it’s relevant to the overall product development.

But here’s the challenge: the custom hardware the app is destined for often doesn’t exist yet! How can software developers ensure their apps are optimized for hardware that’s still in development?

The Parallel Sample: Jumpstarting App Development

We solve this challenge with a parallel sample. This is a functional sample of an existing tablet or phone that uses the same core architecture as the final product. By providing a parallel sample at the project kickoff, we give app programmers a platform to start development immediately, rather than waiting months for the first working samples.

An early start is crucial because software development often takes the longest time. With the parallel sample, app developers can test compatibility and functionality from day one, setting the stage for seamless integration with the custom hardware.

The First Working Sample: Bringing It All Together

It takes about 2-4 months to finish the initial development engineering.  At that point it’s time for the first working sample. This prototype represents the initial physical manifestation of a custom Android device.

• What it includes:
  A 3D-printed case, electronics from a small PCBA batch (usually fewer than 10 pieces), and peripheral components like the screen, battery, and camera.
  
• How it’s used:
  About five units are typically produced. Some go to the customer, while others stay with Hatch for intensive testing. Over 1-2 weeks, this prototype is put through its paces to identify obvious issues—casing design, core electronic functions, firmware stability, and overall user experience.

This phase is all about ironing out big wrinkles and ensuring the basic foundation is solid before scaling up.

Trial Production: A Glimpse of the Final Product

Once the working sample is approved, it’s time to take a bigger leap: trial production. Here, we shift from small-scale prototypes to a limited run of 50-200 units, produced using the same mass production tooling and processes as the final product.

• Purpose of trial production:
  These units are the closest thing to the final product, designed for broader testing. By distributing them to end users, we can get feedback about hidden issues that might only appear in real-world conditions or over time. This stage also provides invaluable insights into hardware durability, software performance, and usability.

Why it matters:
No amount of internal testing can replace the feedback gained from actual users. Trial production bridges the gap between controlled environments and the unpredictability of real-world usage.

Prototyping with Purpose: Faster, Better Results

Each stage of prototyping plays a unique role in the custom Android development process. By understanding and embracing these stages—parallel samples, working samples, and trial production—you can achieve faster timelines and superior results.

Hatch believes in empowering customers with the tools and strategies to bring their vision to life. Whether it’s jumpstarting app development with a parallel sample or refining the final product with trial production units, every step is designed to ensure your custom Android product exceeds expectations.

Reach out if you have a solid team, great business, and long term vision for your custom Android product.  We’re here to help.

Creating a custom Android product requires going through a series of smaller processes that, in succession, become the whole product development process.  First, we figure out if the client knows what they want and then ask ‘why’.  Second, we research the client’s use case.  This step is ongoing, both for Hatch and our customer, this way the product continuously gets better.  Hatch then validates the client’s initial product details, based on a better understanding of the use case.  This is an interactive process that takes place over email or phone calls, with written call recaps.

Once the detailed product architecture has been confirmed, based on an in depth understanding of the use case, Hatch proceeds with product engineering. This mainly includes designing the PCBA, mechanical design (internals of the case), and firmware.

Keeping this theoretical process in mind, below highlights a real communication example from a current project.  Witnessing an actual conversation will clarify the concept.  Plus you can envision how it would work with your project.  To understand exactly what this process entails, let’s look at a recent email exchange with an actual customer.

This customer has been working with Hatch since 2018.  They originally asked for our help to get through a complicated and challenging situation with another supplier.  Once that was resolved, they asked Hatch to redevelop their product with quality improvements.  Over the years they’ve grown their business and we’ve maintained a positive working relationship.  Now they’re ready to get started on their second generation product.

Many companies consider using custom Android hardware to get a steady long-term supply of their optimized hardware, rather than using a generic retail device that gets updated every 6-12 months.  Sticking with the same hardware doesn’t last forever though.  After 5-6 years, enough time and updates have gone by to justify an update.  The development process is similar to the first time, but the customer’s understanding of user experience is even better.

The customer pointed out a few things that they’d like to change in the next generation product.  One of the changes they want to make involves the SD card slot.  That component is exposed to enough water and dust that it must be cleaned after a few years to continue working smoothly.  The ideas that Hatch presented were dismissed by the client based on their acute knowledge of the product’s operational environment and users.  This conversation shows how the client presents product needs, Hatch comes back with ideas, and decisions are made.

After receiving new spec requirement from the client, Hatch responded with the following questions:

Reviewed the specs.  Here are some questions.

1. Does the new version use the same case design?  If not, do you have a new case design in mind?  We may be able to make the current mold thicker, like you requested, which is a lower cost option than having to make a new one.

2. It looks like there will be 2 sets of specs (Model A and B).  I’m thinking we use the same PCBA, but Model A doesn’t include the WiFi chip and uses 32GB memory, while Model B has WiFi and 64GB of flash.  Any other differences?

3. You mention using a heavy duty USB port.  What do you think makes the USB ports ‘heavy duty’?  What experiences inspire this comment?

Here’s the client’s response as well as Hatch’s reply to the client:

1. Same design, yes. Thicker and stronger definitely!  I would really like to strengthen the trim bezel around the screen.

(Hatch) In this case I’d like to see if we can modify the tooling of your current case rather than making a new mold as this will save you thousands of dollars.  Modifications based on the changes you’ve outlined: thicker plastic, USB-C, and something to accommodate the suggestion I’ll make below regarding SD card ports.

2. You hit it spot on.  We also need to change the chipset to a more modern one that can handle a newer Android OS.

3. I would like a real USB-C.  We have had customers use the wrong chargers and cook the mainboards and, in real bad situations, cook the batteries. I feel with USB-C and a supporting chipset, we can utilize fast chargers and higher current. Also, USB-C would be a little more modern.

(Hatch) I know the current CPU only supports USB 2.0.  We’ll make ‘USB 3.0 chipset’ and USB-C port par of the new requirements.

Since last fall we have seen an outbreak of SD Ports not working. A solution seems to be cleaning the ports in the service department.  After spending months trying to figure out the problem, I learned the contacts are slowly becoming corroded, in particular the upper SD Port.  These SD ports are probably the most used SD ports in the world, next to professional photographers. Every day customers are using these and they may be inserting sd cards 10 times a day 4 days a week; which means heavy heavy use.  Is there any way to get a heavy duty sd port? Gold contacts? Better builds?

(Hatch) We’ll explore more durable SD card port options.  I’m impressed that you’re not seeing the SD card component breaking off the board based on the heavy usage and rugged clientele.  We’ll note to continue with the same mechanical design in the new versions.

Having that SD card port constantly open in outdoor environments and in different weather conditions exposes the slot to dust and moisture.  With that in mind, what do you think about these ideas:

1. Adding a silicon (soft rubber) plug to the SD card port opening.  It can be attached to the case so it won’t get lost (unless someone breaks it off).  We can attach it in a way that makes it more difficult to remove unintentionally, if you think that’s useful.  A bike light of mine uses this concept to cover the USB charging port and I accidentally pulled it off.  Now, I can’t get it to reconnect.  I can send a photo if you want.

2. A flap, like the one that covers a letterbox, that is closed by default using a spring mechanism, but is flexible to get pushed back when someone inserts the SD card.  That way the hole stays protected and the user doesn’t deal with a plug.  We just need to make sure this is designed to withstand abuse.

The above 2 ideas are ways to achieve the same end result.  If you’re interested in either we can check the mechanical viability of making modifications to the original mold.

And, finally, we established a clear direction with this response from the client:

I like your thought on the port covers for the new models but I will have to say no, it would be more troublesome and they would certainly break off. (just like on your bike)

The ports are getting the moisture from the cards themselves. Being transferred from every card.  Like I said it took me months to get this completely figured out.  Hundreds of times the cards are being transferred in and out of the device, bringing in moisture. (I traced this by having customers send me their sd cards that seemed problematic).

Also keep in mind, at a minimum, 95% of the time these sd ports are occupied with cards.

You made a very good point about the ports not being torn off the board.  I can tell you we have not had one single problem with that from any of the lots; Not once! Good job on your team’s part!

This exchange highlights the initial part of the product development process.  It starts with understanding the use case and environment.  We use creativity, experience, and communication to define the ideal approach.  Now it’s time to get to work!

Custom Android tablet development requires careful planning to go smoothly. Find out important development principles and tips to help get the best results.

Continue reading