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.
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 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.
I have a question concerning Android app development. I'm about to develop an app that I want to give to test users. Testing the app on my own phone means plugging it in my laptop and updating it manually. Do you know any solution that provides automatic updating for in-progress-apps without plugging each phone in on each update?
Maybe there is a google play store function I don't know about yet that lets you "hide" you app before publication and you can share the link with designated people?
Thank you a lot!
The Play Store offers alpha and beta testing, which allows you to upload and distribute test builds via the Play Store.
If you use this feature, you control which version of your application testers will receive on their devices, and they will automatically get updates.
You do not need your application to be publicly available to use this feature.
We have a fleet tracking Android app which is isntalled on around 100 mobiles.
Problem is to update each mobile whenever there is a patch release. And unfotunately we have not set auto-update.
Now we need to call each driver and follow the process of update from google play.
This is becoming very tedious as they have to go to google play, search the application and install/update it.
And the mobiles are located all over the country.
Before it was easy as Goolge play was giving an option to know the apps installed on each mobile.
Need your advice on how do we manage/automate this update issue.
Build an in-app push notification that there's a new version and have an easy link to Google Play from it. However, this does have a bootstrapping problem, and you will have to make everyone install the new version manually (as in you call them and ask them to do it) at least once. Still, this is your only viable option, as Google Play developer agreement prohibits pushing app updates through other channels.
If you have email or IM contact with the drivers, you can also send them a message there's a new version with the direct link to the Google Play. They will have to open it on their device, of course.
The link format should be market://details?id=com.mycompany.myapp, https://play.google.com/store/apps/details?id=com.mycompany.myapp, or http://market.android.com/details?id=id=com.mycompany.myapp. Either of these three in general should work, though some OEMs have messed up their devices configuration and prevent Google Play app from intercepting the http/https form properly.
You could check a text file located on a server or something like that and then lookup if the current instaleld version is the same as the server version. If not you could download the new apk and open it. As far as I know this is not allowed by Google Play so you must remove the app from google play
I am about to write an App which is customized to Macau, a city in Southern China. I am experiencing some uncertainties and would like to seek help from the fellow developers.
I have checked with Android Dev Guide and found out that we have gotta sign the App with self-generated key or a digital certificate issued from Certificate Authority. May I know whether there are any differences in the user experience when downloading and using the App for self-generated key or digital cert from CA? I heard that Symbian Apps would display alert message like "This App is untrusted" if the App is not formally verified. I do not want this to happen in my App, and I am worried about other tiny differences.
Moreover, I would like to ask about the requirements for digital certificate for signing the App. Is there any specification? Must the key be a .keystore file for signing? I am thinking about applying one from the Post Office for signing, but am worried whether it works.
From the Google Dev Guide, it says we need to plug the Android device to the computer using USB and run the App and perform testing using the computer. May I know more about the testing procedures from the experienced? After this debugging process how can I test the App on a standalone Android phone just like using the App normally? Can I simply sign the App with debug key in the debug mode and use it on the device? Must the device be developer device or Nexus One for performing testing?
If I publish the App to the Web server, i.e. users can download the file and use my file, would my source code be leaked out and get accessed by other people?
Last but not least, as I am developing the free App in Macau, I was stuck when I saw that Macau is not on the developer location list. I wonder whether I can publish my App on the Android Market. When I settle the Google Checkout payment, which option should I choose as my location, as neither China nor Macau is on the list. Should I choose "Hong Kong", my neighbouring city, or simply click "US" for convenience? Can the Android users in Macau download my App from the Android Market? (I cannot see Macau on the supported distribution location list...)
I would really appreciate it if you could kindly answer my loads of questions. Thank you very much!
That's way to many questions for one post, but I'll take a shot at a few.
You must sign your app using a keystore. It should be one you created, but hey, that is your choice. Any app not downloaded from the market is considered "untrusted" and users will receive that error upon installing it.
As far as debugging, you can debug on an emulator and/or a device (phone). Most people will recommend both. Information about how to get started can be found on the Android Development website. More specifically, you can try this
or this.
You can sign the app with a debug key if you setup USB debugging on the phone.
You publish apps as .apk files, which is complied code, not source. Even then it is hackable, just like anything else.