Android

Android news

Introducing Android WebDriver

[This post is by Dounia Berrada, an engineer on the EngTools team. — Tim Bray] Selenium WebDriver is a browser automation tool which provides a lightweight and elegant way for testing web apps. Selenium WebDriver is now available as an SDK extra in the Android SDK, and supports 2.3 (Gingerbread) and onwards! Whether or not your site is optimized for mobile browsers, you can be sure that users will be accessing it from their phones and tablets. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from the Android browser. We’ll walk you through some basics about WebDriver and look at it in action. WebDriver Basics WebDriver tests are end-to-end tests that exercise the web application just like a real user would. WebDriver models user interactions with a web page such as finger flicks, finger scrolls and long presses. It can rotate the display and interact with HTML5 features such as local storage, session storage and the application cache. Those tests run as part of an Android tests project and are based on Junit. They can be launched from Eclipse or the command line. WebDriver tests can be wired with a continuous integration system and can run on phone and tablet emulators or real devices. Once the test starts, WebDriver opens a WebView configured like the Android browser and runs the tests against it. WebDriver is an Android SDK extra and can be installed following these instructions . Once you’ve done that you’ll be ready to write tests! There is a comprehensive WebDriver user guide on the Selenium site, but let’s start with a basic example using www.google.com to give you a taste of what’s possible. Getting Started First, create an Android project containing an empty activity with no layout. public class SimpleAppActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } } Then create the Android test project that will contain the tests. WebDriver will create the WebView and set the layout automatically in the main Activity. Let’s write a test that opens the Google home page 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 class SimpleGoogleTest extends ActivityInstrumentationTestCase2 { public void testGoogleShouldWork() { // 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! WebDriver will create a WebView with the same configuration as the Android browser in the main UI thread, i.e. the activity thread. The activity will display the WebView on the screen, allowing you to see your web application as the test code is executing. Interaction Testing We’ve mentioned that 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()); Now, 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()); 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); Find Out More If this has whetted your appetite and you’d like to know more, go ahead and install the Android WebDriver, take a look at the documentation on the Selenium project’s wiki , or just browse the javadocs . For questions and feedback not only of the Android WebDriver but also its desktop brethren, please join webd...@googlegroups.com . For announcements keep an eye on http://seleniumhq.wordpress.com/ .

View post:
Introducing Android WebDriver

Introducing Android WebDriver

[This post is by Dounia Berrada, an engineer on the EngTools team. — Tim Bray] Selenium WebDriver is a browser automation tool which provides a lightweight and elegant way for testing web apps. Selenium WebDriver is now available as an SDK extra in the Android SDK, and supports 2.3 (Gingerbread) and onwards! Whether or not your site is optimized for mobile browsers, you can be sure that users will be accessing it from their phones and tablets. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from the Android browser. We’ll walk you through some basics about WebDriver and look at it in action. WebDriver Basics WebDriver tests are end-to-end tests that exercise the web application just like a real user would. WebDriver models user interactions with a web page such as finger flicks, finger scrolls and long presses. It can rotate the display and interact with HTML5 features such as local storage, session storage and the application cache. Those tests run as part of an Android tests project and are based on Junit. They can be launched from Eclipse or the command line. WebDriver tests can be wired with a continuous integration system and can run on phone and tablet emulators or real devices. Once the test starts, WebDriver opens a WebView configured like the Android browser and runs the tests against it. WebDriver is an Android SDK extra and can be installed following these instructions . Once you’ve done that you’ll be ready to write tests! There is a comprehensive WebDriver user guide on the Selenium site, but let’s start with a basic example using www.google.com to give you a taste of what’s possible. Getting Started First, create an Android project containing an empty activity with no layout. public class SimpleAppActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } } Then create the Android test project that will contain the tests. WebDriver will create the WebView and set the layout automatically in the main Activity. Let’s write a test that opens the Google home page 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 class SimpleGoogleTest extends ActivityInstrumentationTestCase2 { public void testGoogleShouldWork() { // 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! WebDriver will create a WebView with the same configuration as the Android browser in the main UI thread, i.e. the activity thread. The activity will display the WebView on the screen, allowing you to see your web application as the test code is executing. Interaction Testing We’ve mentioned that 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()); Now, 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()); 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); Find Out More If this has whetted your appetite and you’d like to know more, go ahead and install the Android WebDriver, take a look at the documentation on the Selenium project’s wiki , or just browse the javadocs . For questions and feedback not only of the Android WebDriver but also its desktop brethren, please join webd...@googlegroups.com . For announcements keep an eye on http://seleniumhq.wordpress.com/ .

Link:
Introducing Android WebDriver

Nexus One “too old” to be upgraded to Ice Cream Sandwich

It seems the trusty Nexus One has made it into the legacy column. Google has confirmed what we have long suspected; the beloved Nexus One, Google’s original Nexus device, is too old to be fully and officially upgraded to Ice Cream Sandwich. Fortunately, many people who purchased the Nexus One were individuals who wanted to root their devices. Though Ice Cream Sandwich will not be officially brought to the Nexus One, we’re quite confident that Nexus One owners will see an unofficial  version of Ice Cream Sandwich come to their devices. Who out there is still using the Nexus One as your daily driver? Are you disappointed that Google couldn’t find a way to make it work, or did you largely expect this move? Any developers out there planning to port Ice Cream Sandwich to the Nexus One? Sound off below.

The rest is here:
Nexus One “too old” to be upgraded to Ice Cream Sandwich

Changes to Library Projects in Android SDK Tools, r14

Last week, we released the SDK for Android 4.0 and a new set of developer tools, now in revision 14. The updated tools include a lot of build changes, many that improve build performance. Also included is an under-the-hood change in how libraries are used by main projects — a first step in improving library support and code reusability. While the change should have little impact on existing projects, some developers have had issues when migrating to the updated tools. Please read below for more information about the change to library projects and how to solve migration issues. Previously, library projects were handled as extra resource and source code folders to be used when compiling the resources and the application’s source respectively. While this worked fine for most cases, there were two issues. 1. Developers asked us for the ability to distribute a library as a single jar file that included both compiled code and resources. The nature of Android resources, with their compiled IDs prevented this. 2. The implementation of the library projects was extremely fragile in Eclipse. Adding extra source folders outside of the project folders is non-trivial when it needs to be handled automatically, in a way that doesn’t expose a user’s local installation path (which is required for people working in teams through a source control system such as SVN or git). For r14, we decided to fix both issues at once, by moving to a compiled-code based library mechanism. This solves the implementation fragility in Eclipse and will allow us to, later, enable distribution of libraries as a single jar file. As you might have seen in the release notes, moving to this new mechanism can affect existing projects in some cases, but there are simple fixes. The first impact of this change is that the new library project requires the resource IDs generated by libraries to be non final. This prevents the Java compiler from inlining the values in the library code, and therefore prevents usage of the switch statement in the library code. To address such occurrences in your code, Eclipse provides a refactoring action to convert from switch statements to if/else (see here ). Second, some projects may not have been properly migrated to the new mechanism, resulting in projects that fail to compile, with errors such as duplicated classes being added in the dex build step. ADT 14 should have migrated older projects to the new mechanism but the fragility of the old mechanism may have prevented it from happening. This makes projects reference the libraries twice, using both the old and new mechanisms, which then triggers the libraries classes being packaged twice. If you see this in your projects, look in the Package Explorer for extraneous source folders named with the pattern _src . The screenshot to the right shows an example of this. To fix the project, you must remove the extraneous source folders with the following steps: Right click source folder and choose Build Path > Remove from Build path A dialog will pop up. In it, make sure to check “Also unlink the folder from the project” to completely remove the folder. With this change to library projects, we pave the way to better support for reusable components. We will continue working to make components easier to create, work with, and manage. Our goal is to make it easy for developers to create apps with great user experiences that easily adapt to all form factors. Some developers have also told us that they only use library projects internally, that they don’t need to distribute binary versions and would prefer to continue with a source-based mechanism. We are investigating how we could support this alongside the new mechanism. Finally, I wanted to point out that we are tracking a few known issues (and workaround for them) in the current r14 tools at this page: http://tools.android.com/knownissues . We are working on a tools update that will include fixes for most of these. We are hoping to have it out shortly.

View original post here:
Changes to Library Projects in Android SDK Tools, r14

Microsoft now takes patent licensing fees on 50pc of Android devices

ODM Compal is the latest entry in Microsoft’s Android Licensing Program With Compal as its latest victim, Microsoft has proudly announced that it now collects license fees from companies that account for over half of all Android devices shipments. Some of these are big names like HTC, Samsung and Acer. On the ODM front also,

Read the original:
Microsoft now takes patent licensing fees on 50pc of Android devices

Microsoft now takes patent licensing fees on 50pc of Android devices

ODM Compal is the latest entry in Microsoft’s Android Licensing Program With Compal as its latest victim, Microsoft has proudly announced that it now collects license fees from companies that account for over half of all Android devices shipments. Some of these are big names like HTC, Samsung and Acer. On the ODM front also,

Read the original here:
Microsoft now takes patent licensing fees on 50pc of Android devices

Workaround for minimizing sensor sampling battery cost

In my Droidcon 2011 presentation I tried to highlight the battery cost of the continuous sensor sampling which is necessary for detecting motion patterns. While the general case still requires some sort of improvement over the current Android sensor architecture e.g. the use of the “wake on motion” feature of the acceleration sensors , it is possible to decrease the battery consumption if the motion to be detected is longer than 5-10 seconds. This is still not suitable for recognising very short events like fall, tap, shake, etc. but can be suitable to “wake up” a step counter when the motion starts. Some steps would be missed but this may be acceptable if the battery life is increased. Click here to download the example program . The essence of the workaround is to use the AlarmManager and to generate periodic wakeup events. When the wakeup event is received, sensor sampling is started and some samples are collected. Then we have to figure out using some heuristics whether there is some movement. This implementation calculates the average value of the acceleration sample absolute values and looks for values deviating from the average. If there is movement detected, the sampling continues. If there is no movement detected, the program gives up the wake lock and goes back sleeping.- I have made some measurements using my Nexus 1. I switched the phone into airplane mode and ran the program during the night, for 7-8 hours. The battery percentage consumed during an hour can be seen below as a function of wakeup period (check out WAKEUP_PERIOD constant in AlarmSleep.java). 5 sec – 1.14%/hour 10 sec – 1.10%/hour 20 sec – 0.56%/hour 30 sec – 0.27%/hour The battery consumption with the last timeout value – 30 sec – is very close to the standby consumption, 0.25%. If you can tolerate that long “dead period”, then you can bring the battery consumption in “no motion” state very close to the phone’s normal standby consumption. For a general “tap” or “shake” detector, however, this is not an adequate solution. I have received encouraging mails that a proper solution relying on the sensor’s low-power mode may be deployed soon.

Read this article:
Workaround for minimizing sensor sampling battery cost

Griffin Technology debuts new Android accessories for fall

Griffin Technology has announced a number of new accessories for Android smartphones and tablets, putting them on sale for the fall 2011 season.  The new products include tablet covers, holsters, smartphone cases, micro-HDMI to HDMI cables, and more.  While some of the accessories are designed specifically for one particular model, others work in a more broad sense.  Check out the press release below and then head over to Griffin’s website to see what they might have for you. Griffin Debuts Fall Mobile Accessories Line-Up Griffin expands offerings for Android and RIM users, launching array of cases, folios and audio/visual accessories Griffin Technology, one of the world’s foremost creators of innovations for everyday life, is rolling out a new collection of smartphone and tablet accessories designed for popular Android and RIM devices. “Griffin’s new line-up addresses the demand from mobile users for connective and protective solutions that allow them to get the most out of their devices,” said Mark Rowan, President of Griffin Technology. Leading the line-up of tablet accessories includes the Elan Folio and AirStrap collections. Elan Folio features a microsuede-lined cover that flips open for quick access to the touchscreen but can also be locked into place to create an adjustable easel for landscape and portrait viewing. Elan Folio is available in models designed for Motorola Xoom, BlackBerry PlayBook, and Samsung Galaxy 10.1 in prices ranging from $39.99 to $49.99. AirStrap Lite, $39.99, designed for Samsung Galaxy 10.1, Motorola Xoom, and BlackBerry PlayBook, is Griffin’s form-fitting case collection with built-in, neoprene straps providing the ability to conveniently use tablets with a single hand. Three new case collections for smartphones each boast a distinct flare and personality, from sophisticated and sleek, to sporty and rugged. The Col. Littleton Universal Cases are Griffin’s upscale line of holsters, featuring luxurious edge-stitched steer hide with hand-set rivets and ball stud closures in polished nickel silver. New to the Griffin + Col. Littleton partnership, the No. 46 and No. 48 Holsters accommodate smartphones, MP3 players, cameras and other devices, with room to throw in some cash and cards. Like all of the Colonel’s products, these universal holsters are handmade in the Col. Littleton Workshop located in Lynnville, Tennessee, using soft, dry-milled American Steer Hide. Prices range from $65 to $68. The View Twin Shell, available in black and red versions for $29.99, provides two layers of protection for the HTC EVO 3D – a hard polycarbonate outer shell and sheer silicone inner lining to cushion the phone and keep out dust and grit. The View Twin Shell also features a built-in kickstand for landscape viewing. Motif Diamonds is a durable yet flexible line of cases for Samsung Droid Charge, available in clear and black versions for $19.99. Scuff- and tear-resistant TPU material creates a glossy, smooth finish, and clever custom cut-outs provide easy access to the Multi-Touch display, camera lens, headphone jack and dock connector. A molded-in diamond pattern gives it dimensionality and depth. Griffin’s Micro HDMI to HDMI Cable is another new mobile accessory launching this Fall, connecting smartphones to televisions in stereo audio and high definition video at resolutions up to 1080p. Simply plug-and-play. The full size HDMI connector is designed for televisions, set-top boxes, projectors and other displays with HDMI multimedia ports. The Smartphone Audio/Video Cable, available for $29.99, is compatible with BlackBerry PlayBook, HTC EVO and EVO 3D, LG Revolution, Motorola Droid Bionic, Motorola Droid X, Samsung Droid Charge, and Samsung Fascinate. Griffin’s Fall mobile accessory collection will continue to roll out onto  www.griffintechnology.com  throughout the month. To celebrate this new collection, a free  Jumper  is being offered, for a limited time only, on any smartphone or tablet accessory purchase. Customers can add a Jumper to their cart and add the promo code “JUMPER” during checkout to receive the complimentary neoprene tablet sleeve. This promotion is valid until Friday, 10/21/2011 at midnight, while supplies last. To learn more about Griffin’s smartphone and tablet accessories for Android and RIM devices, visit www.griffintechnology.com/smartphone  and  www.griffintechnology.com/tablets . For additional information about Griffin products, visit  www.griffintechnology.com  and follow Griffin on Facebook,  www.facebook.com/griffintech , and on Twitter,  @griffintech . Griffin Technology debuts new Android accessories for fall originally appeared on AndroidGuys . Follow us on Facebook and Twitter !

See the original post:
Griffin Technology debuts new Android accessories for fall

Android 4.0 Platform and Updated SDK Tools

Today we are announcing Android 4.0, Ice Cream Sandwich — a new version of the platform that brings a refined, unified user experience for phones, tablets, and more. Android 4.0 builds on the things people love most about Android — efficient multitasking, rich notifications, customizable home screens, resizable widgets, and deep interactivity — and adds powerful new ways of communicating and sharing. It includes many great features for users, including social and sharing integration, network data usage control, innovative connectivity and camera options, and an updated set of standard apps. For developers, Android 4.0 introduces many new capabilities and APIs. Here are some highlights: Unified UI toolkit: A single set of UI components, styles, and capabilities for phones, tablets, and other devices. Rich communication and sharing: New social and calendar APIs, Android Beam for NFC-based instant sharing, Wi-Fi Direct support, Bluetooth Health Device Profile support. Deep interactivity and customization: Improved notifications, lockscreen with camera and music controls, and improved app management in the launcher. New graphics, camera, and media capabilities: Image and video effects, precise camera metering and face detection, new media codecs and containers. Interface and input: Hardware-accelerated 2D drawing, new grid-based layout, improved soft keyboard, spell-checker API, stylus input support, and better mouse support. Improved accessibility: New accessibility APIs and text-to-speech APIs for writing new engines. Enhancements for enterprise: Keychain and VPN APIs for managing credentials and connections, a new administrator policy for disabling the camera. For a complete overview of what’s new for users and developers, please read the Android 4.0 Platform Highlights . Alongside the new Android platform, we are releasing new versions of the SDK Tools (r14) and ADT Plugin (14.0) for Eclipse. Among the highlights are: Improved build performance in Ant and Eclipse Improved layout and XML editors To get started developing on Android 4.0, visit the Android Developers site for information about the Android 4.0 platform , the SDK Tools , and the ADT Plugin . If you have already developed and published apps, we encourage you to download the Android 4.0 platform now, to begin testing your app before devices arrive in stores. Check out the video below for a closer look at Android 4.0 in action.

Excerpt from:
Android 4.0 Platform and Updated SDK Tools

Android 4.0 Platform and Updated SDK Tools

Today we are announcing Android 4.0, Ice Cream Sandwich — a new version of the platform that brings a refined, unified user experience for phones, tablets, and more. Android 4.0 builds on the things people love most about Android — efficient multitasking, rich notifications, customizable home screens, resizable widgets, and deep interactivity — and adds powerful new ways of communicating and sharing. It includes many great features for users, including social and sharing integration, network data usage control, innovative connectivity and camera options, and an updated set of standard apps. For developers, Android 4.0 introduces many new capabilities and APIs. Here are some highlights: Unified UI toolkit: A single set of UI components, styles, and capabilities for phones, tablets, and other devices. Rich communication and sharing: New social and calendar APIs, Android Beam for NFC-based instant sharing, Wi-Fi Direct support, Bluetooth Health Device Profile support. Deep interactivity and customization: Improved notifications, lockscreen with camera and music controls, and improved app management in the launcher. New graphics, camera, and media capabilities: Image and video effects, precise camera metering and face detection, new media codecs and containers. Interface and input: Hardware-accelerated 2D drawing, new grid-based layout, improved soft keyboard, spell-checker API, stylus input support, and better mouse support. Improved accessibility: New accessibility APIs and text-to-speech APIs for writing new engines. Enhancements for enterprise: Keychain and VPN APIs for managing credentials and connections, a new administrator policy for disabling the camera. For a complete overview of what’s new for users and developers, please read the Android 4.0 Platform Highlights . Alongside the new Android platform, we are releasing new versions of the SDK Tools (r14) and ADT Plugin (14.0) for Eclipse. Among the highlights are: Improved build performance in Ant and Eclipse Improved layout and XML editors To get started developing on Android 4.0, visit the Android Developers site for information about the Android 4.0 platform , the SDK Tools , and the ADT Plugin . If you have already developed and published apps, we encourage you to download the Android 4.0 platform now, to begin testing your app before devices arrive in stores. Check out the video below for a closer look at Android 4.0 in action.

Originally posted here:
Android 4.0 Platform and Updated SDK Tools