I recently uploaded an app bundle to Internal App Sharing, and was surprised to see that on my backend, there were 7 new users of this new app version just a few seconds later. I was especially surprised because I am the only person with access to the app on Internal App Sharing, and I hadn't even installed the update yet.
So I guess Google is running something similar to pre-launch testing when uploading to Internal App Sharing. This is annoying, because it fills up my servers user table with irrelevant noise.
Can I detect these devices reliably somehow? I tried detecting the presence of firebase.test.lab in Settings.System, as suggested in this answer, but it didn't work.
As a developer och you can disable tests-reports in Google Play Console. Pre-launch tests, config (or something, I get the UI in Swedish so I currently don't see the English names of them.)
NOTE: I have not tested myself (as I want the testing) and I think they will still do some tests when you want to launch things.
Related
Our Wear OS application, which is not a standalone application (it is a companion app of our smartphone app, it cannot be used without the smartphone app) keeps getting rejected by Google Play Policy team for the following reason : "Your application requires phone interaction for the watch version to function." even if we have clearly explained in our Play Store description that it is not a standalone application and cannot work when the smartphone app is not available.
Our application was previously accepted and published on the Play Store but we suspect a Google policy change even if we haven't found it clearly anywhere (we have only found recommendations which encourage standalone apps).
=> Are not-standalone Wear OS apps still allowed for Play Store submission or must our Wear OS app include at least a standalone feature ?
Thanks in advance for your help.
TLDR for those who don't want to read the whole message: I had to set the following flag in the watch app's manifest to get my watch app approved:
<meta-data
android:name="com.google.android.wearable.standalone"
android:value="false" />
The longer story
I don't believe that what they forced me to do makes any sense. My application is semi-independent according to Google's own documentation:
A watch app can be considered as one of the following:
Completely independent of a phone app Semi-independent (a phone app is
not required and would provide only optional features) Dependent on a
phone app If a watch app is completely independent or
semi-independent, it is in the standalone category. You must indicate
this categorization to the Google Play store by setting the value of
this meta-data element to true:
My app requires an initial initialization of 2FA accounts, which can be done from an Android phone or from an iPhone. In the second case the Android phone is not required. Google requested to write a "disclaimer", which I've added to the app's description, but that didn't have any effect, they continued rejecting the app. I've asked three times about what was wrong with the disclaimer, but the best answer I've got was:
As much as I'd like to help, I’m not able to provide any more detail
or a better answer to your question.
I've asked one more time about what's wrong with the disclaimer, didn't get any answer, set 'standalone' flag to false and got approved two days later.
The problem that Google created for me and my users was that going forward installing the watch app would be possible from an Android phone only and not from a watch directly. It means that iPhone users would either need to find an Android device to install the watch app or to use ADB, and I'm sure, the users will hate me for this change.
Once again, an impression is that Android is on its way to self destruction: new policies break the old apps, support doesn't exist and developers are forced to make changes that make customers unhappy.
It's not the first episode of this stupidly, just recently I had to disable GDrive functionality in my Android app because new policies broke the existing logic that worked for years, and all OAuth 2.0 processes that Google suggested to be compliant with the new policies were not feasible for a small company
Here is a fragment of my comms with Google that fell on their deaf ears
I recently published an application to production mode on the play-store, the app status has changed from review to open testing, what does this mean? Might I have selected an option by mistake or it is a normal term as am meeting it for the first time.
Image
Internal testing: The app is not visible to the general public on Google Play. The app is only available to a list of people you manually set - you add their emails, and they get an invitation.
Closed testing: Same as Internal testing (not publicly visible, has an allow-list), but you get a Google report. Google will test your app and give you feedback.
Open testing: Visible to the general public on Google Play, but with a "Pre-release" warning. People can review the app, but the reviews are only visible to you.
Production: Visible to the general public. User reviews are public.
The workflow I use is:
I set the app as Internal testing (even if it is just my email address) . Right after doing this I
Promote the app to "Close testing" (even if it is just my email address) - so I can get Google's report right away.
After getting Google's report and fixing what they suggest (or ignoring it), I promote the app to production.
The reason why I jump from internal to closed testing is because I want Google's report right away. I do internal testings outside Google Play (I develop with React Native and Expo - and I use Expo for internal testings). So, the moment I submit the app it is already internally tested.
I also go straight from "closed testing" to "production" because my apps have a small audience, and I'm okay with public feedback. But if you are afraid you app may have bugs and it can hinder the app reputation with bad reviews, do the "open testing" first.
There's some testing type.
I hope you may know what production is. Production means when an application is completely ready for every device.
What's the difference between an internal, closed, and open test?
You can create releases on three testing tracks before you release
your app to production. Each phase of testing helps you gather the
feedback you need to make improvements to your app throughout its
development.
Internal testing: Create an internal testing release to quickly
distribute your app to up to 100 testers for initial quality assurance
checks. We recommend running an internal test before releasing your
app to the closed or open tracks. If needed, you can run internal
tests concurrently with closed and open tests for different versions
of your app.
Tip: You can also use internal testing to test apps that are not fully
configured (see below). Closed testing: Create a closed testing
release to test pre-release versions of your app with a wider set of
testers to gather more targeted feedback. Once you've tested with a
smaller group of colleagues or trusted users, you can expand your test
to an open release. On your Closed testing page, an alpha track will
be available as your initial closed test. If needed, you can also
create and name additional closed tracks.
If you're testing an existing app that you've published before, only
users in your test group will receive an update for your closed
version.
Open testing: Create an open testing release to run a test with a
large group and surface your app's test version on Google Play. If you
run an open test, anyone can join your testing program and submit
private feedback to you. Before choosing this option, make sure your
app and store listing is ready to be visible on Google Play.
Copied from google support.
Easy way : Open testing
Pre-launch reports
Spot issues before they affect your users. Test on a range of Android
devices to learn more about your app's stability, performance, accessibility, and more.
Here's another beautiful question with answer
I have 500k active users. My application has been probably hacked. How do I know that? My production versions are 3.x.y But I can see in Firebase statistics that 1% (about a few thousand) users use version 4.0.0. I have never released app with that version. Probably somebody just changed app version and I assume ad ids. He didn't even remove Firebase analytics so I can see that the hacked app is live. I use standard ProGuard obfuscation but as we can see it didn't help.
The question is how to find the place (site, market,..) from where hacked application is downloaded?
If you are fine to update your app, then I would first change my app to read getInstallerpackageName from PackageManager, and then record it via Firebase analytics.
If the result of this is com.android.vending it was installed from Google Play, otherwise it will be the program that installed your app. If this is another app store then great, you have found it.
If the result is something like a web browser then it is harder as the user got the app from a website. Then your best option is Google searching. The normally easiest way is include your app name and the word "APK". This tends to find most sites serving your app. You could even search for your app name, "APK" and "4.0.0" as many website list the version code on the page.
I've recently published my very first app to Play Store. I asked a friend to download and test it and it crashed on his phone. However, I have an exact phone as him with the same version of Android, and when I tested it the app runs without error. So what do I need to know about a device to re-create the bug?
So I've just figured out that Google Play Console there is a feature called Pre-launch report which give you the log of the bugs from user's devices, it is under Release Management tab on the left of the web page.
If you are a developer then can not re-create bugs because you would test with best-cases of app.You should test with worst-case scenario.
I will recommend to use a professional Tester to test your application. He/She must find out the bugs.
We are adding Android Auto and iOS CarPlay support to the existing Android/iOS versions of an app. We are able to successfully test the Auto application using the Android Media Browser simulator as directed by the Android developer documentation.
We also have a stereo head unit that supports both Auto and CarPlay. We are able to use the CarPlay app successfully on the head unit, and we are able to use published Auto apps on the head unit. However, we can't see our development app on the actual device.
The Auto documentation is still a little bit thin, but I'm gathering based on some wording I've seen that Auto apps get some special flag (or similar) added by Google Play when they pass review:
Before making the app available to Android Auto users, Google Play
submits your app for review against the Auto App Quality criteria and
notifies you of the result. If your app is approved, Google Play makes
that app available to Android Auto users.
Based on this, is at all possible to run Auto apps on hardware before they've already been published and approved through Google Play?
This seems like a frustrating chicken-and-egg problem. We'd like to have the confidence that things look good on actual hardware and on target devices before publishing.
It is now possible to test your Android Auto apps on Auto-enabled head units. The procedure is to upload your app to the Play Store in an alpha channel, which you can then install to your device and test in a car. You will even receive feedback from the Auto review team for your app. [Wayne Piekarski]
Follow this
You can also install the Desktop Head Unit (DHU) to test it in software before submitting it to the Play Store. I used this method to make sure most of the quality issues were resolved with my app before submitting it. The DHU does not require the apk to be signed by Google.
Also, submitting it through the store usually takes several hours before you can test. The DHU is, obviously, immediate feedback.
Here's the link: https://developer.android.com/training/auto/testing/index.html
The short answer is no, you can not. It is due to the driver safety review. It will not be able to run on the real device until the app is approved.
But I think, you can contact Google and they can do something about it, if you really need to test it in your car.