[Android General] bitbang3r:
4 internal pads on the rear of the circuit board, ready for snap-on peripheral backs to connect to Pogo Pins the same way Nexus S and Galaxy Nexus phones connect the NFC antenna mounted on the back to the board. The pads carry I2C (SDA & SCL), ground, and some reasonable supply voltage (ideally 5v, or at least 3.3v, but can be 3v, 2.9v, 2.7v, or some other offbeat voltage if it makes a HUGE difference in manufacturing cost). Don't forget a few more pads for NFC.

Anticipated use: snap-on backs with various optional peripherals, including a slide-out (or maybe rotate-out) keyboard, gamepads, etc.

Somewhere on the circuit board is a high-density interboard connector that exposes the fastest bus you can to a snap-back peripheral (possibly by attaching an expansion board that breaks the interboard connector out to much larger pogopin-ready pads, or maybe a ribbon cable. At the very least, the bus should be capable of conveying full-speed video at the display's full resolution, so somebody could make a camera-back module that uses the phone as its display, UI, wifi host, but puts a FPGA and/or DSP or two, and possibly some form of fast local storage, in the snapback module. Don't laugh. Quite a few people are *dying* for a platform suitable for an open-source HDR camcorder. Your phone will already have half the electronics it needs. If the front half of the phone can be repurposed for this use, so much the better.

Give it a PAIR of batteries... one that's swappable, somewhere between 1800 and 2400mAH, and ideally is the identical battery used by some popular phone like the Galaxy S3. You aren't going to sell enough phones for proprietary batteries to ever be a profit source, and using a commodity battery that's dirt cheap and available everywhere will make customers happy. For battery #2, fill every nook and crany of unused space inside the phone with lithium ion gel. The internal fixed battery should be at least 2400-4000mAH. This gives users the best of all worlds... the ability to casually swap batteries for more power in a pinch, but enough power to let even the most overclocked speedfreak wake up on Friday, actively use his phone all day and night, then wake up at noon on Saturday & still have a few hours of charge left.

Design a shell you can use for at least 2 or 3 generations. This will help increase the market for accessories. Give it a real 2-stage camera button at the lower right (when held in portrait orientation). Then put a pair of volume buttons at the upper right, and make sure they can be pressed independently. Put a third button between them that has no specific purpose. The user will think of one.

Put another button someplace where a user holding the phone with his left hand can have his index and middle finger on the volume buttons, and his thumb on this button. Make the button firm and tactile so the user can confidently hold the phone without fear of accidentally pressing the button, then know from touch and feel when he HAS pressed it firmly and made contact. Ditto, for the volume buttons and extra button between them.

There's another reason for the pair of volume buttons and thumb button: the user can multiply the number of buttons by chording and shifting them with each other. For example, press and hold "vol. up", press and release "vol. down" three times, release "vol up". Or press and hold the thumb button, press and release "vol. down", then release the thumb button. Somebody like ME might overload the buttons so that the actual volume function gets triggered on-screen... press and hold vol. down, press and release vol. up, then press vol. up. As long as vol. up remains held, the user can adjust volume by stroking up or down the screen.

Design your first-generation phone to work on American HSPA+ frequencies (which also happen to be relevant to Canada, Australia, Mexico, and probably a few other countries). And make sure it can fall back to EDGE, not just GPRS. Yeah, the chip will cost a few dollars more than one that only does 1900/2100 UMTS and GPRS, but that slightly more expensive chip will roughly double your potential market for the phone. Even if you never intend to explicitly sell it in the US or screw with AT&T or T-Mobile as partners, Americans WILL buy it as long as it physically works on American networks. And just as importantly, no American will touch it with a dirty pole if it can't do high-speed data in the US. The marketplace for "developer"-oriented phones is littered with the corpses of phones that were shipped with uninspiring hardware or baseband chips that couldn't do high-speed data in America. If you're tempted to think you can do OK with a phone that ignores American frequencies or has second-rate hardware, ask Trolltech or OpenMoko how well they ended up doing. Or for that matter, ask Sprint how many Nexus S phones they ended up selling (by the time Sprint released it, it was last year's hardware at this year's prices, coming out "next week"). You have to be competitive with whatever next year's top of the line Nexus device is likely to be, because that's going to be your competition by the time YOUR phone is ready to sell.

If your phone becomes wildly popular in Europe, you can always make a second cost-reduced run of phones with the baseband chip's cheaper 1900/2100 pin-compatible cousin... but on the other hand, if you use the more expensive chip and it flops in Europe, you can always view the US/Canada/Australia as "Plan B". It's a cheap insurance policy. And just to bring up CDMA again, keep in mind that they're quite common in India... and the same properly-designed USIM card subsystem that provisions it for GSM use will provision it for CDMA use just about everywhere besides America (USIM is a superset of SIM that incorporates both LTE support and CDMA's R-UIM as additional standards).

If regulatory reasons force you to ship with 1700/2100 or other American HSPA+ frequencies disabled, find a way to have someone at XDA magically discover a long-lost copy of the flash file to enable it. If AT&T offers to buy 50,000 if you disable T-Mobile frequencies, find the most non-robust way you can to do it so anybody who knows the magic settings value/keypad code/whatever can re-enable it. Microsoft did something like this ~10 years ago with Windows Mobile when Verizon demanded that they disable Bluetooth. They made a registry setting, and deleted the .dll file from the phone's ROM. Not surprisingly, it took XDA users about 3 days to rip the missing .dll file from a Sprint phone, copy it to a Verizon phone, and change the setting to enable it. ;)

Leave room for a LTE daughtercard. Even if you have no immediate plans for it, it's a cheap insurance policy. In America, LTE support is pretty much mandatory going forward. Nobody who's seen what 26mbit/sec downloads look like in with Speedtest.net will ever settle for 4-6mbit/second data again. For dimensions, tear apart an American Sprint phone with Wimax. A comparable LTE daughtercard won't be any bigger. See what signals it needs, and make sure your connector has them, too. Then bring a few more i/o lines through, just to be safe. You can always ignore unneeded signal lines, but it's really hard to add more after the fact.

While you're at it, give a little extra love & attention to the LTE daughtercard's connection bus... Try to think of other kinds of special-purpose radio modules you could connect the same way. There might be a nice, juicy contract with a bunch of American law-enforcement agencies or first responders if you can give them a phone that defaults to HSPA+, can roam on CDMA, and can interoperate with the proprietary digital network they got talked into building at unholy expense 4 years ago. Leave enough room for a 400MHz antenna if you can, and definitely make sure there's enough room for a pair of diversity-tuned 600 or 800MHz antennas with opposite polarizations if necessary. If you're going to pursue this as a fallback/side plan, design an indestructable Otterbox-like case for it, and make sure things like a broken screen can be replaced with minimal drama.

Try to use a baseband chipset that supports "everything", like the Qualcomm MDM6600. Even if you end up never selling phones to Sprint or Verizon, putting the capability there won't cost much, and it might come in handy someday. Don't bother trying to implement Sprint firmware unless Sprint buys in (Sprint refuses to activate phones they didn't personally sell), but Verizon is actually NOT ALLOWED to refuse to activate compatible phones (they're bound by the consent decree that broke up the AT&T monopoly 25 years ago. They don't have to HELP end users use unauthorized phone hardware, but they can't stand in the way, either).

Don't be afraid of Pentile. Low-resolution Pentile displays looked grainy, but anybody who claims he can tell the difference between RGBG and RGBRGB at 1280x800 green-element resolution on a 4-5" screen is lying or delusional.

Give it a real home button, flanked by menu and back buttons. Don't cheese out and try using the display as a soft button area. Everyone knows that's not a superior solution and is only done to shave a few cents from the manufacturing cost. Don't be cheesy. Remember, the user can always ignore hardkeys he doesn't want, but you can never get back the screen real estate stolen by fake hardkey images. For the record, the home button on the Samsung Galaxy S3 is too small, too low, and insufficiently tactile.

If you want to make Asians (and a few Americans & Europeans) really happy, consider equipping it with a dual capacitive + resistive touchscreen (so users can use fingers for blunt movements, then whip out a stylus for high-resolution input).

Guarantee to buyers that every single chip and module that can't have open drivers for licensing or legal reasons will have drivers furnished IMMEDIATELY for new kernels within days of any new release from Google -- unsupported drivers almost immediately making a best-effort automated build, officially supported drivers a few weeks later, with additional unsupported interim releases in between the two. That's all anybody here at XDA really expects. We know polished drivers don't spontaneously appear, and we know there are nasty companies like Qualcomm and Nvidia who'll never release open-source drivers. You have the source. We don't. We need you to put that source to good use, and do at least as well as we'd have done with the same resources.