Group items tagged

Authentication with App Engine, regardless of where you're doing it, is a three-stage process: Obtain an authentication token. This can be done with ClientLogin for installed apps, for example, or with AuthSub for a webapp. When logging in directly to an application, this is the part of the login process where your user sees a Google signin screen. Take that authentication token, and use it to obtain an authentication cookie. Use that authentication cookie in all subsequent requests.

<uses-permission android:name="android.permission.GET_ACCOUNTS"></uses-permission> <uses-permission android:name="android.permission.USE_CREDENTIALS"></uses-permission> <uses-permission android:name="android.permission.INTERNET"></uses-permission>

final ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);  am.restartPackage(getPackageName());  

<uses-permission android:name="android.permission.RESTART_PACKAGES"></uses-permission>  

I had the same issue. Along with including android:xlargeScreens="true" I found this to be the fix.

The Android Market treats as though requesting a permission like CALL_PHONE also requests: <uses-feature android:name="android.hardware.telephony" /> The XOOM does not have telephony — the first Android Market-compliant device with that limitation. While it can have a data plan, it has no voice or SMS capability, and so it is treated as not having android.hardware.telephony. But, if you request permissions like CALL_PHONE, the Android Market by default will assume you need android.hardware.telephony. As a result, you will be filtered out of the Market for the XOOM. The solution is simple: for any hardware features that might be implied by permissions but that you do not absolutely need, manually add the appropriate element to your manifest with android:required="false": <uses-feature android:name="android.hardware.telephony" android:required="false" />

It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it. C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages. An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.

It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

C2DM imposes the following limitations: The message size limit is 1024 bytes. Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device

does not

request to Android Market