Originally posted on Google Developers Blog
Posted by Nathan Martz, Product Manager, Google Cardboard
Human beings experience sound in all directions—like when a fire truck zooms by, or when an airplane is overhead. Starting today, the Cardboard SDKs for Unity and Android support spatial audio, so you can create equally immersive audio experiences in your virtual reality (VR) apps. All your users need is their smartphone, a regular pair of headphones, and a Google Cardboard viewer.
Many apps create simple versions of spatial audio—by playing sounds from the left and right in separate speakers. But with today’s SDK updates, your app can produce sound the same way humans actually hear it. For example:
We built today’s updates with performance in mind, so adding spatial audio to your app has minimal impact on the primary CPU (where your app does most of its work). We achieve these results in a couple of ways:
It’s really easy to get started with the SDK’s new audio features. Unity developers will find a comprehensive set of components for creating soundscapes on Android, iOS, Windows and OS X. And native Android developers will now have a simple Java API for simulating virtual sounds and environments.
Check out our Android sample app (for developer reference only), browse the documentation on the Cardboard developers site, and start experimenting with spatial audio today. We’re excited to see (and hear) the new experiences you’ll create!
Today at Google I/O we announced a new IDE that’s built with the needs of Android developers in mind. It’s called Android Studio, it’s free, and it’s available now for you to try as an early access preview.
To develop Android Studio, we cooperated with JetBrains, creators of one of the most advanced Java IDEs available today. Based on the powerful, extensible IntelliJ IDEA Community Edition, we've added features that are designed specifically for Android development, that simplify and optimize your daily workflow.
We know you need a build system that adapts to your project requirements but extends further to your larger development environment. Android Studio uses a new build system based on Gradle that provides flexibility, customized build flavors, dependency resolution, and much more.
This new build system allows you to build your projects in the IDE as well as on your continuous integrations servers. The combination lets you easily manage complex build configurations natively, throughout your workflow, across all of your tools. Check out the preview documentation to get a better idea of what the new build system can do.
Android Studio includes a powerful code editor. It's based on the IntelliJ IDEA editor, which supports features such as smart editing, advanced code refactoring, and deep static code analysis.
Smart editing features such as inline resource lookups make it easier to read your code, while giving you instant access to edit code the backing resources. Advanced code refactoring gives you the power to transform your code across the scope of the entire project, quickly and safely.
We added static code analysis for Android development, helping you identify bugs more quickly. On top of the hundreds of code inspections that IntelliJ IDEA provides, we’ve added custom inspections. For example, we’ve added metadata to the Android APIs, that flag which methods can return null and which can’t, which constants are allowed for which methods, and so on. Android Studio uses that data to analyze your code and find potential errors.
Over the past year we’ve added some great drag-and-drop UI features to ADT and we’re in the process of adding them all into Android Studio. This release of Android Studio lets you preview your layouts on different device form factors, locales, and platform versions.
We wanted to make it easy for you to harness the power Google services right from your IDE. To start, we’ve made it trivial to add services such a cloud-based backend with integrated Google Cloud Messaging (GCM) to your app, directly from the IDE.
We’ve also added a new plugin called ADT Translation Manager Plugin to assist with localizing your apps. You can use the plugin to export your strings to the Google Play Developer Console for translation, then download and import your translations back into your project.
Starting next week we’ll be doing all of our development in the open, so you can follow along or make your own contributions. You can find the Android Studio project in AOSP at https://android.googlesource.com/platform/tools/adt/idea/
Give Android Studio a try and send us your feedback! It's free, and the download bundle includes includes everything you need, including the IDE, the latest SDK tools, the latest Android platform, and more. .
Note: This is an early access preview intended for early adopters and testers who want to influence the direction of the Android tools. If you have a production app with a large installed base, there’s no need to migrate your development to the new tools at this time. We will continue to support Eclipse as a primary platform for development.
If you have feedback on the tools, you can send it to us using the Android Studio issue tracker.
Posted by Fred Chung, Android Developer Relations team
Android 4.2, Jelly Bean, introduced quite a few new features, and under the covers it also added a number of security enhancements to ensure a more secure environment for users and developers.
This post highlights a few of the security enhancements in Android 4.2 that are especially important for developers to be aware of and understand. Regardless whether you are targeting your app to devices running Jelly Bean or to earlier versions of Android, it's a good idea to validate these areas in order to make your app more secure and robust.
Content providers are a facility to enable data sharing amongst app and system components. Access to content providers should always be based on the principle of least privilege — that is, only grant the minimal possible access for another component to carry out the necessary tasks. You can control access to your content providers through a combination of the exported attribute in the provider declaration and app-specific permissions for reading/writing data in the provider.
exported
In the example below, the provider ReadOnlyDataContentProvider sets the exported attribute to "true", explicitly declaring that it is readable by any external app that has acquired the READ_DATA permission, and that no other components can write to it.
ReadOnlyDataContentProvider
READ_DATA
<provider android:name=”com.example.ReadOnlyDataContentProvider” android:authorities=”com.example” android:exported=”true” android:readPermission=”com.example.permission.READ_DATA” />
Since the exported attribute is an optional field, potential ambiguity arises when the field is not explicitly declared in the manifest, and that is where the behavior has changed in Android 4.2.
Prior to Jelly Bean, the default behavior of the exported field was that, if omitted, the content provider was assumed to be "exported" and accessible from other apps (subject to permissions). For example, the content provider below would be readable and writable by other apps (subject to permissions) when running on Android 4.1 or earlier. This default behavior is undesirable for sensitive data sources.
<provider android:name=”com.example.ReadOnlyDataContentProvider” android:authorities=”com.example” />
Starting in Android 4.2, the default behavior for the same provider is now “not exported”, which prevents the possibility of inadvertent data sharing when the attribute is not declared. If either the minSdkVersion or targetSdkVersion of your app is set to 17 or higher, the content provider will no longer be accessible by other apps by default.
minSdkVersion
targetSdkVersion
While this change helps to avoid inadvertent data sharing, it remains the best practice to always explicitly declare the exported attribute, as well as declaring proper permissions, to avoid confusion. In addition, we strongly encourage you to make use of Android Lint, which among other things will flag any exported content providers (implicit or explicit) that aren't protected by any permissions.
Android 4.2 includes a new default implementation of SecureRandom based on OpenSSL. In the older Bouncy Castle-based implementation, given a known seed, SecureRandom could technically (albeit incorrectly) be treated as a source of deterministic data. With the new OpenSSL-based implementation, this is no longer possible.
SecureRandom
In general, the switch to the new SecureRandom implementation should be transparent to apps. However, if your app is relying on SecureRandom to generate deterministic data, such as keys for encrypting data, you may need to modify this area of your app. For example, if you have been using SecureRandom to retrieve keys for encrypting/decrypting content, you will need to find another means of doing that.
A recommended approach is to generate a truly random AES key upon first launch and store that key in internal storage. For more information, see the post "Using Cryptography to Store Credentials Safely".
Javascript hosted in a WebView can directly invoke methods in an app through a JavaScript interface. In Android 4.1 and earlier, you could enable this by passing an object to the addJavascriptInterface() method and ensuring that the object methods intended to be accessible from JavaScript were public.
WebView
addJavascriptInterface()
On the one hand, this was a flexible mechanism; on the other hand, any untrusted content hosted in a WebView could potentially use reflection to figure out the public methods within the JavascriptInterface object and could then make use of them.
JavascriptInterface
Beginning in Android 4.2, you will now have to explicitly annotate public methods with @JavascriptInterface in order to make them accessible from hosted JavaScript. Note that this also only takes effect only if you have set your app's minSdkVersion or targetSdkVersion to 17 or higher.
@JavascriptInterface
// Annotation is needed for SDK version 17 or above. @JavascriptInterface public void doSomething(String input) { . . . }
Android 4.2.2 introduces a new way of protecting your apps and data on compatible devices — secure USB debugging. When enabled on a device, secure debugging ensures that only host computers authorized by the user can access the internals of a USB-connected device using the ADB tool included in the Android SDK.
Secure debugging is an extension of the ADB protocol that requires hosts to authenticate before accessing any ADB services or commands. At first launch, ADB generates an RSA key pair to uniquely identifies the host. Then, when you connect a device that requires secure debugging, the system displays an authorization dialog such as the one shown below.
The user can allow USB debugging for the host for a single session or can give automatic access for all future sessions. Once a host is authorized, you can execute ADB commands for the device in the normal way. Until the device is authorized, it remains in "offline" state, as listed in the adb devices command.
adb devices
For developers, the change to USB debugging should be largely transparent. If you've updated your SDK environment to include ADB version 1.0.31 (available with SDK Platform-tools r16.0.1 and higher), all you need to do is connect and authorize your device(s). If your development device appears in "offline" state, you may need to update ADB. To so so, download the latest Platform Tools release through the SDK Manager.
Secure USB debugging is enabled in the Android 4.2.2 update that is now rolling out to Nexus devices across the world. We expect many more devices to enable secure debugging in the months ahead.
For a full list of security best practices for Android apps, make sure to take a look at the Security Tips document.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
