Facebook Launches Android SDK

Amid an apparent meltdown in the Facebook for Android app , the official Android SDK has been launched in beta for developers to use at their disposal. Up until now developers have had to rig up interface solutions through the iPhone SDK, but the official support should now make it easy to create Facebook tie-ins across apps. First demoed last week at Google I/O, the Android SDK will bring advanced functionality to Android developers over what is currently available for the iPhone, including access to Facebook’s recently announced Graph API . Users will be protected with the strong authorization of OAuth 2.0, and will be able to publish stories from apps directly to their News Feed using Feed forms. Is this a sign that Facebook is starting to get their Android ducks in a row? We sure hope so. Maybe ex-Android Team member Erick Tseng is making some good moves there already. [via TechCrunch ]

See the rest here:
Facebook Launches Android SDK

Zeemote Releases Android SDK, Bluetooth Controller-Enabled Games to Follow?

Zeemote, makers of of the JS1 Bluetooth gaming peripheral, have now made an Android SDK for said controller available to developers . The SDK supports Android 1.6 and higher, and is aimed at bringing a console-like experience to handheld gaming. The JS1 is a small, portable controller that provides an analog joystick and four buttons for a more game-friendly interface compared to on screen controls or hardware keyboards. Zeemote claims that “existing applications can be adapted in a matter of hours” and plans to roll out a developer support program in the coming weeks to help encourage and enable developers to take advantage of their Bluetooth peripherals. New and old apps alike are promised that Zeemote functionality can: provide a superior mobile gaming experience across multiple supported platforms (while maintaining compatibility with existing distribution channels) deliver true analog game control enable multi-player mobile gaming (two controllers to one device) turn a TV-out featured smart phone into a mobile game console I think it goes without saying that before you can enjoy the experience of gaming with an additional controller, the actual library of quality games in the market would need need to increase. Could additions of SDKs like Zeemote’s help push developers to create better, more engaging games for Android? Google has been looking towards gaming more and more lately, so there is hope larger developer support is on the way with some great games in tow. [ press release ]

See original here:
Zeemote Releases Android SDK, Bluetooth Controller-Enabled Games to Follow?

Android 2.1 SDK Now Available

Less than a week after the launch of the Google Nexus One handset, Google have released the Android 2.1 SDK to developers. The 2.1 SDK includes all the new features we’ve seen in the Nexus One, including new APIs for animated wallpapers, webkit browser geolocation support, and more. Hopefully it won’t be too long now before we start seeing the Android 2.1 update being pushed to the Droid, the Hero, and other Android handsets. Just yesterday Motorola also confirmed that the 2.1 update would be made available for their European Motorola Milestone (Droid), and Motorola DEXT (CLIQ) handsets. [via android-developers.blogspot.com ] If you’re looking for more info on the upcoming Google Phone, then be sure to check out the Nexus One Forums Android 2.1 SDK Now Available

View original here: 
Android 2.1 SDK Now Available

Android 2.1 SDK Out, Seems Benign

The Android 2.1 SDK is now available! This release matches the OS on the Nexus One and, presumably, future devices will upgrade to it when appropriate. With every Android SDK release, changes fall into two buckets: documented changes, and under-documented/undocumented changes. In this case, the documented changes are comparatively benign. Nothing appears to be newly deprecated or removed from the API, which are the prime causes of apps breaking in a new release. What’s definitely new are all additions, such as: “Live Wallpaper” (implemented a bit like an app widget, except you draw to a Surface instead of configuring widgets via a RemoteViews object) More hooks into the HTML5 underpinnings, with APIs to configure Web storage and geolocation for a WebView More information about signal strength changes Of course, every SDK release brings its unexpected hiccups. Given some of the reports of apps breaking on the Nexus One, and given the lineup of documented changes, it is likely there are either some subtle implementation changes that we are not yet aware of, or that the Nexus One is different enough in some ways to cause apps problems where other devices do not. I would expect that we will get a clearer picture of all of this in the next few weeks. In the meantime, use the SDK Updater tool to grab the latest additions to your SDK installation, and start playing with it!

Read the original here: 
Android 2.1 SDK Out, Seems Benign

Code Pollution: Reaching Past the SDK

In the Code Pollution series, I’ll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others. Android has a fairly rich SDK — take it from somebody who’s been writing about it continuously for quite some time. That being said, the SDK does not cover every feature, even every feature in Android itself. The core Android team’s philosophy is to avoid putting things in the SDK until the API has stabilized to the point they feel confident in supporting it over the long haul. And, even then, some things may not be added to the SDK, simply to preserve implementation flexibility. The problem is, too many parties are reaching past the SDK. The SDK is, in effect, a three-way contract. Developers who agree to stick to the SDK are assured that their application should run without issue on current and future Android Market-enabled devices. Device manufacturers that wish to ship the Android Market are given latitude to morph Android as they see fit to run on their hardware, so long as they continue to adhere to their side of the SDK and do a quality job of running third-party applications. And Google itself is committed to making deprecated APIs work as well as possible given inevitable advances in the platform. I wrote about this in a recent post on another site, but I want to dig more into the developer side of this contract. There are many tantalizing Android features just out of reach, from modifying the SMS inbox to proactively powering off the screen. Some developers go past the SDK boundaries and use such features. Sometimes, this is because the developer really wants to build app X with feature Y, and feature Y can only be implemented with things beyond the SDK. Sometimes, this is because a pointy-haired boss, who cares not a whit about customers or Android, is demanding it. Sometimes, developers use these capabilities to demonstrate 1337 hax0r sk1llz . And so on. The problem is: reaching past the SDK is bad for all parties. It is bad for the developer, because they will forevermore be chasing “bugs” because what they tried using is not stable, by accident or by intent. For example, device manufacturers are welcome to replace anything inside Android that is not part of the SDK, such as the SMS client. Developers can reach past the SDK and manipulate the SMS client’s content provider…assuming the device in question has such a content provider, and assuming the device in question has not changed the schema of the content provider, etc. It is bad for the end user, because apps will break. Developers who reach past the SDK may not be able to keep up with new Android releases or new device firmware that break their apps. As such, users will wind up downloading apps based upon product descriptions that are, at best, pleasant-sounding hopes, that may or may not be fulfilled on the user’s specific device. It is bad for the developer community, because we lose the moral high ground when trying to get device manufacturers and Google itself to adhere to their sides of the SDK “contract”. For example, it is hypocritical to complain about device manufacturers tweaking the contacts content provider and breaking apps when developers do the equivalent. And it is bad for the Android ecosystem, if enough of these apps fail on enough devices that Android gets a reputation for incomplete device compatibility, like other mobile operating systems have had. We are going to have a rough enough time with this from manufacturers working off of the Android open source project and eschewing the Android Market. Developers who add to the problem, by reaching past the SDK, are going to make it that much worse — doing unfortunate things in the swimming pool, as it were. The good news is that I think most apps available for Android stick to the SDK. After all, by and large, you need to be doing some fairly unusual stuff to go past the SDK: using reflection to access hidden classes and methods, using findViewById() to manipulate Android-supplied composite widgets like the TabWidget , using undocumented content providers, etc. I suspect there are fairly few developers who have accidentally gone past the SDK, and probably a bunch of those just copied and pasted some irregular sample they found on a blog post somewhere. I urge Android developers everywhere to consider all of the impacts of reaching past the SDK when making the decision to use such techniques, not just those impacts that they will feel immediately. It’s not too outlandish to say that Android depends upon everybody — developers, manufacturers, and Google — adhering to the boundaries of the SDK. Popular Posts That You Might Enjoy! October 27, 2009 — An Early Look at the Android 2.0 SDK (7) September 24, 2008 — The One: Musings on Android 1.0 SDK and the G1 (3) December 7, 2009 — Code Pollution: Boot-Time Services (3) November 23, 2009 — Idle Musings: Android on Chrome (6) November 16, 2009 — Diagnosing Sporadic Errors (10)

Go here to read the rest:
Code Pollution: Reaching Past the SDK

A Few Updates to the Android SDK are Released

To all those interested on any available update to Android, especially to all developers, there are a few updates to the Android SDK. And Xavier Ducrohet, Android SDK Tech Lead at Android Developers wants you to know about these new updates. As you can see on the image above, there were updates to multiple components of the Android SDK last Thursday: Android 2.0.1 revision 1, Android 1.6 revision 2 and SDK Tools, revision 4. Let’s begin with Android 2.0.1, which is a minor update to the mobile OS (Android 2.0) running on the Motorola DROID. This update includes several bug fixes and behavior changes. If you like to know more about this update, check the Android 2.0.1 release notes. Next is Android 1.6, revision 2, which includes fixes to the compatibility mode for those apps that don’t support multiple screen sizes. For more on this update, read the release notes on the Android 1.6, revision 2 here. And now, let’s talk about the SDK Tools, revision 4, which is also a minor update, with mostly bug fixes in the SDK Manager. There’s also a new version of the Eclipse plug-in that embeds those fixes. For more info on the details, check the links of the SDK Tools revision 4 and the ADT (Android Development Tools) 0.9.5 release notes.

Go here to see the original:
A Few Updates to the Android SDK are Released

Pencils Down! ADC2 Voting Comes to End

The official Android Developers Blog has announced that public voting for the second Developers Challenge has come to a close .  We won’t have to wait too long to find out who the winners are as they will be announced this coming Monday, November 30 th ! Thanks to tens of thousands of Android users around the world who participated in the review of ADC 2 finalist applications, we have now collected sufficient scores to complete 2nd round public judging. We are reviewing the final results and will announce the top winners this coming Monday, November 30. Thanks to all who’ve participated in ADC 2 and good luck to all the finalists. Anyone have a favorite or dark horse in the race? Popular Posts That You Might Enjoy! November 18, 2009 — Hey Developers – Mark Your Calendars for DroidCon London (5) November 14, 2009 — Google Pushes Source Code for Android 2.0 – Developers Push it to G1 Within Hours (26) October 11, 2009 — Developers Can Now Target By Carrier in Android Market (14) November 19, 2009 — Android Market Acting Up for Developers [RESOLVED] (19) November 5, 2009 — ADC2 Results Going Out to Developers (11)

See more here: 
Pencils Down! ADC2 Voting Comes to End

Week-old Android build demoed on TI uber-dev-device

Texas Instruments were demonstrating their Zoom OMAP34x-II Mobile Development Platform at Mobile World Congress this week, and among the software was a very recent build of Android.  In fact, according to the TI staff, the Android build they’re running is only a week old. The Zoom is intended for developers interested in coding for the OMAP3 chipset, and has a 4.1-inch capacitive touchscreen running at WVGA resolution, HDMI out, WiFi and optional 3G, together with 16GB of storage plus an SD card slot, a QWERTY keypad and an 8-megapixel camera.  TI will happily sell them to consumers, too, though you’ll need deep pockets: the WiFi-only version is priced at $1,150 while the 3G-equipped Zoom comes in at $1,399. We asked TI whether they had forked from the standard Android build, and they were at pains to say no; they’ve been feeding back in their code developments to the Open Handset Alliance.  Check out the demo video, which shows just how well the TI Zoom runs the Google OS. Click here to view the embedded video.

View original post here: 
Week-old Android build demoed on TI uber-dev-device