A android third party application SDK which is in violation of tracking data like below
MUwS-V: SDK collects a list of installed applications without consent
Location-V: SDK collects location data without consent
MUwS-V: SDK collects a large variety of hardware identifiers including build serial allowing for bridging PII with hardware IDs
How can I suppress / stop this tracking in the SDK and still use the SDK's main functionality? Anyway to control from main application which consumes the SDK?
Related
Not using any Unity Ads SDK but still getting this error. Any one have any idea about this
version code 33 includes SDK com.unity3d.ads:unity-ads or an SDK that one of your libraries depends on, which collects personal or sensitive data that includes but may not be limited to null identifiers. Persistent device identifiers may not be linked to other personal and sensitive user data or resettable device identifiers as described in the User Data policy.
Starting from January 11, 2023 midnight (UTC), new app releases containing the SDK version(s) that do not comply with the User Data policy may be blocked from release. You may consider upgrading to a policy-compliant version of this SDK that does not include the violating code if available from your SDK provider, or removing this SDK from your app.
According to your SDK provider, you may consider upgrading to 4.0.1, and/or contacting your SDK provider to see if a suitable later version might be available. Google is unable to endorse or recommend any third party software.
ACTION REQUIRED: Upload a new compliant version AND deactivate the noncompliant version.
Read through the User Data policy for more details, and how to submit an updated app for review here.
If you've reviewed the policy and feel our decision may have been in error, please reach out to our policy support team.
I am working on a custom EMM MDM solution. I did a lot of study about it and I came across these two APIs.
Android Management API
Google EMM API
Now I have few questions about these two APIs
I did about these two APIs individually but i don't why i find these
APIs similar in functionality I just want to know the main
difference between of both these APIs or advantage and disadvantage
of both APIs.
While provisioning a device with android management API, In DPC identifier method we write afw#setup when prompted to sign in which downloads Android Device Policy application but other MDMs for example In tiny MDM when user is going to enroll device, he writes afw#tinymdm when prompted to sign in which downloads their own application. Now what i need to do develop my own application and i write a code which downloads my app and user gets enrolled
What is actually NFC? In the documentation they wrote there is an admin device and u need to bump other device with admin device to enroll device. I did same but nothing happens.
How can i share the files and contacts with all enrolled devices in android management API
How can i track the physical location of device in android management API
I eagerly wants the answer of these questions that I found nowhere yet.
Google is no longer accepting new registrations for the Play EMM API. It is mentioned on all EMM related webpages, this is done so that developers can start using the latest Android Management API.
afw#setup is the identifier for Android Management API, it will download the Android Device Policy and continue to setup. afw#name are identifiers of EMMs which were built on Play EMM APIs and have their own DPC - Device Policy Controller and now Google doesn't accept new identifiers.
NFC enrollment is a process to provision a device. Link
Would suggest to perform more research on Android Management API and also understand the options better.
How can i share the files and contacts with all enrolled devices in android managment API
There is currently no way to achieve this using Android Management API. However, you are free to use third-party applications to achieve this.
How can i track the physical location of device in android management API
This has been answered here.
Soon new Huawei phones will stop supporting Google Play and Google Mobile Services.
Huawei is preparing its own ecosystem called HMS https://developer.huawei.com/consumer/en/service/hms/developer.html
Their app store is called "Huawei App Gallery" and has its documentation here: https://developer.huawei.com/consumer/en/doc/30202
They are now sending messages to developers (including me) that encourage them to release an app to their store. They are claiming that they only need an APK file and no changes to the application are needed.
My questions are:
Is a react-native app going to work without code changes?
Is Firebase SDK going to work?
What is the real hidden cost of maintaining an app in another Android ecosystem?
Huawei has already released its Huawei Mobile Services and is currently progressively updating its services to closely match with Google and Apple. As for the questions your asking
Is the react-native app going to work without code changes?
Yes, as long as you can generate an apk to upload to their Huawei App Gallery. You do not have to make any code changes.
Is Firebase SDK going to work?
This depends on the type of service you are trying to incorporate into your application for instance if your trying to use Google Login using the authentication module provided by Firebase then it will not be supported only on the phones that do not include GMS (Google Mobile Services) which is the Huawei Mate 30 Pro.
However, if you are looking at notifications. Google has Firebase Cloud Messaging and Huawei has its Huawei Push Notification. You can use either one as this is dependant on the architecture of the backend services and will be supported on all android devices.
What is the real hidden cost of maintaining an app in another Android eco-system?
This completely depends on how you architect the system and the services that are required within your application. Let say you want to include Huawei Sign in to be incorporated within your application and you also need to include HMS, But these you want to maintain in the Huawei App Gallery and For Google you have FCM and Google Login and Maps implemented then you would have to maintain two different branches which share the common core functionality which is time and cost consuming.
If the app is just going to use only the bare functionality which is purely dependant on logic and very little or no GMS/HMS, then you do not have to maintain separate branches for your project, just one would suffice. You just need to submit a version to your Google Play Publish and Huawei App Gallery.
If you would like to use a single repo for both GMS and HMS then you have to check the service available to enable the functionality.
For GMS
val gmsAvailable = GooglePlayServicesUtil.getInstance().isGooglePlayServicesAvailable(mContext)
For HMS
val hmsAvailable = HuaweiApiAvailability.getInstance().isHuaweiMobileServicesAvailable(mContext)
So when trying to use Google Login or Huawei Login or any other services, It would be.
if gmsAvailable {
// execute GMS Code
} else if hmsAvailable {
// execute HMS Code
}
Note* The above code is in Kotlin
Huawei has begun to build an HMS ecosystem to make top apps available on its new devices without access to GMS, such as Mate 30 and P40 devices, improving user experience on these devices. It is recommended that you use GMS if the device has access to GMS and use HMS if the device has no access to GMS.
As for your questions:
1.
Is a React-Native app going to work without code changes?
If your app uses any GMS plugins for React Native, such as Google Sign-in and Firebase Cloud Messaging, your app may not work properly on devices without access to GMS. Therefore, you need to make some code changes to your app.
Huawei has provided some HMS Core kit plugins for React Native. For details, visit the following links:
Push Kit plugin for React Native
Analytics Kit plugin for React Native
Location Kit plugin for React Native
Map Kit plugin for React Native
Health Kit plugin for React Native
Is Firebase SDK going to work?
This depends on which GMS service you use. For example, if your app uses the push notification/Location/map service of GMS, your app may not work properly. In this case, you need to use relevant HMS SDK instead. You can choose what HMS Core services to use.
3.
What is the hidden cost of maintaining an app in another Android
ecosystem?
There indeed some hidden workload, for example, maintaining code, releasing your app to HUAWEI AppGallery, and modifying both GMS and HMS to provide new functions. Of course, this depends on the complexity of your app. If your app uses many GMS services, the workload is relatively high. If your app uses few GMS services, the workload is relatively low. To reduce your workload, you are advised to use both GMS and HMS in your project. The method is as follows:
Check whether the device supports GMS
Check whether the device supports HMS
In your app, you can use the following pseudocode to use both GMS and HMS:
if isGMSAvailable {
// execute GMS Code
} else if isHMSAvailable {
// execute HMS Code
}
By doing so, you can reduce subsequent workload for maintaining code and adding new functions.
Regarding:
Is Firebase SDK going to work?
You could use this service from Huawei called QuickHMS - you simply search for a dependency/framework/library and find out if it can run as it is on HMS devices: https://quickhms.com/en/compatibility-check/
The list of current ReactNative HMS plugins can be found here: https://developer.huawei.com/consumer/en/doc/development/HMS-Plugin-Library-V1/reactnative-plugin-0000001050155850-V1
I have received an warning from Google Play:
Reason for warning: Violation of Usage of Android Advertising ID
policy and section 4.8 of the Developer Distribution Agreement
I have been checking and app should be sending the Android Advertising ID. It has to be a library because I am not doing it.
I use crashlytics and OneSignal and both could be the problem. But I have found in the documentation of OneSignal that the SDK get it:
https://documentation.onesignal.com/docs/handling-personal-data#section-personal-information-sent-as-data-tags
Some data is automatically collected by the OneSignal SDK. For example, on mobile devices this typically include's the device's advertising id, purchases they have made in your app, the timezone setting of the device, and location data (if your app has location permission).
I am trying to disable the SDK continue collecting the advertising identifier but I don't find how to do it. In addition, the list of collected data is not clear because Advertising identifier does not appear:
https://documentation.onesignal.com/docs/data-collected-by-the-onesignal-sdk
I would need to know how to configure OneSignal SDK for not collecting anymore the Advertising identifier.
Thanks.
Google has started emailing apps that use Advertising Id and do not have a privacy policy to tell them they must add a privacy policy.
You can address this by adding a privacy policy to your Play Store listing and in your app. If you do not already have a privacy policy, there are tools available to create one such as http://www.docracy.com/mobileprivacy (free) or https://www.iubenda.com/en/ ($27/yr)
After speaking a little bit more with JonF, he spoke with OneSignal developers and they said that it is possible to avoid sending the Advertising ID changing some lines in the SDK:
Most of the tracking for Android can be removed from registerUserTask
in
https://github.com/OneSignal/OneSignal-Android-SDK/blob/3a4d4353b1d803852e3b9986b828c9b823801ce5/OneSignalSDK/onesignal/src/main/java/com/onesignal/OneSignal.java#L1180-L1182
The problem is that it is not possible to keep the library integrated with gradle, but at least it is a solution.
I have been thinking to implement the change with Reflection but I don't have much time now for it, it could be another way.
This is the Android version of App for limited or restricted audience
The project
I'm going to start a brand new project for one of our customers that will be deployed to our customer's suppliers to track on-field activity. I am skilled enough on Java/Android development so this question is only about deployment.
Owned vs provided devices
Our customer will either provide a Samsung Galaxy Ace 4 device to the suppliers or will allow the supplier to use their own Android 4 smartphone without warranties from us. Our customer currently has a Google for Business organization set up, but we cannot rely on that (see partial answer).
Technical (non functional) requirements
Ability to easily distribute application and updates across enterprise users.
Application should not be visible to the public
Application must be able to send crash reports so our team can inspect and investigate
The question is
Given the above "should not be visible to the public" statement, what is the most effective and efficient way to deploy an Android app targeted only for enterprise users?
I'll post a partial answer below. I'm asking others to enrich it with other possible means, including using Alpha/beta channels for which I don't have experience about
Currently, limited-audience Android applications can be deployed like this:
Publishing on Google Play as a free app for the public
Maybe adding a limitation to our country
Advantages:
Simplemost and well documented
Auto deployes updates as soon as no new permission is enforced
Collects crash reports on Dashboard
Disadvantages:
Everyone can download the app
This has the disadvantage that some organizations may not be happy as publicly available code might in some cases help exploit vulnerabilites on remote systems (but it is almost impossible if app is well-written and obfuscated)
If country limitation is enforced, imported devices won't download
Distributing the APK direct URL
Advantages:
The app remains private (enterprise users are surely not going to redistribute the app to friends as it's no use without enterprise credentials)
Disadvantages:
No crash reports unless implementing a third-party library
No auto updates unless implemented by custom code or third party library. Implementing auto updates prevents the app from being published to Google Play in the future, even on a private channel, as Play prohibits apps that auto-update themselves via third-party channels. Or, to be precise, the auto-update feature and Play publishing require, in order to exist together, maintaining two APKs
Google Play for Enterprise
As mentioned on this link, Google Play provides a private channel for app deploying for users withing a Google for Business organization. This is the perfect approach for applications that organization's users must use
Advantages:
Same as publishing for the public (simple, auto update, crash report)
Visible only to restricted audience
Disadvantages:
Every device must come with a Google account within the organization, and it will be economically unfeasible to [request the Sysadmin to] enable Google accounts for every external supplier in our target organization
Permanently in Alpha/Beta
I haven't tested this yet, as it is also very tricky. Basically, it involves using testing mode without ever going to production. With Google Play, one can deploy artifacts into Alpha (e.g. test server environment) and Beta (a trick to point to production server environment) without ever moving the app to Google Play's Production stage.
All requires setting up special moderated Google+ groups
Potential advantages:
Same as publishing to enterprise
Disadvantages:
Only telling users to subscribe to Google+ and joining a community
From your requirements, I would suggest distributing the APK via a direct URL and integrating a service such as HockeyApp (see their Android SDK for more) to manage both the crash reports and app updates.
"Ability to easily distribute application and updates across enterprise users"
Many services allow .apk files to be uploaded directly to their service for deployment. A direct download link is then generated for that build.
Crash information is collected and updates are automatically displayed if the app implements the Android SDK provided by the service.
"Application should not be visible to the public"
Services such as HockeyApp do not publicise direct download links publicly. This link can therefore be distributed as required.
"Application must be able to send crash reports so our team can inspect and investigate"
Full stack-trace and device information is sent along with crash reports and can be viewed online by technicians.
From my experience there are a few pros and cons:
Pros:
App distribution is super easy, as simple as visiting a website.
Bug reports are comparable to those received through Google Play
Cons:
Crash report's aren't sent automatically and updates aren't automatic
By default, updates and crashes appear as system dialogs prompting users to either send the crash report/update the app or cancel. Ideally, no user interaction should be required to perform the desired actions. I am sure it is possible but have not found relevant documentation for it.
Cost. These services aren't free.
Would require the removal of the service SDK from the app if uploaded to Play Store