On Android Compatibility

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]

At Google I/O 2010, we announced that there are over 60 Android models now, selling 100,000 units a day. When I wear my open-source hat, this is exciting: every day the equivalent of the entire population of my old home city starts using open-source software, possibly for the first time. When I put on my hat for Android Compatibility, this is humbling: that’s a whole lotta phones that can all share the same apps.

Another thing we launched at Google I/O was an upgraded and expanded source.android.com. The new version has refreshed info on the Android Open-Source Project, and some new tips and tools for device manufacturers — useful if you’re an OEM. However, it also has details on the Android compatibility program, now. This is also aimed mostly at OEMs, but Tim Bray suggested that developers might be interested in a peek at how we keep those 100,000 devices marching to the same beat, every day. So here I am, back on the blog.

The F-word, or, Remember remember the fifth of November

I remember sitting with my colleagues in a conference room in Building 44 on November 5, 2007, listening to Andy Rubin and Eric Schmidt announce Android to the world. I remember a lot of the press stories, too. For instance, Android was “just words on paper” which was especially entertaining since I knew we were getting ready to launch the first early-look SDK a mere week later.

Another meme I remember is... yes, “fragmentation”. Literally before the close of business on the same day we announced Android (4:46pm to be precise), I saw the first article about Android “fragmentation.” The first day wasn’t even over yet, and the press had already decided that Android would have a “fragmentation” problem.

The thing is, nobody ever defined “fragmentation” — or rather, everybody has a different definition. Some people use it to mean too many mobile operating systems; others to refer to optional APIs causing inconsistent platform implementations; still others use it to refer to “locked down” devices, or even to the existence of multiple versions of the software at the same time. I’ve even seen it used to refer to the existence of different UI skins. Most of these definitions don’t even have any impact on whether apps can run!

Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.

Compatibility

Now, that’s not to say that there aren’t real challenges in making sure that Android devices are compatible with each other, or that there aren’t very real concerns that keep app developers awake at night. There definitely are, and I spend a great deal of time indeed thinking about them and addressing them. The trick is to define them clearly.

We define “Android compatibility” to be the ability of a device to properly run apps written with the Android SDK. This is a deceptively simple way to frame it, because there are a number of things that can go wrong. Here are a few:

• Bugs - devices might simply have bugs, such as a buggy Bluetooth driver or an incorrectly implemented GPS API.




• Missing components - devices might omit hardware (such as a camera) that apps expect, and attempt to “fake” or stub out the corresponding API.




• Added or altered APIs - devices might add or alter APIs that aren’t part of standard Android. Done correctly this is innovation; done poorly and it’s “embrace and extend”.

Each of these is an example of something that can make an app not run properly on a device. They might run, but they won’t run properly. These are the things that I spend my time preventing.

How It Works

As stewards of the platform we realize that it’s vital to allow only compatible devices to participate in the Android ecosystem. So, we make compatibility a strict prerequisite for access to Android Market and the right to use the Android name. This means that developers can rely on the fact that Android Market — the keystone of the Android ecosystem — will only allow their apps to run on compatible devices. It’s pretty self-evident that a single app ecosystem is better than many small ones, so OEMs are generally pretty motivated to ship compatible devices.

But motivation alone doesn’t get us very far without tools to actually ensure compatibility, which is where the Android compatibility program comes in. This program is like a stool with three legs: the Android source code, the Compatibility Definition Document, and the Compatibility Test Suite.

It all starts with the Android source code. Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device. For the most part, Android devices are running the same code. The fact that all Android devices run the same core Android code goes a long way toward making sure those devices all work the same way.

However, this doesn’t solve the problems of missing components or altered APIs, because the source code can always be tweaked. This is where the Compatibility Definition Document (or CDD) comes in. The CDD defines in gory detail exactly what is expected of Android devices. It clearly states, for example, that devices may not omit most components, and that the official Android APIs may not be altered. In a nutshell, the CDD exists to remove ambiguities around what’s required of an Android device.

Of course, none of that overcomes the simple reality of human error — bugs. This is where the Compatibility Test Suite comes in. The CTS is a collection of more than 20,000 test cases that check Android device implementations for known issues. Device makers run the CTS on their devices throughout the development process, and use it to identify and fix bugs early. This helps ensure that the builds they finally ship are as bug-free as possible.

Keeping Up with the Times

We’ve been operating this compatibility process with our OEM partners for over a year now, and it’s largely responsible for those 60+ device models being interoperable. However no process is ever perfect and no test suite is ever 100% comprehensive, and sometimes bugs get through. What happens then?

Well, we have great relationships with our OEMs, and like I said, they’re motivated to be compatible. Whenever we hear about a serious bug affecting apps, we report it to our partners, and they typically prepare a bugfix release and get it out to end users. We will also typically add a test case to the CTS to catch that problem for future devices. It’s an ongoing process, but generally our partners are as interested as we are in the user experience of the devices they sell.

The mobile industry today is “very exciting”, which is code for “changes painfully fast”. We believe that the only way Android will be a success is to keep up with that change, and ultimately drive that change. This means that over time, the CDD will also change. We’ll add new text to handle problem cases we encounter, and the actual requirements will change to accommodate the innovations happening in the field. For example, in the 2.1/Eclair CDD, we tweaked the CDD slightly to make telephony optional, which allows Android to ship compatibly on non-phone handheld devices. Whenever we do this, of course, we’ll make corresponding changes to the Android APIs and Android Market to make sure that your apps are protected from ill effects.

On a somewhat related note, a lot of ink has been spilled on the fact that there are multiple versions of Android out there in users’ hands at the same time. While it’s true that devices without the latest software can’t run some of the latest apps, Android is 100% forward compatible — apps written properly for older versions also run on the newest versions. The choice is in app developers’ hands as to whether they want to live on the bleeding edge for the flashiest features, or stay on older versions for the largest possible audience. And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded.

What It Means for You

All that is great — but what does it mean for developers? Well, we put together a page in the SDK Documentation to explain this, so you should take a look there. But really it boils down to this:

1. As a developer, you simply decide what features your app requires, and list them in your app’s AndroidManifest.xml.




2. The Android compatibility program ensures that only compatible devices have access to Android Market.




3. Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don’t have the features you listed.

That’s all!

There almost certainly will be devices that have access to Android Market that probably weren’t quite what you had in mind when you wrote your app. But this is a very good thing — it increases the size of the potential audience for your app. As long as you accurately list your app’s requirements, we’ll do the rest and make sure that your app won’t be accessible to a device where it won’t run properly. After all, we’re app developers ourselves, and we know how painful it is to deal with users upset about an app not working on a device it wasn’t designed for.

Now, that’s not to say that we think our current solution is perfect — no solution is. But we’re continuously working on improvements to the SDK tools and Android Market to make your life as an Android developer even easier. Keep an eye on this blog and on the Android Market itself for the latest info.

Thanks for reading, and happy coding!

Hatta Rajasa Jagokan Brazil di Piala Dunia

Jadwal Pertandingan Piala Dunia 2010 Hingar bingar Piala Dunia Afrika Selatan ternyata juga dinanti-nanti oleh Menko Perekonomian Hatta Rajasa. Meskipun dirinya mengaku lebih menggemari olahraga golf, namun Hatta mengaku memfavoritkan Brazil untuk merengkuh trofi kebanggaan sepakbola dunia tersebut.

Jadwal Pertandingan Piala Dunia "Saya sih mengharapkan Afrika Selatan selaku tuan rumah, cuman memang harapan. Tapi kalau mau ukur kekuatan bagusnya Brazil, Italia, Belanda, saya favoritkan Brazil supaya bisa menang tujuh kali," ujarnya di kantornya, Jalan Lapangan Banteng, Jakarta, Senin (31/5/2010).

Sebenarnya alasan Hatta untuk menjagokan Brazil karena sosok Ronaldinho sebagai pemain andalan Brazil. Namun, sayangnya Ronaldinho tidak dipanggil pelatih Brazil Dunga dalam tim nasional Brazil untuk piala Dunia 2010 ini.

Meskipun Ronaldinho tidak ada, namun harapannya tertumpu pada bintang Brazil lainnya Kaka, meskipun musim ini kemampuan Kaka kurang teruji dan kemungkinan besar Kaka akan terlempar dari skuad klubnya Real Madrid karena kedatangan pelatih anyar Jose Mourinho ke Klub berjuluk Los Galasticos.

"Saya sedih Ronaldinho tidak masuk,untungnya masih ada Kaka. Tapi Maurinho kan megang Real Madrid, Kaka bisa dituker Frank Lampard (pemain Chelsea)," tandasnya

De Oranje Bertvan Marwijk Cari Tim Impian

Punggawa Belanda merayakan gol kedua Robin van Persie ke gawang Meksiko dalam laga uji coba, Kamis (28/5) dini hari WIB. Pertandingan kontra El Tri dimanfaatkan pelatih De Oranje Bert van Marwijk untuk menyeleksi 23 pemain yang bakal di bawa ke Piala Dunia 2010.

FREIBURG(SI) – Pelatih Bert van Marwijk mengaku sudah mendapat gambaran tentang ketujuh pemain yang harus dibuangnya untuk menggenapi skuad Belanda di Piala Dunia 2010. Arsitek berusia 58 tahun tersebut enggan memberi bocoran dan berencana baru memaparkannya ke publik kemarin melalui konferensi pers. ”Saya sudah tahu siapa yang bakal ditinggalkan,”kata Van Marwijk, seusai menyaksikan pasukannya menaklukkan Meksiko 2-1 di Stadion Badenova,Rabu (26/5).

Beberapa nama yang masuk spekulasi gagal lolos audisi adalah RonVlaar,Orlando Engelaar,Ryan Babel, dan Edson Braafheid.Vlaar dan Babel terkena cedera sehingga kebugarannya diragukan. Engelaar gagal menarik hati selama latihan. Begitu pula Braafheid,meski diberi kesempatan menunjukkan kemampuan di partai persahabatan kontra Meksiko. Jika benar keempat pemain tersebut dipangkas,ada tiga sosok lain yang nasibnya terancam.

Mereka terpaksa ditinggalkan untuk memberi tempat kepada Arjen Robben, Wesley Sneijder,dan Mark van Bommel yang terlambat bergabung dengan timnas akibat partisipasi di final Liga Champions.Di sini,nama Ibrahim Afellay masuk nominasi. ”Dia mengesankan dan berperan terhadap terciptanya gol Robin van Persie. Afellay juga bekerja bagus di training camp.

Namun, penampilan buruk di babak kedua melawan Meksiko memberinya nilai negatif,”sebut Van Marwijk. Mantan nakhoda Feyenoord Rotterdam itu memberikan pujian khusus bagi Van Persie yang memborong gol kemenangan De Oranje –julukan Belanda–di babak pertama. Menurut Van Marwijk, anak buahnya ini bermain istimewa di laga perdana sejak terakhir kali merumput di laga uji coba versus Italia, November 2009.

Berkaca pada performanya tersebut,Van Persie hampir dipastikan mengisi salah satu posisi di lini depan tim utama.”Keseluruhan, saya puas menyaksikan anak-anak mengambil inisiatif sejak menit pertama.Yang perlu disesalkan adalah penyelesaian.Kami punya tujuh atau delapan peluang bagus. Kami mestinya menang lebih besar,”papar Van Marwijk.

Laga kontra Meksiko merupakan persiapan perdana Belanda menyambut partisipasi di Piala Dunia. Mereka dijadwalkan bertemu Ghana (1 Juni) dan Hungaria (5 Juni) sebelummelakonipartaiperdanaGrup E melawan Denmark pada 14 Juni. Selain Denmark, Belanda bergabung bersama Jepang dan Kamerun. Sementara untuk Meksiko,kekalahan memberikan pencerahan bagi Pelatih Javier Aguirre dalam membenahi kelemahan pasukannya.

El Tri–julukan Meksiko–sebelumnya diberi pelajaran oleh Inggris yang berjaya 3-1, Senin (24/5). ”Tidak seperti kemenangan, banyak yang dapat kami petik dari kekalahan versus tim kuat. Kami jadi tahu apa yang perlu diperbaiki,” ujar Direktur Timnas Federasi Sepak Bola Meksiko Nestor de la Torre.

Ilmu tersebut adalah lemahnya konsentrasi pemain di awal laga dan lubang di lini belakang. Sementara gol Javier Hernandez yang memperkecil kedudukan memberikan nilai positif semangat pantang menyerah.

Android Cloud To Device Messaging

[This post is by Wei Huang, who helped implement this feature. — Tim Bray]

In the just-launched Android 2.2, we’ve added a new service to help developers send data from servers to their applications on Android phones. Android Cloud to Device Messaging (C2DM) makes it easier for mobile applications to sync data with servers.

Most of the useful applications on your mobile phone use the Internet to keep users connected. Traditionally, many apps use polling to fetch data periodically. POP mail clients, for example, connect to the server every 15 minutes or so. Polling is fairly easy to implement, and works well in many situations. It’s tricky, though, to select the frequency: Poll too often, you may not see any new data, and create unnecessary stress on the server and network. Poll too rarely and the data on the device may become stale. Polling is especially problematic on mobile devices, because it consumes precious network bandwidth and battery life.

Having the server push messages to the client asynchronously may be a superior choice for getting the latest data to your applications, resulting in fresher data and more efficient use of the network and your battery. However, it’s also tricky to implement a good push solution, and it isn’t free as there is some overhead in maintaining the required connection. On a mobile device like an Android phone, implementing applications to receive these messages is tricky; you have to worry about patchy network coverage and zombie connections created when the wireless carrier’s routers time out connections that are idle for too long.

Many of the Google applications on Android already use push to keep their data fresh, for example Gmail, Contacts, and Calendar. Starting with Android 2.2, C2DM allows third-party developers to use the same service the Google apps do.

Here are a few basic things to know about C2DM:

• It requires Android 2.2; C2DM uses Google services which are present on any device running the Android Market.




• It uses existing connections for Google services. This requires the users to sign into their Google account on Android.




• It allows 3rd party servers to send lightweight data messages to their apps. The C2DM service is not designed for pushing a lot of user content; rather it should be used like a “tickle”, to tell the app that there is new data on the server, so the app can fetch it.




• An application doesn’t need to be running to receive data messages. The system will wake up the app via an Intent broadcast when the the data message arrives, so long as the app is set up with the proper Intent Receiver and permissions.




• No user interface is required for receiving the data messages. The app can post a notification (or display other UI) if it desires.

It’s easy to use the C2DM API. Here is how it works:

• To enable C2DM, an application on the device registers with Google and get a registration ID, and sends the ID to its server.




• When the server needs to push a message to the app on the device, it posts the message via HTTP to Google’s C2DM servers.




• The C2DM servers route the message to the device, and an Intent broadcast is sent to the app.




• The app is woken up to process the message in its Intent Receiver.




• The app can unregister with C2DM when the user no longer wants messages to be pushed to it.

That’s about it! All you need is a server that knows to talk HTTP, and an Android app that knows how to use the Intent APIs. Below are some code samples:

// Use the Intent API to get a registration ID
// Registration ID is compartmentalized per app/device
Intent regIntent = new Intent(
        "com.google.android.c2dm.intent.REGISTER");
// Identify your app
regIntent.putExtra("app",
        PendingIntent.getBroadcast(this /* your activity */, 
            0, new Intent(), 0);
// Identify role account server will use to send
regIntent.putExtra("sender", emailOfSender);
// Start the registration process
startService(regIntent);

The registration ID will be delivered back to your app via an intent broadcast with the Intent Action com.google.android.c2dm.intent.REGISTRATION. Here is a code sample to receive the registration ID.

// Registration ID received via an Intent
public void onReceive(Context context, Intent intent) {
  String action = intent.getAction();
  if (“com.google.android.c2dm.intent.REGISTRATION”.equals(action)) {
    handleRegistration(context, intent);
  }
}

public void handleRegistration(Context context, Intent intent) {
  String id = intent.getExtra(“registration_id”);
  if ((intent.getExtra(“error”) != null) {
    // Registration failed.  Try again later, with backoff.
  } else if (id != null) {
    // Send the registration ID to the app’s server.
    // Be sure to do this in a separate thread.
  }
}

On the server side, your server needs to get a ClientLogin Auth token in order to talk to the C2DM servers. When it wants to push a message to the device, it can send an authenticated http POST with:

• Authorization: GoogleLogin auth=<auth token>




• URL encoded parameters including the registration id, the data key/value pairs, a “collapse key” used for overriding old messages with the same key on the Google C2DM servers, and a few other optional params.

When you use the C2DM service, you no longer need to worry about dealing with flaky mobile data connections, or when the user isn’t connected to the internet (i.e. Airplane mode). C2DM keeps the messages in the server store, and delivers them when the device comes back online. Basically, you can leave all the hard work of designing a robust push service to Google. Your application can take advantage of push infrastructure we’ve already built and tested, and stay more connected to the internet. Best of all, you won’t ruin the users’ battery life.

Information about how to build C2DM enabled applications on Android is online at the code lab, and more will be coming as we approach general release.

Dalvik JIT

[This post is by Dan Bornstein, virtual-machine wrangler. — Tim Bray]

As the tech lead for the Dalvik team within the Android project, I spend my time working on the virtual machine (VM) and core class libraries that sit beneath the Android application framework. This layer is mostly invisible to end users, but done right, it helps make Android devices run smoothly and improves developer productivity.

The 2.2 release is particularly pleasing to me, as it is the first release since before 1.0 in which we have been able to deliver significantly new VM technology. And unlike much of what my team and I do, it is something that can be experienced directly by end users.

“Dalvik” isn’t exactly a household word (at least in my country), and most people wouldn’t know a virtual machine if it hit them in the face, but when you tell them you were able to make their existing device work better — run faster, use less battery — they will actually take notice!

What Makes This Possible?

We added a Just In Time (JIT) compiler to the Dalvik VM. The JIT is a software component which takes application code, analyzes it, and actively translates it into a form that runs faster, doing so while the application continues to run. If you want to learn more about the design of the Dalvik JIT, please watch the excellent talk from Google I/O 2010 given by my colleagues Bill Buzbee and Ben Cheng, which should be posted to YouTube very soon.

To be clear, the differences aren’t always dramatic, nor do they apply uniformly to all applications. Code that is written to run the CPU all-out can now do more in the same amount of time (running faster), and code that is written to be rate-limited can get its work done using less time and less of the CPU (using less battery). On the performance front in particular, we have seen realistic improvements of 2x to 5x for CPU-bound code, compared to the previous version of the Dalvik VM. This is equivalent to about 4x to 10x faster than a more traditional interpreter implementation.

The team is proud of our new JIT in general, but we are especially proud of two aspects of it:

Many previous JIT implementations react slowly, delivering performance improvements only after a long warm up period. In the extreme, it can be minutes or even hours before the code is fully up to speed. On the other hand, the Dalvik JIT reacts quickly, so that mere moments after you hit the “Start” button on your favorite game, you are already benefiting from the work of the JIT.

We are also very pleased with how little memory the JIT uses. The code for the JIT itself is well under 100k, and each process that the JIT runs in will typically only use another 100k or so of RAM. On the current generation of Android phones, device users won’t even notice this additional memory usage; on my own phone, I can still have literally dozens of applications warmed up in memory and ready to go.

The Dalvik team isn’t resting on its laurels, either. We are hoping to see the Dalvik JIT deployed on many devices in the coming months. Looking forward, the team has an endless list of ideas for making the VM and library code better, which we are diligently working on.

New Zealand vs Sri Lankaat Lauderhill, 1st T20 Cricket Live Streaming Online Here

Test/Odi's

European Union

Test Series and all ODI's .

Click Here To Watch Live T20 Cricket Matches Online

 New Zealand vs Sri Lanka Live

LIVE LINK

Dated: 22-05-2010

Stated : from 19:30 until 23:30 (GMT/UK)

New Zealand v Sri Lanka at Lauderhill, 1st T20I

Sri Lanka squad
KC Sangakkara*†, LD Chandimal, TM Dilshan, CU Jayasinghe, ST Jayasuriya, DPMD Jayawardene, S Randiv, CK Kapugedera, KMDN Kulasekara, SL Malinga, AD Mathews, BAW Mendis, NLTC Perera, T Thushara, UWMBCA Welegedara

New Zealand squad
DL Vettori*, IG Butler, MJ Guptill, GJ Hopkins†, BB McCullum†, NL McCullum, AJ McKay, KD Mills, RJ Nicol, JDP Oram, AJ Redmond, TG Southee, SB Styris, LRPL Taylor

A historical bat and ball matchup takes place in Florida this weekend. No, it doesn't include the Marlins. They're in Chicago playing the White Sox. Nor is it the Rays. They're in Houston playing the Astros. In fact, it's not even baseball related.

It's Sri Lanka against New Zealand, a battle of two powerhouses in international cricket. Yes, cricket, that odd bat and ball sport which Sports Illustrated writer Paul Gallico described, "takes three days to play, in which runs are scored by the dozens and Centuries, and batting stands of one hundred are not uncommon. And the break for tea is considered the most deliciously funny business this side of a comic valentine."
Sri Lanka and New Zealand will be the first International Cricket Committee teams to play on American soil. It will also be the first time an American audience will get a glimpse at cricket stars like Daniel Vettori, New Zealand's young captain, and Sri Lankan batsman Mahela Jayawardene.

The teams will play each other in The Pearls Cup at the Broward County Regional Park in Lauderhill along with the United States against Jamaica in a doubleheader of matches that will air live on ESPN3.com at 3:30 p.m. ET Saturday and noon ET Sunday.
Cricket is considered the second most popular sport in the world and has more than 15 million fans in the United States, where baseball is still the national pastime. But cricket has historical roots that outdate baseball. Soldiers in the Revolutionary War played cricket at Valley Forge.

In 1844, the United States and Canada went head-to-head in the first international sporting event between two nations in world history. Even Abe Lincoln reportedly turned out to watch Chicago play Milwaukee in a cricket match in 1849. The United States had one of the finest cricket players of all time in Philadelphia born Bart King, known as one of the fastest bowlers (pitchers) of his generation.
On Monday, the New Zealand cricket team, known as the Black Caps, visited the Marlins during batting practice. All-Star shortstop Hanley Ramirez wore knee guards and swung a cricket bat. In the outfield, members of the New Zealand cricket team caught fly balls. Later that night they would throw out the first pitch. So in the roots of sports genealogy, baseball and cricket are brothers from another mother.

CRICKET PRIMER
"Baseball and cricket are beautiful and highly stylized medieval war substitutes, chess made flesh, a mixture of proud chivalry and base - in both senses - greed"
-- John Fowles, English novelist, author of The Collector
Let's get to the basics. In cricket there are 11 players; in baseball, nine. The object of both games is to score the most runs and to get the other team out. Baseball is played on a diamond-shaped field with foul lines, whereas cricket is played on an oval-shaped area about 450 feet in diameter.

Pitching/fielding

Both sports are battles between a batter and a pitcher, called a bowler in cricket. The distance between both is relatively similar; 60 feet, 6 inches is the distance between the pitching mound and home plate, while the distance between two wickets is about 66 feet.
In cricket, the bowler gets a running start and on most occasions hurls the ball on a bounce to the batter. In baseball, unless your Carl Lewis throwing out the first pitch, the ball is usually thrown directly to the catcher in a set motion.
Cricket, like baseball, also has its speed and offspeed pitches. In cricket, slower bowlers are called spinners. In baseball, they're called Orlando Hernandez.
There are a number of similar ways to record an out in cricket and baseball, whether by a catching a ball in the air or tagging a runner. In cricket, a player can also get out on a leg before wicket, which is as esoteric to a baseball fan as the infield fly rule is to a cricket aficionado.
In baseball, defensive positions are standardized, whereas in cricket they are fluid. Sure, you can play the shift with David Ortiz at bat, but in cricket a batter can use the entirety of the field to place shots.
In baseball, a manager can make defensive decisions, but in cricket only the captain can.
Fielders in baseball use mitts to catch a ball. In cricket, where the ball is harder, it's your bare hands in every position but the wicket keeper, which is similar to playing catcher.
Batting
When it comes to batting, writer Roger Bate wrote,"baseball's emphasis is on power. In cricket, consistent contact." Meaning Indian batsman Virender Sehwag would be a solid slugger in the MLB and Ichiro a terrific cricket player.

Runs are much easier to score in cricket. You can easily see batters accumulate dizzying run totals. The record for a test match is 400 runs, held by former West Indies star Brian Lara, described by President Obama as the "Michael Jordan of cricket."
The fact you can hit the ball in any direction in cricket makes it easier run up the score. Ted Williams said hitting a baseball is the hardest thing to do in sports, Tell that to a cricket batsman, who has to incorporate a number of strokes and techniques from a slog to leg glance and who can stay at bat for hours at a time drenched in sweat.
In cricket, runs can be scored hitting the ball and running from one wicket to another or smacking the ball past the boundary line in the field. By air it's six runs and by ground it's four runs.
Length
"Baseball has the great advantage over cricket of being ended sooner."
-- George Bernard Shaw, Nobel Prize winner, author of Pygmalion
Test matches are the stereotypical cricket matches that can last three to five days.
One Day Internationals take place from morning till dusk. Think doubleheader. They last for 50 overs (innings). Each over consists of six balls thrown.
But the new form of cricket gaining traction is the Twenty20 format, which is 20 overs and lasts the length of a baseball game. This format has proved successful in the Indian Premier League and is being utilized to promote the game in the United States. 

Android Application Error Reports

[This post, the first in a series about new features in Android 2.2 ("Froyo"), is by Jacek Surazski, a Googler from our Krakow office. — Tim Bray]

The upcoming release of Android will include a new bug reporting feature for Market apps. Developers will receive crash and freeze reports from their users. The reports will be available when they log into their Android Market publisher account. No more blind debugging!

When an app freezes or stops responding, the user can send a bug report to the developer with a click of a button, right from their phone. The new button appears in the application error dialog; if the user chooses to click it, the Google Feedback client running on the device will analyze the offending app and compose a report with information needed to diagnose it. The system is set up with user privacy in mind — the app developer will not receive information which could identify the user in any way. The user can also preview all information that will be sent.

If users choose to do so, they may also send additional system information like device logs. Because there is a chance these may contain private information, they will not be passed on to the developer; they will be used by Google to track down bugs in the Android system itself.

On the receiving end, developers will get tools to diagnose, triage and fix bugs in their apps. A popular app can generate hundreds of thousands of reports. Google Feedback aggregates them into "bugs" - individual programming errors. Bugs are displayed to developers sorted by severity, measured as the rate at which reports for the bug are flowing in.

Clicking on a bug will display information such as stack traces, statistics about which type of hardware the bug occurred on and what versions of the app the user was running. In case of freezes, stack traces for all threads in the app will be displayed. This data should give developers a good idea how well their apps are faring in the wild.

Google is constantly working on improving and extending the feedback feature to provide developers with tools to improve the quality of their apps. The benefits should be felt by both developers and their users.

[I recommend watching the video of this feature's announcement in Vic Gundotra's Google I/O keynote on May 20th, mostly for the audience reaction. I hear that a high proportion of developers are making use of the Market's new "Bugs" tab. — Tim Bray]

Sneaky Hate Spiral

Most of the time, I'm pretty even-tempered.  Aside from the odd nervous breakdown or caffeine-induced bliss-seizure, I have the emotional variation of sand.  However, every once in a great while, I'll lapse into what I like to call a "sneaky hate spiral."

The buildup:

Sneaky hate spirals begin simply enough.  In fact, that is one of the hallmarks of sneaky hate spirals - they are merely the confluence of many unremarkable annoyances.

Your day begins poorly.

Before you've had a chance to recover from your unpleasant awakening, you are pummeled by a series of unfortunate events.  There are probably some loud and/or persistent sounds mixed in there, too. 

The little frustrations start to happen more quickly.  They ping against your psyche like hundreds of tiny pebbles.  

Eventually, the sum of the small annoyances begins to exceed your capacity for patience and rational thought.  All it would take to send you over the edge into a bottomless pit of angry hysteria is just one more tiny, little thing...

The turning point:

The turning point is usually a minor but slightly jarring incident, initiated by some force of nature that cannot be blamed or scolded - like gravity or sleeplessness or wind.  That last specification is very important.  In order to send you into truly batshit crazy hysterics, the final straw must cause anger that cannot rationally be directed outward in any way.

Your worn patience plus the inability to blame anything for your misery causes a chain reaction to take place inside of you.

The rage enters your body, but cannot exit through either the blame or personal responsibility pathways. It therefore must travel to the very center of you where it will fester and eventually rupture.  

Chaos:

When enough anger and hatred has accumulated inside of you, it will rupture through your pathetic sense of integrity and start spewing outwardly as if you are some sort of rage sprinkler, spraying your putrid hate all over anything that comes near you.   

You are officially out of control.   At this late stage, there is no way around it.  You are simply a helpless passenger in your psychotic war-machine of a body.