Approaching Time Sensitive Custom Android Development with Creative Solutions

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.

Close up of nurse holding and typing on tablet standing in stomatologic clinic, while doctor is working with patient in background. Using monitor with chroma key izolated pc key mockup pc display

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.

Custom Android Prototyping Best Practices

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.

Behind the Scenes: Android Device Customization

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!

Quality Checklist for Custom Android Tablets (Functional Checks)

This month’s article lists out a few of the standard functionality tests Hatch performs on custom Android tablets.  These tests are part of a longer list which includes many kinds of inspections Hatch does to ensure the product meets Hatch’s basic quality standard.  Beyond the fundamental tests, when checking the functionality of a custom Android tablet, Hatch will add custom quality checks based on the product’s specific functionality requirements.  For example, if the product uses a wide angle camera lens, Hatch will check that the viewing angle meets the special requirements.  If an unforeseen problem gets found during the development process, Hatch will introduce a test into the quality control process to cover that specific issue.

The name of each check is followed by details of the inspection process.

Functional Defects

Functional tests ensure correct performance of the custom Android tablet. The proper functionality of a tablet starts with using good components. This is why there are different functionality tests for all the key components of the tablet.

  1. Plug Insertion Force

This test ensures that the ports of a custom Android properly fit with the plugs that go in them. Generally this applies to a USB, earphone, and charging port. Plug insertion force is the force required to insert the plug into a slot. The port shouldn’t be too loose, so the plug falls out unintentionally, and it shouldn’t be too tight, making it difficult to insert or withdraw the plug.

We measure this force using gram-force. Gram-force (gf) is a metric unit of force that is equal to the force of gravity on a one-gram mass.

The tolerance range for this test is Min 250gf and Max 1500gf.

  1. Button Activation Force 

This test makes sure that the buttons are working properly, and more specifically, that they respond to the right amount of force. It applies to physical buttons which ‘click’, rather than touch buttons which use other sensing methods.

Button activation force defines the amount of pressure required to apply to a button for it to function. It’s also measured using gf.

The tolerance range for this test is Min 200gf and Max 400gf.

  1. Speaker Audio Quality

This test ensures that the audio output from the Android tablet or smartphone is clear at the highest volume.

Speaker Audio Quality is evaluated using sound pressure level (SPL) and total harmonic distortion + noise (THD+N) at peak speaker loudness on 1kHz sine wave.

The tolerances are SPL as dBa and THD+N as a percentage. These are checked at a distance of 10cm from the speaker. An acceptable SPL, dBa is ≥72 and THD+N, % is ≤15. To put things into everyday terms 40dB is the volume of a quiet library. 60dB: ordinary spoken conversation. 85dB: a food blender. 88dB: heavy traffic. (source: rnid.org.uk)

  1. Display Quality

This test applies to the image shown on an Android tablet or smartphone screen. It ensures that the screen’s colors, brightness, and pixels appear correctly.

Display defects are defects which cause total or partial image loss, image distortion, or reduces display usability under bright ambient light.

The tolerances for this test include average brightness (in nits), brightness uniformity (as a percentage), color representation (CIE1931), bright dead sub-pixels (based on size and density), and dark dead sub-pixels (based on size and density).

Additional tests include:

Age testing, where the device runs a demanding workload, usually playing a video at high volume. This test lasts for between several hours to several weeks, depending on the product. The point is to ensure that the system functions properly over a longer period of time while under a high stress level.

Drop testing, where the device is dropped at a specified height onto a hard surface multiple times at different angles. The goal is to ensure the device can sustain violent impact and continue to function properly.

And there are tests for all the other major components such as camera, microphone, battery, and memory.

The list of functional testing covers all elements of the custom Android tablet or smartphone that could affect its performance. All custom devices also undergo tests which are specific to their unique requirements as well. These tests are initially based on the devices custom requirements and new tests are added during the development process as new issues are found.

Handling Problems

Gain insights into the realities of custom Android hardware development with this article. Discover how setbacks in a current project led to valuable lessons on quality control, design decision-making, and the importance of thorough research in avoiding costly mistakes. Learn from a real-world example of navigating challenges in custom product development, ensuring that each problem becomes an opportunity for growth.

Continue reading

Custom Android Hardware; is now the right time?

Economics and Rational of Custom Android Hardware

To measure the economic implications of making a custom Android tablet (or custom Android phone), first look at the company’s history with Android hardware. Does the company already purchase Android devices? If yes, which kind of Android device? For example, tier 1 brand Android devices, no-name brand devices, manufacturer-direct devices, or a custom Android device. If the company is just getting started, they should begin by using a basic retail device before making a custom one.

Starting from Scratch

With many tech projects, both software and hardware, product designers have a hard time knowing exactly how end users will react to the features and interactive designs they create. Trying to design an ‘end product’ from the concept stage is nearly impossible to do perfectly. The ways customers use a product rarely matches expectation. For this reason companies go through multiple rounds of beta testing before releasing a product to the general public. Each round of testing generates feedback that improves the product’s user experience.

Product improvement in the early phases is an ongoing process of quick iterations. The key is to avoid sinking too much money into custom Android development by making small changes on existing hardware. See how customers use the product first and, then decide whether a custom device would add value. Use a non-custom device as long as possible. During that time you’ll learn what custom features to implement. The education is highly valuable in order to develop a meaningful custom Android product.

Already Using Mass Market Tier 1 Brand Tablets or Smartphones

Companies that are already using a tablet or smartphone from a tier 1 brand, often become interested in making a custom Android device after a few years. The main reason companies want to change from the mass market device is because they don’t have control over the supply. Every year the brand starts making a new model and discontinues an old model. The availability of stock is not stable. Also the company’s engineers need to modify their app’s code with each new version of hardware, adding burden and complications.

In this scenario, the company historical distribution data for the tier 1 brand device. Based on that it can predict the future volume for a custom device to determine if there’s enough volume to justify the up front cost of a custom product. It’s likely that the unit cost of a custom Android tablet, including amortized development costs, is lower than the unit cost of a tier 1 brand Android tablet. The custom device comes with higher up front costs though. For a well financed company that has a history using brand name Android tablets, developing a custom Android tablet is a smart business decision that has economic benefit within 1 year.

Using no-name brand

For companies running their custom business application on no-brand mass market devices, is a custom Android product even necessary? Some use cases don’t require any custom hardware. Maybe a bit of firmware customization on a generic device is all that’s necessary. Generic no-name brand devices are usually the cheapest products to source. The buyer needs to be sure that they’re getting products with good components, like new, grade A memory, a high quality battery, and quality assembly. In this scenario, the company can stick to buying ‘off the shelf’ devices, but should at least get a custom firmware made.

Minimum customization options should include restricting downloads, so end users can’t install unrelated apps. Embedding the client’s special apps in the firmware, so they’re always there, can’t be deleted, and will still appear after a factory reset. Custom branding, like a custom launcher or displaying the client logo on startup or on the wall paper of home screen.

Already using an existing custom product.

This is a great scenario to start from since there’s already experience with a custom product. Over time a company will discover aspects of their existing custom device that are either extraneous, missing, or could be optimized. These improvements will get integrated into a new design. Every 5-6 years it becomes necessary to update the hardware of a custom Android tablet because components used during the original development stage become obsolete over time.

When it starts to get difficult to source components of an old design, your product supplier should propose designing an updated version. If it’s not necessary to redo casing, and there aren’t major changes to the hardware, then updating should be fairly low cost and quick. Having a team that is already familiar with the product makes redevelopment easier. Since there’s historical volume of the existing custom product, it’s easy to predict future volume. As long as the volume is 5-10k+ pcs/year, updating the hardware may require a deposit on future volume, but shouldn’t require a high reinvestment.

Conclusion

For companies that have experience using a generic Android device to run their custom software, custom Android hardware not only delivers a better experience to end users, but also costs less than brand name alternatives. Benefits such as control over the devices’ operating system, embedded applications, and component selection are a few examples of where a custom Android device has clear advantages. Using a custom Android device is like wearing custom tailored clothes. They have the best look, fit, and feel, but you should know your style before getting something expensive made.