Skypop on Android
Bruce Leak and Timo Bruck from SkyPop demo a couple of their new applications for Android.
Saturday, August 30, 2008
Skypop on Android
Skypop on Android
Bruce Leak and Timo Bruck from SkyPop demo a couple of their new applications for Android.
Android Market Images and Features
Go to ImageShack® to Create your own Slideshow
The Android Market is an open content distribution system that will help end users find, purchase, download and install various types of content on their Android-powered devices. The concept is simple: leverage Google's expertise in infrastructure, search and relevance to connect users with content created by developers like you.
Developers will be able to make their content available on an open service hosted by Google that features a feedback and rating system similar to YouTube. Similar to YouTube, content can debut in the marketplace after only
three simple steps: register as a merchant, upload and describe your
content and publish it.
More information Here
Android App: Life360
Created by Chris Hulls, Dilpreet Singh, Luis Carvalho, Phuong Nguyen, Steve Potell
Life360 uses a multi-channel messaging system and neighborhood-centric
social network to keep you up-to-date and in contact with your family
and local community. Fire warning in your area? You’ll hear about it
right away and can instantly let your entire family know you are safe.
Dog ran off and you want to ask your neighbors for help? Post a request
on the map that everyone nearby will see.
Using Android’s always-on networking capabilities, Life360 can ensure
you always stay in contact with your family and know when important
events happen in your area. Unlike most emergency alerts, these are
specifically customized to you.
Track your family on the map, know everyone’s status instantly, and
access their important medical information and emergency profiles. Get
in an accident? Life360 monitors the accelerometer to detect if you are
in a collision and automatically displays your emergency data onscreen
when you need it.
A location-based message board where you can ask for help and assist
others. Unlike other social networks, this one isn’t about interacting
with friends, but helping your neighborhood overcome challenges as a
group. Need help in a hurry? Push panic and we will notify everyone
nearby.
Life360 uses a multi-channel messaging system and neighborhood-centric
social network to keep you up-to-date and in contact with your family
and local community. Fire warning in your area? You’ll hear about it
right away and can instantly let your entire family know you are safe.
Dog ran off and you want to ask your neighbors for help? Post a request
on the map that everyone nearby will see.
Using Android’s always-on networking capabilities, Life360 can ensure
you always stay in contact with your family and know when important
events happen in your area. Unlike most emergency alerts, these are
specifically customized to you.
Track your family on the map, know everyone’s status instantly, and
access their important medical information and emergency profiles. Get
in an accident? Life360 monitors the accelerometer to detect if you are
in a collision and automatically displays your emergency data onscreen
when you need it.
A location-based message board where you can ask for help and assist
others. Unlike other social networks, this one isn’t about interacting
with friends, but helping your neighborhood overcome challenges as a
group. Need help in a hurry? Push panic and we will notify everyone
nearby.
Android App: Compare Everywhere
Created by Jeffrey Sharkey
Scan a barcode to instantly check if that "sale price" really is a good
deal. Read reviews to find out if those hiking boots will last a
lifetime, or fall apart next month. Keep track of shopping lists, wish
lists, and more.
Use the built-in camera to effortlessly scan barcodes, making shopping a breeze.
Compare prices across dozens of stores in only a few seconds.
Use GPS to find nearby stores, then call them directly, or find driving directions using Google Maps.
Scan a barcode to instantly check if that "sale price" really is a good
deal. Read reviews to find out if those hiking boots will last a
lifetime, or fall apart next month. Keep track of shopping lists, wish
lists, and more.
Use the built-in camera to effortlessly scan barcodes, making shopping a breeze.
Compare prices across dozens of stores in only a few seconds.
Use GPS to find nearby stores, then call them directly, or find driving directions using Google Maps.
Android App: cab4me
cab4me enables you to easily call a cab to any location worldwide. You
do not need to know the number of the local cab company. You do not
need to enter or even know the address you want to be picked up at. You
do not need to place a call. With cab4me you can order a cab to your
current location with a single click.
cab4me integrates the Google Maps component provided by Android. This
enables the user to select their cab destination by simply moving the
map. Cab4me shows places where cabs usually wait as overlays and uses
geocoding extensions to find and display addresses.
cab4me uses the location awareness of Android (GPS and cell-based), to
make it easy for the user to order a cab to his current location
without the need to know the exact address or to know the name of the
cab company.
cab4me integrates the phone’s contact list to select pickup locations.
It can initiate calls to a cab company and uses notification services
to inform the user about the current cab order status.
App Created by Konrad Huebner,
Henning Boeger
do not need to know the number of the local cab company. You do not
need to enter or even know the address you want to be picked up at. You
do not need to place a call. With cab4me you can order a cab to your
current location with a single click.
cab4me integrates the Google Maps component provided by Android. This
enables the user to select their cab destination by simply moving the
map. Cab4me shows places where cabs usually wait as overlays and uses
geocoding extensions to find and display addresses.
cab4me uses the location awareness of Android (GPS and cell-based), to
make it easy for the user to order a cab to his current location
without the need to know the exact address or to know the name of the
cab company.
cab4me integrates the phone’s contact list to select pickup locations.
It can initiate calls to a cab company and uses notification services
to inform the user about the current cab order status.
App Created by Konrad Huebner,
Henning Boeger
Thursday, August 28, 2008
Android Market: a user-driven content distribution system
When we talk to developers, a common topic is the challenge of getting applications in the hands of users. That's why today I'm happy to share early details of Android Market—an open content distribution system that will help end users find, purchase, download and install various types of content on their Android-powered devices. The concept is simple: leverage Google's expertise in infrastructure, search and relevance to connect users with content created by developers like you.
Developers will be able to make their content available on an open service hosted by Google that features a feedback and rating system similar to YouTube. We chose the term "market" rather than "store" because we feel that developers should have an open and unobstructed environment to make their content available. Similar to YouTube, content can debut in the marketplace after only three simple steps: register as a merchant, upload and describe your content and publish it. We also intend to provide developers with a useful dashboard and analytics to help drive their business and ultimately improve their offerings.
I also wanted to share some early details to help with planning your efforts so that you can be ready as our partners release the first Android-powered handsets. Developers can expect the first handsets to be enabled with a beta version of Android Market. Some decisions are still being made, but at a minimum you can expect support for free (unpaid) applications. Soon after launch an update will be provided that supports download of paid content and more features such as versioning, multiple device profile support, analytics, etc. Below are some screenshots that illustrate some of the security features and workflow.
With the addition of a marketplace, the Android ecosystem is becoming even more robust. I am incredibly energized by the support and amazing content I've seen so far. We will share more details as they are available and I look forward to working with many of you in the coming months.
Source: Android Blog
Developers will be able to make their content available on an open service hosted by Google that features a feedback and rating system similar to YouTube. We chose the term "market" rather than "store" because we feel that developers should have an open and unobstructed environment to make their content available. Similar to YouTube, content can debut in the marketplace after only three simple steps: register as a merchant, upload and describe your content and publish it. We also intend to provide developers with a useful dashboard and analytics to help drive their business and ultimately improve their offerings.
I also wanted to share some early details to help with planning your efforts so that you can be ready as our partners release the first Android-powered handsets. Developers can expect the first handsets to be enabled with a beta version of Android Market. Some decisions are still being made, but at a minimum you can expect support for free (unpaid) applications. Soon after launch an update will be provided that supports download of paid content and more features such as versioning, multiple device profile support, analytics, etc. Below are some screenshots that illustrate some of the security features and workflow.
With the addition of a marketplace, the Android ecosystem is becoming even more robust. I am incredibly energized by the support and amazing content I've seen so far. We will share more details as they are available and I look forward to working with many of you in the coming months.
Source: Android Blog
Wednesday, August 27, 2008
Why Google Removed some API's from Android 0.9 SDK Beta
From Android Developers Blog
GTalkService
We were all really excited when the "XMPPService" (as it was called, at first) was included in the first early-look SDK. Once we brought in our security review team to examine Android, however, they soon realized that, as exciting as it is, the GTalkService has some fundamental security problems. Rich Cannings is one of our security researchers, and here's his explanation of the issues:
When I first read about GTalkService, I was both excited and scared. As a developer, I was interested in a feature that provided a simple interface to send messages between two Google Talk friends. The messages would appear on the receiving device as a standard Intent that was easy to handle. How simple and beautiful is that? Unfortunately, when I put my tin foil hat on, I recognized that things are a little more complicated than that.
We decided to postpone GTalkService's data-messaging functionality for the following reasons:
1. "Repurposing" Google Talk Friends
Google Talk friends are intended for a different purpose than that envisioned by the GTalkService. Your Google Talk friends can contact you at any time via IM. They can see your email address and often can see your real name. However, the idea of a Google Talk friend does not always line up with the types of people who may want to interact with via an Android application. For example, imagine a really cool mobile Massively Multiplayer Online Roleplaying Game using GTalkService. You would have to add all the players to your Google Talk friends list in order to play with them. Next time you log in to Google Talk from your desktop or on the web, you would notice that you have many new "friends". You may not want to chat with these friends -- and perhaps worse, you may not want them to know what your real name or email is. We do realize that Android users will want to interact with other Android users anonymously and for short periods of time, especially in gaming scenarios. Unfortunately, it turns out that using Instant Messaging is not really a good way to do that.
2. Verifying Remote Intent Senders
Intents were designed to send messages within the device. The Intent subsystem can conclusively determine who sent Intents only when the Intents originate from the same device that services the Intent. When Intents come from other devices, the Intent subsystem cannot determine what application sent the Intent. This can lead to a variety of problems. At first, remote applications could send arbitrary Intents, meaning that your Google Talk friends had almost the same control of your device as you did. Even once that issue was resolved, we recognized that we could not trust the identity of the application who sent the request. We could only trust the identity of the user. So a "bad" application on your friend's device could send a message to a "good" application on your device which would negatively affect the good application. In the end, we determined that the Intent system, as designed for local use, did not lend itself well to being the vehicle for a Remote Procedure Call (RPC).
3. Placing Too Much Security Burden on Developers
As originally designed, the GTalkService placed a significant burden on the application developer to avoid security flaws and perform user and relationship management. An Android application using GTalkService would be reachable from all of the user's Google Talk friends, and a flaw in that application could pose an inviting target to a malicious "friend" or automated malware. There are automated mechanisms that could be used to help protect vulnerable applications or stop the spread of malware, but the deployment of these technologies was not possible in time for the launch of the first Android handsets.
Although we would have loved to ship this service, in the end, the Android team decided to pull the API instead of exposing users to risk and breaking compatibility with a future, more secure version of the feature. We think it's obvious that this kind of functionality would be incredibly useful, and would open lots of new doors for developers. One of our top priorities after the first devices ship is to develop a device-to-device (and possibly device-to-server) RPC mechanism that is fast, reliable, and protective of developers and users alike.
As a final note, I want to point out that since the GTalkService was always a Google "value-added" service anyway, it was never guaranteed that it would be present on every Android device. That is, GTalkService was never part of core Android. As a result this change actually allows us the potential to build a new system that is part of the core of a future version of Android.
Bluetooth API
The 1.0 version of Android and the first devices will include support for Bluetooth; for instance, Android will support Bluetooth headsets. In the early-look SDKs, there was an incomplete draft of an API that exposed Bluetooth functionality to developers. Unfortunately we had to remove that API from the 1.0 release. To get the skinny on why, I contacted Nick Pelly, one of the Android engineers responsible for that functionality. Here's the story on Bluetooth, in Nick's words:
The reason is that we plain ran out of time. The Android Bluetooth API was pretty far along, but needs some clean-up before we can commit to it for the SDK. Keep in mind that putting it in the 1.0 SDK would have locked us into that API for years to come.
Here's an example of the problems in the API. Client code is required to pass around IBluetoothDeviceCallback objects in order to receive asynchronous callbacks, but IBluetoothDeviceCallback is meant to be an internal interface. That client code would break the moment we added new callbacks to IBluetoothDeviceCallback.aidl. This is not a recipe for future-proof apps.
To make things even more tricky, the recent introduction of the bluez 4.x series brings its own new API. The Android Bluetooth stack uses bluez for GAP and SDP so you'll see more than a passing resemblance to bluez's interfaces in Android. The bluez 4.x change requires us to carefully consider how to structure our API for the future. Again, remember that once we settle on an interface we need to support it for years going forward.
Rather than ship a broken API that we knew was going to change a lot, we chose not to include it. We absolutely intend to support a Bluetooth API in a future release, although we don't know exactly when that will be. This should include some tasty features, such as:
* Bindings to GAP and SDP functionality.
* Access to RFCOMM and SCO sockets.
* Potentially, L2CAP socket support from Java. (This one is under consideration.)
* An API to our headset and handsfree profiles.
On a personal note, Nick adds, "I would love nothing more than to start seeing some neat third-party applications and games over Bluetooth. In my opinion, Bluetooth is completely under-utilized on most mobile platforms and I'm excited to someday see what the developer community can do with Android."
I'm definitely bummed about these API removals. I was particularly looking forward to the P2P capabilities offered by GTalkService, but, as always, user security and privacy must come first. In all these cases, we'll work with the developer community to create some great APIs that balance these concerns.
GTalkService
We were all really excited when the "XMPPService" (as it was called, at first) was included in the first early-look SDK. Once we brought in our security review team to examine Android, however, they soon realized that, as exciting as it is, the GTalkService has some fundamental security problems. Rich Cannings is one of our security researchers, and here's his explanation of the issues:
When I first read about GTalkService, I was both excited and scared. As a developer, I was interested in a feature that provided a simple interface to send messages between two Google Talk friends. The messages would appear on the receiving device as a standard Intent that was easy to handle. How simple and beautiful is that? Unfortunately, when I put my tin foil hat on, I recognized that things are a little more complicated than that.
We decided to postpone GTalkService's data-messaging functionality for the following reasons:
1. "Repurposing" Google Talk Friends
Google Talk friends are intended for a different purpose than that envisioned by the GTalkService. Your Google Talk friends can contact you at any time via IM. They can see your email address and often can see your real name. However, the idea of a Google Talk friend does not always line up with the types of people who may want to interact with via an Android application. For example, imagine a really cool mobile Massively Multiplayer Online Roleplaying Game using GTalkService. You would have to add all the players to your Google Talk friends list in order to play with them. Next time you log in to Google Talk from your desktop or on the web, you would notice that you have many new "friends". You may not want to chat with these friends -- and perhaps worse, you may not want them to know what your real name or email is. We do realize that Android users will want to interact with other Android users anonymously and for short periods of time, especially in gaming scenarios. Unfortunately, it turns out that using Instant Messaging is not really a good way to do that.
2. Verifying Remote Intent Senders
Intents were designed to send messages within the device. The Intent subsystem can conclusively determine who sent Intents only when the Intents originate from the same device that services the Intent. When Intents come from other devices, the Intent subsystem cannot determine what application sent the Intent. This can lead to a variety of problems. At first, remote applications could send arbitrary Intents, meaning that your Google Talk friends had almost the same control of your device as you did. Even once that issue was resolved, we recognized that we could not trust the identity of the application who sent the request. We could only trust the identity of the user. So a "bad" application on your friend's device could send a message to a "good" application on your device which would negatively affect the good application. In the end, we determined that the Intent system, as designed for local use, did not lend itself well to being the vehicle for a Remote Procedure Call (RPC).
3. Placing Too Much Security Burden on Developers
As originally designed, the GTalkService placed a significant burden on the application developer to avoid security flaws and perform user and relationship management. An Android application using GTalkService would be reachable from all of the user's Google Talk friends, and a flaw in that application could pose an inviting target to a malicious "friend" or automated malware. There are automated mechanisms that could be used to help protect vulnerable applications or stop the spread of malware, but the deployment of these technologies was not possible in time for the launch of the first Android handsets.
Although we would have loved to ship this service, in the end, the Android team decided to pull the API instead of exposing users to risk and breaking compatibility with a future, more secure version of the feature. We think it's obvious that this kind of functionality would be incredibly useful, and would open lots of new doors for developers. One of our top priorities after the first devices ship is to develop a device-to-device (and possibly device-to-server) RPC mechanism that is fast, reliable, and protective of developers and users alike.
As a final note, I want to point out that since the GTalkService was always a Google "value-added" service anyway, it was never guaranteed that it would be present on every Android device. That is, GTalkService was never part of core Android. As a result this change actually allows us the potential to build a new system that is part of the core of a future version of Android.
Bluetooth API
The 1.0 version of Android and the first devices will include support for Bluetooth; for instance, Android will support Bluetooth headsets. In the early-look SDKs, there was an incomplete draft of an API that exposed Bluetooth functionality to developers. Unfortunately we had to remove that API from the 1.0 release. To get the skinny on why, I contacted Nick Pelly, one of the Android engineers responsible for that functionality. Here's the story on Bluetooth, in Nick's words:
The reason is that we plain ran out of time. The Android Bluetooth API was pretty far along, but needs some clean-up before we can commit to it for the SDK. Keep in mind that putting it in the 1.0 SDK would have locked us into that API for years to come.
Here's an example of the problems in the API. Client code is required to pass around IBluetoothDeviceCallback objects in order to receive asynchronous callbacks, but IBluetoothDeviceCallback is meant to be an internal interface. That client code would break the moment we added new callbacks to IBluetoothDeviceCallback.aidl. This is not a recipe for future-proof apps.
To make things even more tricky, the recent introduction of the bluez 4.x series brings its own new API. The Android Bluetooth stack uses bluez for GAP and SDP so you'll see more than a passing resemblance to bluez's interfaces in Android. The bluez 4.x change requires us to carefully consider how to structure our API for the future. Again, remember that once we settle on an interface we need to support it for years going forward.
Rather than ship a broken API that we knew was going to change a lot, we chose not to include it. We absolutely intend to support a Bluetooth API in a future release, although we don't know exactly when that will be. This should include some tasty features, such as:
* Bindings to GAP and SDP functionality.
* Access to RFCOMM and SCO sockets.
* Potentially, L2CAP socket support from Java. (This one is under consideration.)
* An API to our headset and handsfree profiles.
On a personal note, Nick adds, "I would love nothing more than to start seeing some neat third-party applications and games over Bluetooth. In my opinion, Bluetooth is completely under-utilized on most mobile platforms and I'm excited to someday see what the developer community can do with Android."
I'm definitely bummed about these API removals. I was particularly looking forward to the P2P capabilities offered by GTalkService, but, as always, user security and privacy must come first. In all these cases, we'll work with the developer community to create some great APIs that balance these concerns.
Friday, August 15, 2008
T-Mobile to be first Android Carrier
T-Mobile will be the first carrier to offer a mobile phone powered by Google’s Android software, according to people briefed on the company’s plans. The phone will be made by HTC, one of the largest makers of mobile phones in the world, and is expected to go on sale in the United States before Christmas, perhaps as early as October.
The high-end phone is expected to match many of the capabilities of Apple’s iPhone and other so-called smartphones that run software from Palm, Research in Motion, Microsoft and Nokia to access the Internet and perform computerlike functions.
The HTC phone, which many gadget sites are calling the “dream,” will have a touch screen, like the iPhone. But the screen also slides out to expose a full five-row keyboard. A video of the phone has been posted recently on YouTube. A person who has seen the HTC device said it matched the one in the video.
The phone’s release date depends on how soon the Federal Communications Commission certifies that the Google software and the HTC phone meet network standards. Executives at all three companies are hoping to announce the phone in September because they would benefit from holiday season sales. The people briefed on the discussions declined to be named because they were not authorized to discuss the project.
Read the rest here
Link
The high-end phone is expected to match many of the capabilities of Apple’s iPhone and other so-called smartphones that run software from Palm, Research in Motion, Microsoft and Nokia to access the Internet and perform computerlike functions.
The HTC phone, which many gadget sites are calling the “dream,” will have a touch screen, like the iPhone. But the screen also slides out to expose a full five-row keyboard. A video of the phone has been posted recently on YouTube. A person who has seen the HTC device said it matched the one in the video.
The phone’s release date depends on how soon the Federal Communications Commission certifies that the Google software and the HTC phone meet network standards. Executives at all three companies are hoping to announce the phone in September because they would benefit from holiday season sales. The people briefed on the discussions declined to be named because they were not authorized to discuss the project.
Read the rest here
Link
Monday, August 4, 2008
HTC: "Android handsets on track, Will launch before the end of the year"
HTC's chief financial officer, Hui-ming Cheng, has confirmed that the
company is on track to launch Android-based handsets before the end of
2008.
Cheng has been quoted as saying the first Android phones from HTC are
due to ship to "ODM" (original design manufacturer) clients in the
fourth quarter of this year.
HTC currently creates own-label branded handsets for T-Mobile - who is
a member of the Open Handset Alliance, with seperate confirmation from
T-Mobile will launch an Android handset by the end of the year
suggesting this is what could launch soon.
It's predicted that HTC will beat other manufacturers to market
with an Android phone, as the company were given a several month
headstart with access to the OS thanks to their role as the
manufacturer of the HTC "Dream" Android prototype.
company is on track to launch Android-based handsets before the end of
2008.
Cheng has been quoted as saying the first Android phones from HTC are
due to ship to "ODM" (original design manufacturer) clients in the
fourth quarter of this year.
HTC currently creates own-label branded handsets for T-Mobile - who is
a member of the Open Handset Alliance, with seperate confirmation from
T-Mobile will launch an Android handset by the end of the year
suggesting this is what could launch soon.
It's predicted that HTC will beat other manufacturers to market
with an Android phone, as the company were given a several month
headstart with access to the OS thanks to their role as the
manufacturer of the HTC "Dream" Android prototype.
Subscribe to:
Posts (Atom)