Android 4.0.3 Platform and SDK tools

 

Google are announcing Android 4.0.3, an incremental release of the Android 4.0 (Ice Cream Sandwich) platform. The new release includes a variety of optimizations and bug fixes for phones and tablets, as well as a small number of new APIs for developers. The new API level is 15.

Some of the new APIs in Android 4.0.3 include:

Social stream API in Contacts provider: Applications that use social stream data such as status updates and check-ins can now sync that data with each of the user’s contacts, providing items in a stream along with photos for each. This new API lets apps show users what the people they know are doing or saying, in addition to their photos and contact information.

Calendar provider enhancements. Apps can now add color to events, for easier tracking, and new attendee types and states are now available.

New camera capabilities. Apps can now check and manage video stabilization and use QVGA resolution profiles where needed.

Accessibility refinements. Improved content access for screen readers and new status and error reporting for text-to-speech engines.

Incremental improvements in graphics, database, spell-checking, Bluetooth, and more.

 

For a complete overview of what’s new in the platform, see the Android 4.0.3 API Overview.

Going forward, we’ll be focusing our partners on Android 4.0.3 as the base version of Ice Cream Sandwich. The new platform will be rolling out to production phones and tablets in the weeks ahead, so we strongly encourage you to test your applications on Android 4.0.3 as soon as possible.

We would also like to remind developers that we recently released new version of the SDK Tools (r16) and of the Eclipse plug-in (ADT 16.0.1). We have also updated the NDK to r7.

Visit the Android Developers site for more information about Android 4.0.3 and other platform versions. To get started developing or testing on the new platform, you can download it into your SDK using the Android SDK Manager.

Now you can test your Mobile Web Apps with WebDriver

Mobile testing has come a long way since the days when testing mobile web applications was mostly manual and took days to complete. Selenium WebDriver is a browser automation tool that provides an elegant way of testing web applications. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from an Android or iOS browser.

For those of you new to WebDriver, here are a few basics about how it helps you test your web application. WebDriver tests are end-to-end tests that exercise a web application just like a real user would. There is a comprehensive user guide on the Selenium site that covers the core APIs.

Now let’s talk about mobile! WebDriver provides a touch API that allows the test to interact with the web page through finger taps, flicks, finger scrolls, and long presses. It can rotate the display and provides a friendly API to interact with HTML5 features such as local storage, session storage and application cache. Mobile WebDrivers use the remote WebDriver server, following a client/server architecture. The client piece consists of the test code, while the server piece is the application that is installed on the device.

Get Started


WebDriver for Android and iPhone can be installed following these instructions. Once you’ve done that, you will be ready to write tests. Let’s start with a basic example using www.google.com to give you a taste of what’s possible.

The test below opens www.google.com on Android and issues a query for “weather in san francisco”. The test will verify that Google returns search results and that the first result returned is giving the weather in San Francisco.

public void testGoogleCanGiveWeatherResults() {
// Create a WebDriver instance with the activity in which we want the test to run.
WebDriver driver = new AndroidDriver(getActivity());
// Let’s open a web page
driver.get(“http://www.google.com”);

// Lookup for the search box by its name
WebElement searchBox = driver.findElement(By.name(“q”));

// Enter a search query and submit
searchBox.sendKeys(“weather in san francisco”);
searchBox.submit();

// Making sure that Google shows 11 results
WebElement resultSection = driver.findElement(By.id(“ires”));
List searchResults = resultSection.findElements(By.tagName(“li”));
assertEquals(11, searchResults.size());

// Let’s ensure that the first result shown is the weather widget
WebElement weatherWidget = searchResults.get(0);
assertTrue(weatherWidget.getText().contains(“Weather for San Francisco, CA”));
}

Now let’s see our test in action! When you launch your test through your favorite IDE or using the command line, WebDriver will bring up a WebView in the foreground allowing you to see your web application as the test code is executing. You will see www.google.com loading, and the search query being typed in the search box.


We mentioned above that the WebDriver supports creating advanced gestures to interact with the device. Let’s use WebDriver to throw an image across the screen by flicking horizontally, and ensure that the next image in the gallery is displayed.

WebElement toFlick = driver.findElement(By.id(“image”));
// 400 pixels left at normal speed
Action flick = getBuilder(driver).flick(toFlick, 0, -400, FlickAction.SPEED_NORMAL)
.build();
flick.perform();
WebElement secondImage = driver.findElement(“secondImage”);
assertTrue(secondImage.isDisplayed());

Next, let’s rotate the screen and ensure that the image displayed on screen is resized.


assertEquals(landscapeSize, secondImage.getSize())
((Rotatable) driver).rotate(ScreenOrientation.PORTRAIT);
assertEquals(portraitSize, secondImage.getSize());

Let’s take a look at the local storage on the device, and ensure that the web application has set some key/value pairs.


// Get a handle on the local storage object
LocalStorage local = ((WebStorage) driver).getLocalStorage();
// Ensure that the key “name” is mapped
assertEquals(“testUser”, local.getItem(“name”));

What if your test reveals a bug? You can easily take a screenshot for help in future debugging:


File tempFile = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);

High Level Architecture

WebDriver has two main components: the server and the tests themselves. The server is an application that runs on the phone, tablet, emulator, or simulator and listens for incoming requests. It runs the tests against a WebView (the rendering component of mobile Android and iOS) configured like the browsers. Your tests run on the client side, and can be written in any languages supported by WebDriver, including Java and Python. The WebDriver tests communicate with the server by sending RESTful JSON requests over HTTP. The tests and server pieces don’t have to be on the same physical machine, although they can be. For Android you can also run the tests using the Android test framework instead of the remote WebDriver server.

Infrastructure Setup

At Google, we have wired WebDriver tests to our cloud infrastructure allowing those tests to run at scale and making it possible to have them run in our continuous integration system. External developers can run their mobile tests either on emulators/simulators or real devices for Android and iOS phones and tablets.
Android emulators can run on most OSes because they are virtualized, so we run them on our generic cloud setup. Though there are many advantages to using Android emulators because they emulate a complete virtual device (including the virtual CPU, MMU, and hardware devices), it makes the test environment slower. You can speed up the tests by disabling animations, audio, skins, or even by running in the emulator headless mode. To do so, start the emulator with the options –no-boot-anim, –no-audio, –noskin, and –no-window. If you would like your tests to run even faster, start the emulator from a previously created snapshot image. That reduces the emulator startup time from 2 minutes to less than 2 seconds!
iOS simulators can’t be virtualized and hence need to run on Mac machines. However, because iOS simulators don’t try to emulate the virtual device or CPU at all, they can run as applications at “full speed,” this allows the test to run much faster.
Stay tuned for more mobile feature in Selenium WebDriver, and updates on the Selenium blog.

Google Earth Imagery: The end of October

What do Elvis’ Graceland and Iran’s Marmar Palace have in common? Both estates have been updated with new imagery in Google Earth and Google Maps!

Over the last few weeks, the imagery team has updated hundreds of images. To give you a taste of this new data, today we’ll look at several interesting features that have been updated with new imagery from across the globe.

First, I’d like to look at a fantastic and majestic terrestrial landform known as the star dune. Star dunes form pyramidal shapes that grow upward and are characterized by multiple radiating dune crests. Shown below is a perspective satellite image of a star dune field within the Badain Jaran Desert of China. The desert contains Earth’s tallest stationary dunes, reaching heights of 500 meters!

Perspective view of star dunes of Badain Jaran Desert, China
One of my favorite hobbies is scrambling around volcanic sites throughout the western United States, and many of my favorite areas are located in Idaho’s Snake River Plain. Within this river plain, one of the youngest volcanic flow features of the region comprises the Hell’s Half Acre lava flow field. In the aerial image below, taken this past September, you can see “windows” of older river bed material (now farmland) that were not buried during lava flow emplacement.

Farmland enclosed by lava flow, Snake River Plain, Idaho
Can you identify the unusual feature relationship seen in the satellite image below? Yes, train tracks cut to the northeast across the airport runway! Those tracks belong to the Kyber Railway, and their two vintage steam locomotives take passengers 42 kilometers to the town of Landi Kotal in Pakistan’s mountainous Kyber Pass.

Peshawar International Airport, Pakistan
Below is a fun water sport activity captured in high resolution aerial imagery of the southeastern coast of Auckland, New Zealand. You can see the kayakers paddles as well as the submerged sandbars and boulders of Thorne Bay.

Kayakers in Thorne Bay, New Zealand
We can see the Marmar Palace of Tehran, Iran, a.k.a the Marble Palace in the updated satellite image below. It is associated with the Pahlavi dynasty, and is still used today by the Iranian government.

The Marble Palace, Tehran, Iran.
In my opinion, most good things start and end with Elvis references, so our last example showcases updated imagery of Graceland, including the private customized Convair 880 jet Elvis used while hopping across the globe.

Graceland, Memphis Tennessee
If you’d like to receive an email notification when the Earth and Maps Imagery team updates your favorite site(s), we’ve got just the tool: The Follow Your World application!

These are only a few examples of the types of features that can be seen and discovered in our latest batch of published imagery. Happy exploring!

High Resolution Aerial Updates:
USA: Bellingham, WA; Bemidji, MN; Brookings, SD; Davenport, IA; Emporia, KS; Grinnel, IA; Idaho Falls, ID; Klamamth Falls, OR; Lawrence, KS; Lovell, WY; Nephi, UT; Pittsfield, MA; Portland, OR; San Francisco Peninsula, CA; Scottsbluff, NE; Seattle, WA; St Louis, MO; Terre Haute, IN; Wasco, OR; Williston, ND; Wolf Point, MT

Spain: Huesca, Logrono

Countries/Regions receiving High Resolution Satellite Updates:
Angola, Antarctica, Argentina, Australia, Bahrain, Brazil, Cameroon, Canada, Chad, Chile, China, Colombia, Cuba, Côte d’Ivoire, Democratic Republic of the Congo, Ecuador, Ethiopia, Gaza Strip, Greenland, Hungary, India, Indonesia, Iran, Israel, Jan Mayen, Japan, Jordan, Kazakhstan, Latvia, Libya, Lithuania, Malawi, Mexico, Morocco, Mozambique, Namibia, New Zealand, North Korea, Pakistan, Paraguay, Peru, Philippines, Poland, Romania, Russia, Saudi Arabia, Senegal, Slovakia, South Africa, Spain, Svalbard, Taiwan, Tanzania, The Gambia, Turkey, Uganda, Ukraine, United States, West Bank, Yemen, Zambia, Zimbabwe

Google Summer of Code: Write code and save lives with OpenMRS

Earlier this year OpenMRS participated in Google Summer of Code, a worldwide program organized by Google’s Open Source Programs Office to expose university students to the world of free and open source software, and encourage those students to become long-term contributors to projects that interest them. OpenMRS is a web-based medical record system originally designed for use in the developing world, and is now used on every continent on the globe. OpenMRS is used in all kinds of health care environments, from research laboratories to hospitals to small clinics in remote villages, and even via mobile devices that collect data door-to-door.
OpenMRS has been participating in Google Summer of Code every year since 2007, and our 5th year was arguably our most successful yet. This year, 15 motivated students successfully completed projects to focus or extend the OpenMRS health care IT platform in ways that will have significant impact for our global community of users. Throughout the summer our students became full contributors in good standing in the OpenMRS community. They presented their projects’ work in progress to other developers and users and often contributed their code to our software releases to support health care professionals saving lives around the world. Unlike many other summer internships that students may have during the summer, our students were responsible for planning and delivery of “real-life projects” that came from needs and requests from people installing and using OpenMRS.
Some projects were dedicated to improving the core OpenMRS platform, and some built add-on modules to support specific types of clinical activities. There were projects focused on making the installation of OpenMRS easier, and others focused on helping improve collaboration for our volunteer community. And if the presentations our students made this semester were any indication, all of the projects were exciting ways to write code and save lives. There’s not space here to describe each project in detail, but we encourage you to check out our students and their projects on the OpenMRS Wiki and learn more about them:
  • Balachandiran Ajanthan created an add-on module to deploy reusable “SMART” health care apps inside OpenMRS.
  • Christopher Zakian reimagined a “universal” search within OpenMRS that allows users to search for any system data from anywhere within the system
  • Gaurav Paliwal created an add-on module to allow OpenMRS users to provide application feedback to their system administrators and the larger open source community.
  • Gauthami Pingili improved both the UI of the OpenMRS Patient Matching module and improved its accuracy of finding duplicate patients.
  • Goutham Vasireddi helped make it faster and easier for developers to write add-on modules for OpenMRS by creating a “wizard” for Maven.
  • Jelena Skorucak reworked the attributes a person has within OpenMRS, giving clinics the flexibility to record more information about the persons.
  • João Portela made significant improvements to our HTML Form Entry editor, allowing non-programmers to create more detailed, useful data collection forms for health care.
  • Piotr Bryk enhanced our Metadata Sharing module to make it easier to manage the export and import of OpenMRS system configurations.
  • Rahul Akula’s work helped make it possible for OpenMRS to interoperate with external laboratory information systems.
  • Sai Manohar Nethi worked to create a framework for a comprehensive Human Resource add-on module for OpenMRS, allowing the system to help manage clinic personnel.
  • Sreya Janaswamy created a way for OpenMRS users to translate phrases used by the application into other languages, inside the application itself.
  • Sriskandarajah Suhothayan created a way for the OpenMRS Notifiable Condition Detector module to watch for certain large-scale patterns and send notifications to clinicians via SMS or e-mail.
  • Suranga Kasthurirathne created a new way for OpenMRS to store clinical observations that reference other people or locations.
  • Taras Chorny built a system to allow OpenMRS to be installed and upgraded using a variety of languages.
  • Victor Chircu built an “Atlas” add-on module that allows OpenMRS users to opt-in to report their location, type of clinic, and number of patients on a shared map to represent the active OpenMRS community.
Since we started participating in Google Summer of Code, we’re very proud that so many of our students have stayed active in the OpenMRS community and continued to contribute their talents after the program ended. In fact, three of our students have gone on to become full-time OpenMRS developers paid by various organizations involved in our community.
We continue to be more and more impressed with the students who are interested in our work, and are proud to welcome them into the OpenMRS family! In fact, this year, 2011 Google Summer of Code student Suranga Kasthurirathne was able to join us in October for our annual OpenMRS implementers meeting in Kigali, Rwanda. Suranga provided some excellent feedback about his involvement in Google Summer of Code this year, and about his experience meeting the OpenMRS community face to face. Read his blog post for more of his thoughts.
Once again, this year we were blown away by our amazing students during Google Summer of Code.