Android Wear-Detecting Location on Android Wear，Requesting Permissions on Android Wear

》Detecting Location on Android Wear

Location awareness on wearable devices enables you to create apps that give users a better understanding of their geographic position, movement and what's around them. With the
small form factor and glanceable nature of a wearable device, you can build low-friction apps that record and respond to location data.

an implementation of an activity that implements the

LocationListener

interface:

public class WearableMainActivity extends Activity implements
GoogleApiClient.ConnectionCallbacks,
GoogleApiClient.OnConnectionFailedListener,
LocationListener {

private GoogleApiClient mGoogleApiClient;
...

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

...
mGoogleApiClient = new GoogleApiClient.Builder(this)
.addApi(LocationServices.API)
.addApi(Wearable.API)  // used for data layer API
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.build();
}

@Override
protected void onResume() {
super.onResume();
mGoogleApiClient.connect();
...
}

@Override
protected void onPause() {
super.onPause();
...
mGoogleApiClient.disconnect();
}
}

》 To determine whether your Android Wear device has a built-in GPS sensor, use the

hasSystemFeature()

method.
The following code detects whether the device has built-in GPS when you start an activity:

protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

setContentView(R.layout.main_activity);
if (!hasGps()) {
Log.d(TAG, "This hardware doesn't have GPS.");
// Fall back to functionality that does not use location or
// warn the user that location function is not available.
}

...
}

private boolean hasGps() {
return getPackageManager().hasSystemFeature(PackageManager.FEATURE_LOCATION_GPS);
}

》The following code for wearable apps detects when the location changes and uses the data layer API to store the data for later retrieval by your phone app:

@Override
public void onLocationChanged(Location location) {
...
addLocationEntry(location.getLatitude(), location.getLongitude());

}

private void addLocationEntry(double latitude, double longitude) {
if (!mSaveGpsLocation || !mGoogleApiClient.isConnected()) {
return;
}

mCalendar.setTimeInMillis(System.currentTimeMillis());

// Set the path of the data map
String path = Constants.PATH + "/" + mCalendar.getTimeInMillis();
PutDataMapRequest putDataMapRequest = PutDataMapRequest.create(path);

// Set the location values in the data map
putDataMapRequest.getDataMap()
.putDouble(Constants.KEY_LATITUDE, latitude);
putDataMapRequest.getDataMap()
.putDouble(Constants.KEY_LONGITUDE, longitude);
putDataMapRequest.getDataMap()
.putLong(Constants.KEY_TIME, mCalendar.getTimeInMillis());

// Prepare the data map for the request
PutDataRequest request = putDataMapRequest.asPutDataRequest();

// Request the system to create the data item
Wearable.DataApi.putDataItem(mGoogleApiClient, request)
.setResultCallback(new ResultCallback() {
@Override
public void onResult(DataApi.DataItemResult dataItemResult) {
if (!dataItemResult.getStatus().isSuccess()) {
Log.e(TAG, "Failed to set the data, "
+ "status: " + dataItemResult.getStatus()
.getStatusCode());
}
}
});
}

》Requesting Permissions on Android Wear

Android
6.0 (API level 23) introduces a new permissions
model, bringing some changes that are specific to Wear, and other changes that apply to all Android-powered devices.

However, from Android
6.0 (API level 23), the Wear app no longer inherits these permissions. Thus, for example, a user might grant a handset app permission to use location data, and subsequently have to grant the same permission to the Wear version of the app.

For both Wear and handset apps, the Android 6.0 (API level 23) permissions model also streamlines
app installation and upgrade by eliminating the requirement that the user grant upfront every permission an app may ever need. Instead, the app does not request permissions until it actually needs them.

Note: For an
app to use the new permissions model, it must specify a value of

23

for both

uses-sdk-element

and

compileSdkVersion

.

》Broadly speaking, there are four scenarios you may encounter when requesting dangerous
permissions on Android Wear:

The Wear app requests permissions for an app running on the wearable device.
The Wear app requests permissions for an app running on the handset.
The handset app requests permissions for an app running on the wearable device.
The wearable app uses a different permission model from its handset counterpart.

Note: From Android
6.0 (API level 23), Android Wear automatically syncs Calendar, Contact, and Location data to the Wear device. As a result, this scenario is the applicable one when Wear requests this data.

》 There are different patterns for requesting permission from users. In order of priority,
they are:

Ask in context when the permission is obviously necessary for a specific
functionality, but is not necessary for the app to run at all.
Educate in context when the reason for requesting the permission is not
obvious, and the permission is not necessary for the app to run at all.
Ask up front when the need for the permission is obvious, and the permission
is required in order for the app to run at all.
Educate up front when the need for the permission is not obvious, but the
permission is required in order for the app to run at all.

When a previously denied wearable permission dialog appears a second time, it includes a Deny,
don't show again option. If the user chooses this option, then the only way for them to allow this permission in the future is to go into the wearable's Settings app.

As with the handset, the user can change a Wear app’s permissions in Settings at any time. Therefore,
when the user tries to do something that requires a permission, the app should always first call the

checkSelfPermission()

method
to see if the app currently has permission to perform this operation. The app should perform this check even if it knows the user has previously granted that permission, since the user might have subsequently revoked that permission.

》Using Speakers on Wearables

Some Android Wear devices include speakers, enabling them to incorporate sound into their apps and
offer an extra dimension of engagement with the user. A speaker-equipped Wear device might trigger a clock or timer alarm, complete with audio notification. Games on Wear become become more entertaining by offering not just sight, but sound.

PackageManager packageManager = context.getPackageManager();
AudioManager audioManager = (AudioManager) context.getSystemService(Context.AUDIO_SERVICE);

// Check whether the device has a speaker.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
// Check FEATURE_AUDIO_OUTPUT to guard against false positives.
if (!packageManager.hasSystemFeature(PackageManager.FEATURE_AUDIO_OUTPUT)) {
return false;
}

AudioDeviceInfo[] devices = audioManager.getDevices(AudioManager.GET_DEVICES_OUTPUTS);
for (AudioDeviceInfo device : devices) {
if (device.getType() == AudioDeviceInfo.TYPE_BUILTIN_SPEAKER) {
return true;
}
}
}
return false;

Once you've detected the speaker, the process for playing sound on Android Wear is the same as for a handset or other device. For more information, see Media
Playback.

If you also want to record audio from the microphone on the wearable, your app must also get permission to use the microphone. To learn more, see Permissions
on Android Wear.