DJILDMManager | Data Privacy - dji-sdk

I am developing an iOS app for Phantom 4 Pro, using the DJI SDK for iOS.
In my app, I need to ensure that my user's entire private data, such as Photos, Videos, Location, Flight plan, etc should remain local, and should not get shared to anyone without user's discretion.
For achieving this, I went through the API Reference, and found the class DJILDMManager, which mentions that by enabling the local data mode, the most appropriate for users that have very stringent data requirements.
Here, I need to know what minimal information could still get shared to DJI (or anywhere else), when I have the Local Data Mode Enabled.
More Information
Even with Local Data Mode (LDM) enabled successfully, I have observed the following network requests from the app for creating HTTP tunnels:
CONNECT mydjiflight.dji.com:443 HTTP/1.1
CONNECT active.dji.com:443 HTTP/1.1
CONNECT api.dji-services.com:443 HTTP/1.1
CONNECT flysafe-api.dji.com:443 HTTP/1.1
I would appreciate your inputs regarding these requests, as I am not sure if they are capturing drone's data, but app does seems to reach out for DJI servers in LDM enabled mode.

To monitor the status of LDM becoming supported listen to the notification that LDM Manager posts when the supported status changes. From here you can then enable LDM and continue on with the workflow of your app. Note that until LDM is enabled you may still see networking requests and after LDM enables you may see one request for registration.
[[NSNotificationCenter defaultCenter] addObserverForName:DJILDMManagerSupportedChangedNotification object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * _Nonnull note) {
if([[DJISDKManager ldmManager] isLDMSupported]) {
if (![[DJISDKManager ldmManager] enableLDM]) {
NSLog(#"LDM Enabled");
} else {
NSLog(#"LDM Disabled");
}
} else {
NSLog(#"LDM Not Supported");
}
}];

With LDM enabled (make sure to check first if supported in your region) the only communication that will go through to our servers is the registration.
Registration sends basic statistical information such as device type and verifies that the app key used is valid.
This happens once with our server and is then cached locally.
It may happen again after if the cache is not usable, but only once per app launch.
Registration doesn't send Photos, Videos, Location or Flight plans.
Nothing else is sent after LDM is activated.
Keep in mind that with LDM on, you won't get many of the online features including updated GEO features.

Related

Google play READ_CALL_LOG permission

Reading call log is the basic feature of my app, but i dont know which option to select among the following in the list in the declaration form.
Default SMS handler
Default Phone handler
Default Assistant handler
Transactional backup and restore for users and archive for enterprise (time-limited/non-continuous)
Enterprise archive, CRM, and device management
Caller ID, spam detection, and blocking
Connected device companion apps (for example, smartwatch or automotive)
Cross-device synchronization or transfer of SMS or calls
SMS-based financial transactions and related activity where access is restricted to financial SMS transactions (for example, 5-digit messages)
SMS based money management
Proxy calls
Services - Carrier
Services - OEM
Device Automation
Physical safety / emergency alert apps (e.g., senior safety)
Call-based OTP account verification
Using SMS_CB_RECEIVED for customer communications (e.g., Smart Zone Cast service)
Write and Show Call History in Dialer
In-vehicle hands-free use or projected display
Anti-SMS Phishing
Since its only write and show call history in dialer option thats close to my requirement, i selected this, but now i got thefollowing email from google.
Google Play
Developer update
Hi Developers at Bot Entity, Thanks for contacting the Google Play
team about your app Whatsupp Direct, com.whatsappdirect.wd. Publishing
Status Publishing status: Rejected After review, your app has been
rejected and wasn't published due to a policy violation. If you
submitted an update, the previous version of your app is still
available on Google Play. Issue: Violation of Permissions policy After
reviewing your app, we found that it doesn’t qualify to use the
requested permissions for the following reason(s): App is using
unnecessary permissions When you submitted your app, you specified
your app's core functionality as follows: Write and Show Call History
in Dialer. However, based on the permitted uses, your app is only
allowed to access the following permissions: WRITE_CALL_LOG. Please
remove the following permission(s) from your app: READ_CALL_LOG.
now how do i get READ_CALL_LOG in the list??

Custom google home action should always reconnect to get it working

i have a custom google home action implemented as described in the documentation (Oauth2 setup, sync, execute, etc... setup) and all works as expected on my Google home app and my google home physical devices.
Now, every now and then i need to reconnect the app in the Google Home App because it seems the app cannot reach my devices after some time. I checked my Oauth server if the refresh tokens are working ok and they do. Also my access token expires after 20 minutes and me reconnecting to the app should be done after some hours so the refreshing works in my opinion.
Now, are there any restrictions in using the TEST of the google home action?
The case i wrote is specific for personal use (intergration with personal server and domotica system) so i am actually not planning on releasing it, I just want to use it for myself. Is this allowed? Can i just leave my action in 'test' forever for such purposes?
EDIT: 18/05/2022: custom actions still working flawlessly after 6 months in test :-)
EDIT: 02/02/2023: custom actions still working flawlessly in test :-)
Additional question:
If i have to submit the app for release, i cannot meet the expectation in implementing state report as i have no control over the usage of buttons pressed at my home domotica. Is State Reporting also accepted when i report the state of my devices over time (let's say, every hour?)
tnx
EDIT:
So it seems there is something wrong with my refreshing of the tokens but i don't know what. When i try through postman, all works as expected, in stackdriver logs i see this :
jsonPayload: {
#type: "type.googleapis.com/google.identity.accountlinking.type.AccountLinkingError"
errorReason: "Failed to get response from 3P. 3P returned malformed response like invalid response code or un-inflatble body."
request: {
body: "grant_type=refresh_token&refresh_token=REDACTED_VALUE&client_id=qbusauth&client_secret=REDACTED_VALUE"
method: "POST"
uri: "https://******.azurewebsites.net/token"
}
sessionId: -1039956344
step: "REFRESH_ACCESS_TOKEN"
If you don't plan to submit your Action for release, you'll just need to occasionally re-enable device testing through the console.
To minimize the number of query intents to your fulfillment, you should implement Report State and proactively send device states to update HomeGraph. You would have to implement this if you decide to release your Action.

Changing policy name on device didn't remove old policy apps from the device

When I change the policy name firstpolicy to secondpolicy on the device, the patch API response is 200 ok and it removes apps of first policy to apps of second policy from the play store app, but it did not remove them from the device. It still shows apps of the first policy.
I am using an update mask.
Testing fully managed device
Any help appreciated.
The stack overflow thread at Android Device Policy sync does not work until done manually mentions a reboot will force apply a policy, which isn't ideal but it does at least ensure a policy is updated. I'm also testing a fully managed device.
https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand details the standard for sending a command to a device. You can test it against live data with the API explorer on that page, so navigate towards the bottom of the page where it says 'Request Parameters' -> 'Name', and put in your enterprise & device ids of the form 'enterprises/your-enterprise-id/devices/your-device-id'. Then go to 'Request Body' and use the '+' sign to add 'type' : 'REBOOT' as a parameter. Press the execute button, in which you will be prompted to choose an account for OAuth2.0. After this, you will see the results, and if successful (returns a 200 code), it will issue the reboot command, with the policy being updated after rebooting.
To reiterate, I know this isn't ideal, but it at least does do an update, so just providing that info.
Good luck and let me know if everything worked out.
It may take a while for the policy to sync and apply any changes, including removal of apps. You can force sync by opening the Android Device Policy app and touching the sync button. The other way is to issue a reboot command to the device to make sure that the new policy is applied. You can check the issueCommand method for more information.

Is it possible to persist a Bluetooth LE connection on browser refresh

Is it possible to persist a Bluetooth LE connection on browser refresh? Or at least minimize the pairing time?
Eventually navigator.permissions.query would support this. Sample code from Web Bluetooth Specification
navigator.permissions.query({
name: "bluetooth",
deviceId: sessionStorage.lastDevice,
}).then(result => {
if (result.devices.length == 1) {
return result.devices[0];
} else {
throw new DOMException("Lost permission", "NotFoundError");
}
}).then(...);
However, no browser currently implements this.
As of Q3 2017 the chromium implementation is actively working on Web Bluetooth but not this feature.
I recently implemented a new permissions backend as well as two APIs that will enable previously permitted Bluetooth devices to be used.
The new permissions backend is implemented behind the chrome://flags/#enable-web-bluetooth-new-permissions-backend. The new backend will persist device permissions granted through requestDevice() until the permission is reset in Site Settings or the Page Info dialog box.
The getDevices() and watchAdvertisements() are implemented behind the chrome://flags/#enable-experimental-web-platform-features flag for Chrome 85.0.4165.0 or greater. The recommended use of these APIs is to use getDevices() to retrieve an array of permitted BluetoothDevices and then calling watchAdvertisements() on these devices to start a scan. When advertisement packets are detected from the devices, the advertisementreceived Event will be fired on the device that it corresponds to. At this point, the Bluetooth device is in range and can be connected to.
Please give this new feature a try, and file any bugs at https://crbug.com using the Blink>Bluetooth component.

iOS Google Play Service's push notifications is working at this time?

I'm building an iOS game using Google Play Game for turn-based multiplayer but cannot receive any notifications. I did research many days to find what is wrong but i can't find anything.
So is iOS push notification in Google Play game still working at this time? Do your games still receive push notifications normally? Please provide me some information.
Thank you!
It is still indicated in the documentation that invitation and turn notifications are currently supported on Android and iOS. Based from this tutorial, you need to register your app to receive push notifications.
In your appDelegate, add the following code to the callback for retrieving the push device token passed back from APNS. This device token is used for outbound push notifications, and your app must register it with the Google Play games services push service. Make sure to always register your device token through GPGManager to enable push notifications from Google Play games services. Even if the user has not signed in; the GPGmanager object will cache this token and save it until the user signs in.
- (void)application:(UIApplication *)application
didRegisterForRemoteNotificationsWithDeviceToken
:(NSData *)deviceToken {
NSLog(#"Got deviceToken from APNS! %#", deviceToken);
[[GPGManager sharedInstance] registerDeviceToken:deviceToken
forEnvironment:GPGPushNotificationEnvironmentSandbox];
}
From this related thread:
If you are having issues you might want to make sure the token is being registered correctly with APNS in the AppController.m (by logging it).
Also, there are two certificates you can register on the Play console, one for sandbox and one for production. Make sure that certificate you are using is the one being configured. By default the AppController calls
gpg::RegisterDeviceToken(deviceToken, false); which indicates that this is the prod certificate configured on the console.
You can also check this related GitHub issue which might help.

Resources