Теперь можем официально сообщить вам, что смартфон Google Nexus S доступен для предварительных заказов от британского розничного рынка Carphone Warehouse, а в последнее время его стоимость снизилось, в настоящее время стоит около $ 180, а не $ 199.По словам официального опубликования Carphone Warehouse, 22 декабря – устройство появится в больших магазинах, хотя ранее предполагалось, что поставки начнутся позже – только одну или две недели после Рождества, а теперь , что смартфон будет выпущен еще до Рождества.
Второй “gugalfon” от Samsung является моноблоком с 4-дюймовый сенсорный экран, покрытый изогнутое стекло Contour Дисплей для лучшего баланса лицо. Кстати, в России Super AMOLED панель будет заменена Super Clear LCD, но в Россию на рынке продукт появится только в феврале следующего года.Google Nexus S является первой модели Android 2.3. Цена Google Nexus S, без контракта в Великобритании составляет $ 672. Смартфон будет доступен бесплатно, но с двухлетним контрактом от местного оператора.
Here at Google, we’re all about exploration. It’s no surprise that some of our favorite products are built to let you explore the world in ways never before possible. Google Maps lets you find your way all around the world. Google Earth lets you explore the planet in detail, complete with trees and oceans. And Google Sky Map lets you explore the skies right from your Android device. Well, we wanted to do a little exploring of our own, so we decided to venture into near space, with the help of some Androids.
Recently, we travelled to Ione, CA and sent seven payloads up, up, and away into near space, each equipped with a Nexus S. We took some cues from others who have sent homemade weather balloon rigs far up, and we wanted an opportunity to collect some interesting data about the sensors in Nexus S – GPS, gyroscope, accelerometer, and magnetometer. We also couldn’t resist what looked like a great way to spend a weekend. Sending the balloons up also gave us an opportunity to capture some stunning imagery and videos of Earth. Take a look at unaltered footage of an Android at over 100,000 ft above the Earth’s surface:
The Rig
How did we get our little Android commanders that high up? Well, first the Android platform provides a robust development environment and Nexus S has a great set of embedded sensors, both of which made it easy for us to write the apps we needed for this project. Going forward with other similar projects we have an open environment that we can modify at any level necessary. We then worked with UCSC student Greg Klein to prepare each of the payloads, which were housed in foam coolers. We secured a nylon load line to the cooler and attached to it a radar reflector, a parachute, and finally, a weather balloon. Every payload had an APRS transmitter attached to a GPS that was known to work at high altitudes, as well as batteries for power. The remainder of each payload was different for each balloon: some had digital cameras taking pictures and some had video cameras mounted at various angles (up, down, and at the horizon).
These phones were running a variety of apps: Google Maps for Mobile 5.0 (with offline map data) which allowed us to see what was directly below the balloon, Google Sky Map to see if we could identify the real stars in the backdrop, Latitude to report location when the phones had a data connection, and our own custom sensor logging app that sampled all the available sensors on the device. We even manned our payloads with some special astronauts: small Android robots, and boy did they fly. Check out an in-depth look at how we prepared and launched the payloads:
What We Found
The payloads collected a lot of data, and many reached high altitudes, with the highest topping out at 107,375 ft., over 20 miles high, or over three times the height of an average commercial jet. We also clocked one of the payloads at 139 mph at its fastest.
In tracking the sensors on each of the phones, we observed that the GPS in Nexus S could function up to altitudes of about 60,000 ft. and would actually start working again on the balloon’s descent. We also saw that Nexus S could withstand some pretty harsh temperatures (as low as -50˚C). Some interesting data we collected:
Maximum Speed: 139 mph
Maximum Altitude: 107,375 ft (over 20 miles, over 30 km)
Maximum Ascent Rate: 5.44 m/s
Average Flight Duration: 2 hours, 40 minutes
Average Descent Time: 34 minutes
By analyzing all the collected data, we were able to find some interesting trends. For instance, we determined the speed and altitude of the jet stream: about 130mph at 35,000 ft.
In the end, the team recovered all of the payloads sent up, we even recovered the payload we sent as a test a week prior to the actual launch. We had a blast taking Android all the way up to near space. If your interested in launching a balloon of your own, click here for more info. We have more exciting things coming your way as we use the openness of the Android platform to experiment here at mission Android headquarters.
*Special thanks to Arshan Poursohi, Greg Klein, and Tommy Nourse for all their help.
Posted by Zi Wang, Captain, Mission Android Headquarters
With the advent of Gingerbread, we’re going to be running a series of posts in this space about the aspects of Android 2.3 that developers should care about. One thing that developers should care about more than anything else is not losing data. The rules are changing slightly as Gingerbread arrives, so I thought that would be a good starting point. I didn’t write this; I pulled it together from the contents of an email thread involving Android engineers Brad Fitzpatrick, Dianne Hackborn, Brian Swetland, and Chris Tate.
The question is: how do you make really sure your data’s been written to persistent storage? The answer involves a low-level system call named fsync(). Old C programmers like me mostly learned this the hard way back in the Bad Old Days; in 2008 at OSCON I immensely enjoyed Eat My Data: How Everybody Gets File IO Wrong by Stewart Smith; I’ve included a picture I took of one of his slides.
The reason this should be of concern to Android developers is that with 2.3, an increasing proportion of devices, notably including the Nexus S, are going to be moving from YAFFS to the ext4 filesystem, which buffers much more aggressively; thus you need to be more assertive about making sure your data gets to permanent storage when you want it to.
If you just use SharedPreferences or SQLite, you can relax, because we’ve made sure they Do The Right Thing about buffering. But if you have your own on-disk format, keep in mind that your data doesn’t actually consistently reach the flash chip when you write() it or even when you close() it. There are several layers of buffering between you and the hardware! And because of ext4 buffering policy, any POSIX guarantees that you thought you had before (but actually didn’t), you especially don’t have now.
Some Android devices are already running non-YAFFS filesystems, but as we brought up the Nexus S, buffering issues have actually bitten us a couple of times in framework code. When the Gingerbread source code becomes available, you’ll find lots of examples of how file I/O should be done.
To start with, for raw data consider using one of the synchronous modes of java.io.RandomAccessFile, which take care of calling fsync() for you in the appropriate way. If you can’t, you’ll want Java code that looks something like this.
In some applications, you might even want to check the return status of the close() call.
Now of course, there are two sides to this story. When you call fsync() and force the data onto storage, that can be slow; worse, unpredictably slow. So be sure to call it when you need it, but be careful not to call it carelessly.
