I have updated my app and published the update to Windows App store but during certification it fails by giving below reasons
App Policies: 10.1 Inaccurate Representation Your app and its
associated metadata must accurately and clearly reflect the source,
functionality, and features of your app. All aspects of your app
should accurately describe the functions, features and any important
limitations of your app. Your app may not use a name or icon similar
to that of other apps. Your app may not claim to be to be from a
company, government body, or other entity if you do not have
permission to make that representation. Keywords may not exceed seven
unique terms and should be relevant to your app. Your app must be
fully functional. Locations: Metadata Notes To Developer The app
metadata promotes another mobile platform. For more information see
http://go.microsoft.com/fwlink/?LinkId=615230.
I don't know what happened to this update. Earlier versions were approved without any issue.
If anyone have any clue how to fix it , please please let me know.
Anyway the solution I rebuild and deployed again without any changes and this time it is certified without any issue.
Don't know what Microsoft was looking for.
Related
We had a horror story back in August where our Here Maps SDK License Key was mistakenly changed on us (to this day, nobody still knows who did it and why). It was a nightmare, because all our users' apps froze upon launch and we had to push an update to the app store (and although I've had Apple approve an app update in the past in as little as 4 hours, that time it took them 4 days!!!).
It would make much more sense to store the values locally and then have the info populated into the app. Problem is that Here Maps requires the info in App Delegate which is the top level of app and it's difficult to build database queries in there.
Our license will be renewing soon, so I am thinking of solving this issue once and for all. Anybody had this issue before and has any ideas?
We believe it would be the correct solutions to avoid major incidents.Maintaining credentials in more controlled DB is a right approach instead of keeping in AppDelegates.
I launched a game to the Google Play store recently and it was going good until now. I just received an email from Google that says that "One or more of your apps contains an Intent Redirection vulnerability that puts user data at risk " and tells me I need to fix it by August 13.
I personally don't collect or demand any user data or info. However, I used Google Admob ads with Facebook mediation and Unity ads in my game which may be the cause of this problem. So, my question is how to overcome this problem? They also said in the email to make changes in the manifest file. If any one has a similar problem and knows the solution for it, your help would be appreciated.
Here is the email:
"One or more of your apps contains an Intent Redirection vulnerability that puts user data at risk. On August 13, 2019, any apps that contain unfixed security vulnerabilities beyond the dates listed on your Play Console alerts will be removed from Google Play.
Action required
Sign in to your Play Console.
Select Alerts to see which apps contain a security vulnerability, and review the guidance on how to resolve the vulnerability.
Update your affected apps to fix the vulnerabilities.
Submit the updated versions of your affected apps.
Upon resubmission, your app will be reviewed again. This process can take several hours. If the app passes review and is published successfully then no further action is required. If the app fails review then the new app version will not be published and you will receive notification via email."
I was having the same issue "intent redirection your app(s) are vulnerable to intent redirection" and I added exported="false" in every activity, but still got rejected, then I realized the problem was in one of the payment libraries I was using, all I had to do is update the library and the new app update got live.
my issue was in RazorPay payment gateway, I updated it from 1.6.3 to 1.6.6 (latest)
implementation 'com.razorpay:checkout:1.6.6'
they already mentioned this issue here, check it out https://github.com/razorpay/razorpay-android-sample-app/issues/202
I have a same issue, actually Latest Unity Add Xiaomi SDK by default which cause this issue.
Simple remove Xiaomi from your Unity it will fix the issue.
We had received a similar email, In the Play Console/Alert tab, we found this
for us, the reason is "com.androidnative.features.social.common.SocialProxyActivity.StartActivity"
which come from Android Native asset[Ultimate Mobile] - Unity3D.
We used that asset for Advertisements, In-app purchase and play game services instead of using the original SDK. So the possible solution is to remove that asset from our game and use the original SDK.
Here is the Screenshot of my alert.
There are several points to keep in mind to resolve that issue:
The most confusing: you must rollout affected application fixed APK/AAB to 100% on all tracks where it had place to be. Important note is that among others you must rollout production track release to 100% in order to Google to reconstruct your issue.
In the new version of Play Console there is no way to find out any specific information about the issue so you should email Google Support to ask for details. As a respone you may possibly get obfuscated method or class signature, so you need to deobfuscate it.
Read carefully through official document to address issues and resolve them. Our application got rejected because SMS BroadcastReceiver did not apply any permission restraints.
Ihsan Ali
The problem is in the UnityChannel.aar file, you need to open it with the help of the archiver and open the AndroidManifest.XML. I in the line android:exported="true" wrote a false as indicated in the article in Google. Now publish the version and if the error will no longer be reported.
I had the same issue. Just remove xiaomi app game centre from your unity>>game build option. Disabling it will surely clear out the issue.
I am looking into using firebase dynamic links in my application. I have a need for passing a unique identifier into a users application from an email-generated link. This works fine when the user has the app installed, however, I am running into some confusion with how the application is not installed.
I see that firebase dynamic links has support for taking the user to the app-store if the user does not have the application installed. They then use (deferred?) linking to take the user into the deep-linked target of the app after the application is installed. How is this done? How is a match guaranteed? Or is it?
Branch.io has significant documentation and this on how they handle deferred deep-linking accompanied by all of the strategies and fallbacks that they implement. Do firebase dynamic links rely on the same strategies or do they have another mechanism to 100% guarantee matching of a user from deep-link through app install and into app open?
Alex from Branch.io here:
Firebase uses simplistic device matching. This means matches cannot be 100% guaranteed, because there's always a chance that two devices will look the same to the Firebase backend. Until recently, the system-wide Dynamic Link attribution window was only 5 minutes, to minimize this risk.
This is a relatively minor issue if you're not passing sensitive/personal data through using links, but if you are then you might want to consider using Branch as a drop-in replacement. It's fairly easy to do.
I wanted to know which one is easier to implement. In the branch app indexing method is it required to implement app content sitemaps?
Full disclosure: I'm the Branch.io team
The way Firebase and Branch implement app indexing is fairly similar. In fact, Branch uses exactly the same methods for indexing as Firebase does, and adds some additional functionality on top. Branch acts as a wrapper for your own website, or as your full hosted website from the perspective of Firebase. So, when it comes to indexing with Google, you index a Branch link whereas Firebase requires you to submit your own site.
From the perspective of a developer, assuming the only thing you're trying to do is app indexing, Branch is slightly simpler to use and gives you rich analytics about the traffic from this channel but neither one is a lot of work. However, both platforms also provide other features that may sway your decision. If you're doing any sort of content sharing (i.e., your users create links to post on social media), Branch gives you app indexing basically 'for free' in the same library, whereas Firebase would require you to implement both features separately.
Both tools are free to use.
Firebase
Offers a lot of features (of which app indexing is just one), all implemented to a 'fairly good' level. This makes the Firebase platform an attractive choice for a small, new app that needs a lot of basic infrastructure and doesn't necessarily plan to require advanced functionality later on.
On Firebase, App Indexing for Android apps is implemented via integrating the Firebase App Indexing SDK and making a verified link between your website and your app (usually via Digital Asset Links or the Google Search Console). The 'Firebase App Indexing' SDK is actually just Google's old App Indexing SDK that's been rebranded and repackaged in a peculiar way.
You then register content items inside your app using the SDK and cross your fingers in hopes that Google will index them — there's no feedback on the process. App Indexing for iOS apps is based on crawling URLs that have been enabled for Apple's Universal Links. There is a Firebase App Indexing SDK for iOS, but to be honest I have no idea what it does. We've never seen any benefit or change to indexing behavior on iOS when it's integrated. On both platforms, you need to already have a live website, because every piece of content inside your app must also correspond to a specific URL on your site.
Branch
A best-in-class, enterprise-grade tool for growth attribution and content sharing, used by many of top apps like Pinterest, Airbnb, Jet.com, etc.
Branch is based around the concept of a single link that works everywhere, on all platforms, and intelligently redirects to the appropriate destination. Every time your users share content or view a piece of content in your app, that action generates a link. Since Google's search index is really just a huge collection of links, this is a perfect match.
On both Android and iOS, Branch de-dupes your app's links for any that point to the same content, packages up the result into an 'app content sitemap' (you don't have to do this yourself if you're using Branch links — it's automatic as soon as you enable the feature) and ships that sitemap file over to Google. In addition, since your links are hosted by Branch, there is no need for you to have an existing website, and you also get access to things like iOS Spotlight Indexing. Branch is compatible with iOS Universal Links by default, and we take care of verifying the connection between your web content and your app. We also monitor the links so we can give you feedback on if/when Google decides to index your content, and so that you can pull out reports on traffic that comes in through app indexed links.
On Android, in addition to the approach above, the Branch SDK helps you to identify pieces of content inside your app and submit them to Google for indexing. This is exactly the same approach as Firebase uses, except since the traffic still goes through a Branch link, you get additional data for attribution and analytics.
Feel free to read the full Branch Google App Indexing integration guide for more details!
Of course, implied in all of this is the assumption Google actually cares about your content enough to display it in search results. They seem to be getting better about this, but at the moment it's still very much a black box without much feedback to you as the developer. At Branch, we're trying to provide as much insight into the process as we can, so at least if your content isn't being indexed by Google you'll know that instead of being left wondering.
I'm working on a tweak that needs to download and install an app from the App Store (given a bundle id or some kind of other identifier), but doing so without using the App Store app (e.g., to allow the user to remotely instal an app on the device, without going through the App Store UI).
(I'll pause here to point that obviously this has nothing to do with piracy, as I want the app to be downloaded through the user's account in the store, and in any case I'm only targeting free apps at the moment).
I went through iOS 7 private framework headers and couldn't find a way to fit in and to tell the device to install an app with a given identifier. I've also looked for similar tweaks to have a look at their source, but the only one I could find was 'Auto App Updater', and its code isn't public.
I would greatly appreciate your help in coming up with a code that does that, or an open-source tweak that utilises a similar function.
Thanks a lot!
Dan