Public-Mesh-Research-Report.md

@@ -395,6 +395,7 @@ In short, Bluetooth Mesh doesn't appear to be usable for creating smartphone-bas
 
 On a mobile device, a public mesh Bluetooth service needs to be able to run uninterrupted in the background, and also need to be able to make Bluetooth advertisements and connections in the background. To do this, all of the Bluetooth-based branches of the testbed application request the following permissions:
 
+```
 <uses-permission
         android:name="android.permission.ACCESS_COARSE_LOCATION"
         android:maxSdkVersion="30" />
@@ -414,6 +415,7 @@ On a mobile device, a public mesh Bluetooth service needs to be able to run unin
         android:name="android.permission.BLUETOOTH_SCAN"
         android:usesPermissionFlags="neverForLocation"
         tools:targetApi="31" />
+```
 
 Depending on the API level, various permissions must be granted by the user. On API level 31, the following permissions require user confirmation:
 
@@ -766,6 +768,7 @@ We couldn't find any devices that could perform service discovery while providin
 
 Wi-Fi Direct requires various permissions on different Android API levels:
 
+```
 <uses-permission
     android:name="android.permission.ACCESS_FINE_LOCATION"
     android:maxSdkVersion="32" />
@@ -778,6 +781,7 @@ Wi-Fi Direct requires various permissions on different Android API levels:
 <uses-permission
     android:name="android.permission.NEARBY_WIFI_DEVICES"
     android:usesPermissionFlags="neverForLocation" />        
+```
 
 Depending on the API level, the user must grant either the location permission or the nearby Wi-Fi devices permission.
 In practice, the system UI for requesting the `NEARBY_WIFI_DEVICES` permission also seems to grant the `BLUETOOTH_ADVERTISE`, `BLUETOOTH_CONNECT` and `BLUETOOTH_SCAN` permissions, and vice versa, but apps should probably not depend on this.