Today we are announcing Android 4.4 KitKat, a new version of Android that brings great new features for users and developers.
The very first device to run Android 4.4 is the new Nexus 5, available today on Google Play, and coming soon to other retail outlets. We’ll also be rolling out the Android 4.4 update worldwide in the next few weeks to all Nexus 4, Nexus 7, and Nexus 10 devices, as well as the Samsung Galaxy S4 and HTC One Google Play Edition devices.
As part of this release, we kicked off Project Svelte, an effort to reduce the memory needs of Android so that it can run on a much broader range of devices, including entry-level devices that have as little as 512MB RAM. From the kernel to system, frameworks, and apps, we've reduced memory footprint and improved memory management so Android can run comfortably on only 512MB of RAM. We did this not only on Android but across Google apps, like Chrome and YouTube.
By supporting a broader range of devices, Android 4.4 will help move the Android ecosystem forward. Now all users will be able to enjoy the very best that Android has to offer, on the devices that best meet their needs.
Here’s a quick look at some of the new features for developers:
There's a lot more, so be sure to check out the Android 4.4 platform highlights for a complete overview of those and other new capabilities for developers. For details on the APIs and how to use them, take a look at the API Overview or watch one of the new DevBytes videos on KitKat.
Along with the new Android 4.4 platform we're releasing a new version of the Android NDK (r9b). The new NDK gives you native access to RenderScript and other stable APIs in Android 4.4, so if you've been waiting to use RenderScript from your native code, give it a try.
Last, we've updated the Support Package (r19) with a new helper library for printing images through the new printing framework, as well as other updates.
You can get started developing and testing on Android 4.4 right away, in Android Studio or in ADT/Ant. You can download the Android 4.4 Platform (API level 19), as well as the SDK Tools, Platform Tools, and Support Package from the Android SDK Manager.
Today we're launching a new release of Google Play services. Version 4.0 includes the Google Mobile Ads SDK, and offers improvements to geofencing, Google+, and Google Wallet Instant Buy APIs.
With over 97% of devices now running Android 2.3 (Gingerbread) or newer platform versions, we’re dropping support for Froyo from this release of the Google Play services SDK in order to make it possible to offer more powerful APIs in the future. That means you will not be able to utilize these new APIs on devices running Android 2.2 (Froyo).
We’re still in the process of rolling out to Android devices across the world, but you can already download the latest Google Play services SDK and start developing against the new APIs using the new Android 4.4 (KitKat) emulator.
If you’re using AdMob to monetize your apps, the new Google Mobile Ads SDK in Google Play services helps provide seamless improvements to your users. For example, bug fixes get pushed automatically to users without you having to do anything. Check out the post on the Google Ads Developer Blog for more details.
The Maps and Geofencing APIs that launched in Google Play services 3.1 have been updated to improve overall battery efficiency and responsiveness.
You can save power by requesting larger latency values for notifications alerting your app to users entering or exiting geofences, or request that entry alerts are sent only after a user stays within a geofence for a specified period of time. Setting generous dwell times helps to eliminate unwanted notifications when a user passes near a geofence or their location is seen to move across a boundary.
The Maps API enhances map customization features, letting you specify marker opacity, fade-in effects, and visibility of 3D buildings. It’s also now possible to change ground overlay images.
Apps that are enabled with Google+ Sign-In will be updated with a simplified sign-in consent dialog. Google Wallet Instant Buy APIs are now available to everyone to try out within a sandbox, with a simplified API that streamlines the buy-flow and reduces integration time.
Google Wallet Instant Buy also includes new Wallet Objects, which means you can award loyalty points to a user's saved rewards program ID for each applicable Google Wallet Instant Buy purchase.
To give users better controls and to provide you with a simple, standard system to continue to monetize your apps, this update contains a new, anonymous identifier for advertising purposes (to be used in place of Android ID). Google Settings now includes user controls that enable users to reset this identifier, or opt out of interest-based ads for Google Play apps.
To learn more about Google Play services and the APIs available to you through it, visit the Google Services area of the Android Developers site.
Posted by Chaesang Jung, Software Engineer
There are many reasons to build or not to build a mobile app as part of your broader mobile strategy. For instance, while apps offer a rich user experience, users can’t access them through Google Search like they do websites. Today, we’re announcing a new Google Search capability, app indexing, that will start to make apps more accessible through Google on Android.
Let’s say that a user is searching for a movie. With app indexing, Google will begin to include deep links to apps in Android search results. When the user taps on the “Open in app” deep links, the app opens up directly to the movie in question.
In this example, in order for the app deep links to appear in search results,
The end result is that users will have a seamless search experience when accessing your app content through Google.
Google is currently testing app indexing with an initial group of developers including AllTheCooks, AllTrails, Beautylish, Etsy, Expedia, Flixster, Healthtap, IMDb, moviefone, newegg, OpenTable, Trulia, and Wikipedia. Deep links for these applications will start to appear in Google search results on Android, in the US, in a few weeks.
If you are interested in enabling indexing for your Android app, you can learn more about our developer guidelines at developers.google.com/app-indexing and sign up. We are expanding our app indexing efforts and will gradually include more developers over time.
Posted by Scott Main and David Braun
Sending and receiving SMS messages are fundamental features on mobile devices and many developers have built successful apps that enhance this experience on Android. Some of you have built SMS apps using hidden APIs—a practice we discourage because hidden APIs may be changed or removed and new devices are not tested against them for compatibility. So, to provide you with a fully supported set of APIs for building SMS apps and to make the user experience for messaging more predictable, Android 4.4 (KitKat) makes the existing APIs public and adds the concept of a default SMS app, which the user can select in system settings.
This means that if you are using the hidden SMS APIs on previous platform versions, you need to make some adjustments so your app continues to work when Android 4.4 is released later this year.
On Android 4.4, only one app can receive the new SMS_DELIVER_ACTION intent, which the system broadcasts when a new SMS message arrives. Which app receives this broadcast is determined by which app the user has selected as the default SMS app in system settings. Likewise, only the default SMS app receives the new WAP_PUSH_DELIVER_ACTION intent when a new MMS arrives.
SMS_DELIVER_ACTION
WAP_PUSH_DELIVER_ACTION
Other apps that only want to read new messages can instead receive the SMS_RECEIVED_ACTION broadcast intent when a new SMS arrives. However, only the app that receives the SMS_DELIVER_ACTION broadcast (the user-specified default SMS app) is able to write to the SMS Provider defined by the android.provider.Telephony class and subclasses. As such, it's important that you update your messaging app as soon as possible to be available as a default SMS app, because although your existing app won't crash on an Android 4.4 device, it will silently fail when attempting to write to the SMS Provider.
SMS_RECEIVED_ACTION
android.provider.Telephony
In order for your app to appear in the system settings as an eligible default SMS app, your manifest file must declare some specific capabilities. So you must update your app to do the following things:
"android.provider.Telephony.SMS_DELIVER"
This allows your app to directly receive incoming SMS messages.
"android.provider.Telephony.WAP_PUSH_DELIVER"
"application/vnd.wap.mms-message"
BROADCAST_WAP_PUSH
This allows your app to directly receive incoming MMS messages.
ACTION_SENDTO
"android.intent.action.SENDTO"
sms:
smsto:
mms:
mmsto:
This allows your app to receive intents from other apps that want to deliver a message.
ACTION_RESPONSE_VIA_MESSAGE
"android.intent.action.RESPOND_VIA_MESSAGE"
SEND_RESPOND_VIA_MESSAGE
This allows users to respond to incoming phone calls with an immediate text message using your app.
For example, here's a manifest file with the necessary components and intent filters:
<manifest> ... <application> <!-- BroadcastReceiver that listens for incoming SMS messages --> <receiver android:name=".SmsReceiver" android:permission="android.permission.BROADCAST_SMS"> <intent-filter> <action android:name="android.provider.Telephony.SMS_DELIVER" /> </intent-filter> </receiver> <!-- BroadcastReceiver that listens for incoming MMS messages --> <receiver android:name=".MmsReceiver" android:permission="android.permission.BROADCAST_WAP_PUSH"> <intent-filter> <action android:name="android.provider.Telephony.WAP_PUSH_DELIVER" /> <data android:mimeType="application/vnd.wap.mms-message" /> </intent-filter> </receiver> <!-- Activity that allows the user to send new SMS/MMS messages --> <activity android:name=".ComposeSmsActivity" > <intent-filter> <action android:name="android.intent.action.SEND" /> <action android:name="android.intent.action.SENDTO" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="sms" /> <data android:scheme="smsto" /> <data android:scheme="mms" /> <data android:scheme="mmsto" /> </intent-filter> </activity> <!-- Service that delivers messages from the phone "quick response" --> <service android:name=".HeadlessSmsSendService" android:permission="android.permission.SEND_RESPOND_VIA_MESSAGE" android:exported="true" > <intent-filter> <action android:name="android.intent.action.RESPOND_VIA_MESSAGE" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="sms" /> <data android:scheme="smsto" /> <data android:scheme="mms" /> <data android:scheme="mmsto" /> </intent-filter> </service> </application> </manifest>
Any filters for the SMS_RECEIVED_ACTION broadcast in existing apps will continue to work the same on Android 4.4, but only as an observer of new messages, because unless your app also receives the SMS_DELIVER_ACTION broadcast, you cannot write to the SMS Provider on Android 4.4.
Beginning with Android 4.4, you should stop listening for the SMS_RECEIVED_ACTION broadcast, which you can do at runtime by checking the platform version then disabling your broadcast receiver for SMS_RECEIVED_ACTION with PackageManager.setComponentEnabledSetting(). However, you can continue listening for that broadcast if your app needs only to read special SMS messages, such as to perform phone number verification. Note that—beginning with Android 4.4—any attempt by your app to abort the SMS_RECEIVED_ACTION broadcast will be ignored so all apps interested have the chance to receive it.
PackageManager.setComponentEnabledSetting()
Tip: To distinguish the two SMS broadcasts, imagine that the SMS_RECEIVED_ACTION simply says "the system received an SMS," whereas the SMS_DELIVER_ACTION says "the system is delivering your app an SMS, because you're the default SMS app."
In consideration of some apps that do not want to behave as the default SMS app but still want to send messages, any app that has the SEND_SMS permission is still able to send SMS messages using SmsManager. If and only if an app is not selected as the default SMS app on Android 4.4, the system automatically writes the sent SMS messages to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider).
SEND_SMS
SmsManager
However, if your app is designed to behave as the default SMS app, then while your app is not selected as the default, it's important that you understand the limitations placed upon your app and disable features as appropriate. Although the system writes sent SMS messages to the SMS Provider while your app is not the default SMS app, it does not write sent MMS messages and your app is not able to write to the SMS Provider for other operations, such as to mark messages as draft, mark them as read, delete them, etc.
So when your messaging activity resumes, check whether your app is the default SMS app by querying Telephony.Sms.getDefaultSmsPackage(), which returns the package name of the current default SMS app. If it doesn't match your package name, disable features such as the ability for users to send new messages.
Telephony.Sms.getDefaultSmsPackage()
When the user decides to use your app for messaging, you can display a dialog hosted by the system that allows the user to make your app the default SMS app. To display the dialog, call startActivity() with the Telephony.Sms.Intents.ACTION_CHANGE_DEFAULT intent, including an extra with the Sms.Intents.EXTRA_PACKAGE_NAME key and your package name as the string value.
startActivity()
Telephony.Sms.Intents.ACTION_CHANGE_DEFAULT
Sms.Intents.EXTRA_PACKAGE_NAME
For example, your activity might include code like this:
public class ComposeSmsActivity extends Activity { @Override protected void onResume() { super.onResume(); final String myPackageName = getPackageName(); if (!Telephony.Sms.getDefaultSmsPackage(this).equals(myPackageName)) { // App is not default. // Show the "not currently set as the default SMS app" interface View viewGroup = findViewById(R.id.not_default_app); viewGroup.setVisibility(View.VISIBLE); // Set up a button that allows the user to change the default SMS app Button button = (Button) findViewById(R.id.change_default_app); button.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { Intent intent = new Intent(Telephony.Sms.Intents.ACTION_CHANGE_DEFAULT); intent.putExtra(Telephony.Sms.Intents.EXTRA_PACKAGE_NAME, myPackageName); startActivity(intent); } }); } else { // App is the default. // Hide the "not currently set as the default SMS app" interface View viewGroup = findViewById(R.id.not_default_app); viewGroup.setVisibility(View.GONE); } } }
Because the ability to write to the SMS Provider is restricted to the app the user selects as the default SMS app, any existing app designed purely to backup and restore SMS messages will currently be unable to restore SMS messages on Android 4.4. An app that backs up and restores SMS messages must also be set as the default SMS app so that it can write messages in the SMS Provider. However, if the app does not also send and receive SMS messages, then it should not remain set as the default SMS app. So, you can provide a functional user experience with the following design when the user opens your app to initiate a one-time restore operation:
String defaultSmsApp = Telephony.Sms.getDefaultSmsPackage(context);
Intent intent = new Intent(context, Sms.Intents.ACTION_CHANGE_DEFAULT); intent.putExtra(Sms.Intents.EXTRA_PACKAGE_NAME, context.getPackageName()); startActivity(intent);
Intent intent = new Intent(context, Sms.Intents.ACTION_CHANGE_DEFAULT); intent.putExtra(Sms.Intents.EXTRA_PACKAGE_NAME, defaultSmsApp); startActivity(intent);
We encourage you to update your apps as soon as possible to provide your users the best experience on Android. To help you make the changes, we'll soon be providing the necessary SDK components for Android 4.4 that allow you to compile and test your changes on Android 4.4. Stay tuned!
Posted by Ellie Powers, Google Play team
Fueled by the Nexus 7 and other great devices, more than 70 million Android tablets have been activated. Thousands of developers have already designed their apps to look great on tablets, and with the holidays fast approaching, we’re making it even easier for the next wave of tablet owners to discover great apps and games.
Last year, Google Play added a “designed for tablets” section, where users could easily discover apps that look great on their 7”- and 10”-tablets. This section includes only apps and games which meet criteria and guidelines we established last year. (Here’s an overview if you missed it.) Developers who invest the time to meet the criteria are seeing great results; take Remember The Milk, which saw an 83% increase in tablet downloads from being in this section. (see the whole story here).
On November 21 2013, the Play Store made a series of changes so it’s even easier for tablet users to find those apps that are best for their devices. First, by default, users browsing Google Play on a tablet will now see apps and games that are designed for tablets on the top lists (Top Paid, Top Free, Top Grossing, Top New Paid, Top New Free, and Trending). Tablet users will still be able to switch the view so they can see all apps or games if they choose. Also starting November 21, apps and games that do not meet the “designed for tablets” criteria will be marked as “designed for phones” for users who browse the Play Store on tablets.
You’ll want to make sure that your app is designed for tablets; read more about how to do this at the end of this blog post.
If you want to be sure your app is included in the “Designed for tablets” view, go to the Developer Console to check your tablet optimization tips. If you see any issues listed there, you’ll need to address them in your app and upload a new binary for distribution. If there are no issues listed, your app is eligible to be included in the “Designed for tablets" view in the top lists.
Also, make sure to read the full tablet quality checklist to understand how to build outstanding tablet experiences.
Everyday, thousands of Android developers are taking advantage of the tremendous Android tablet opportunity. The flood of new users coupled with the increased screen size means new user experiences, more engagement and more monetization opportunities. We’re excited to see what you do!
Posted by Greg Hartrell, Google Play Games team
Mobile games are on fire right now; in fact, three out of every four Android users are playing games. Earlier in the year we launched Google Play Games — Google’s platform for gaming across Android, iOS, and the web — to help you take advantage of this wave of users. Building on Google Play Services, you can quickly add new social features to your games, for richer game experiences that drive user acquisition and engagement across platforms.
Today we’re announcing three new features in Google Play Games that make it easier to understand what players are doing in your game, manage your game features more effectively, and store more game data in the Google cloud.
Now you can see stats about your game’s player activity in Google Play Games right in the Google Play Developer Console. You can see how many players have signed into your game through Google, the percentage of players who unlocked an achievement, and how many scores are posted to your leaderboards.
Did you mangle the ID for an achievement or leaderboard? Forget to hit the publish button? Do you know if your game is getting throttled because you accidentally called a method in a tight loop? Fear not! New alerts will now show up in the Developer Console to warn you when these mistakes happen, and guide you quickly to the answers on how to fix them.
Cloud Save is one of our most popular features for game developers, providing up to 512KB of data per user, per game, since it was introduced. You asked for more storage, and we are delivering on that request. Starting October 14th, 2013, you’ll be able to store up to 256KB per slot, for a total of 1MB per user. Game saves have never been happier!
If you want learn more about what Google Play Games offers and how to get started, take a look at the Google Play Games Services developer documentation.
A key part of growing your app’s installed base is knowing more about your users — how they discover your app, what devices they use, what they do when they use your app, and how often they return to it. Understanding your users is now made easier through a new integration between Google Analytics and the Google Play Developer Console.
Starting today, you can link your Google Analytics account with your Google Play Developer Console to get powerful new insights into your app’s user acquisition and engagement. In Google Analytics, you’ll get a new report highlighting which campaigns are driving the most views, installs, and new users in Google Play. In the Developer Console, you’ll get new app stats that let you easily see your app’s engagement based on Analytics data.
This combined data can help you take your app business to the next level, especially if you’re using multiple campaigns or monetizing through advertisements and in-app products that depend on high engagement. Linking Google Analytics to your Developer Console is straightforward — the sections below explain the new types of data you can get and how to get started.
Once you’ve linked your Analytics account to your Developer Console, you’ll see a new report in Google Analytics called Google Play Referral Flow. This report details each of your campaigns and the user traffic that they drive. For each campaign, you can see how many users viewed listing page in Google Play and how many went on to install your app and ultimately launch it on their mobile devices.
With this data you can track the effectiveness of a wide range of campaigns — such as blogs, news articles, and ad campaigns — and get insight into which marketing activities are most effective for your business. You can find the Google Play report by going to Google Analytics and clicking on Acquisitions > Google Play > Referral Flow.
If you’re already using Google Analytics, you know how important it is to see how users are interacting with your app. How often do they launch it? How much do they do with it? What are they doing inside the app?
Once you link your Analytics account, you’ll be able to see your app’s engagement data from Google Analytics right in the Statistics page in your Developer Console. You’ll be able to select two new metrics from the drop-down menu at the top of the page:
These engagement metrics are integrated with your other app statistics, so you can analyze them further across other dimensions, such as by country, language, device, Android version, app version, and carrier.
To get started, you first need to integrate Google Analytics into your app. If you haven’t done this already, download the Google Analytics SDK for Android and then take a look at the developer documentation to learn how to add Analytics to your app. Once you’ve integrated Analytics into your app, upload the app to the Developer Console.
Next, you’ll need to link your Developer Console to Google Analytics. To do this, go to the Developer Console and select the app. At the bottom of the Statistics page, you’ll see directions about how to complete the linking. The process takes just a few moments.
That’s it! You can now see both the Google Play Referral Flow report in Google Analytics and the new engagement metrics in the Developer Console.
.png)
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
.png)
