The help text on Google Play Console is confusing. While we can set up a release to rollout for an internal test, it says* that a rollout to any track automatically sets the status to Published, and makes it visible on Google Play.
It must be possible to provision the test release to the internal testers before it is rolled out and visible on Google Play, right? How?
See "New Apps" at https://support.google.com/googleplay/android-developer/answer/6334282?hl=en&ref_topic=7072031
I think the confusion comes from the statement "visible on Google Play". It is visible on Google Play, but only visible to people who are in the internal testers list. No-one else can see it or find it in search results.
The benefit to it being "visible" on Google Play are things which require this, like testing in-app purchases or license verification work.
Related
To perform a Private Publishing of Google-Sheet Addon in GSuite/Chrome Web Store for QA team.
Steps Executed:
Created a project in script.google.com and using clasp, pushed the latest code for google-sheet addon into it.
The prepared the manifest.json per Google’s requirement (attached for reference)
Then selected “Deploy as add-on” from publish.
Beforehand, prepared the zip, logo and screenshot per Google’s requirement.
Then on “Deploy as add-on” screen, selected “Add-on Type” as “Sheets” in addition to filling other fields as required.
Then went to Chrome Web Store>Dashboard page to upload the zip, image, screenshot, provided description, selected category, etc. and finally selected “Visibility options” as “Private”.
At the end, I published the changes.
Are these steps correct or have I missed something?
How to get this add-on visible in google-sheets opened by the tester that is added in “testers accounts”? Per Google, I have to share the complete link of the add-on with the tester. Then What is the point of adding the testers into “Testers accounts”.
Also, it is appearing as “Extension” in “Chrome Web Store”. Is it correct?
In the list of "My Executions" on the Developer Hub there is a project that keeps showing up named "Advanced Summary by Awesome Table" that I have just noticed. Just one of them shows the script as running 166,847 times with 24,178 users. The container is not owned by me (the owner is shown as "Support Account"), neither is the project. This is listed as an Add on. I have no idea why this is executing and I can not stop it. Executions continued to run, a few every second. The Project's OAuth scope concerns me.
Does anyone know what this might be?
If you google "Advanced Summary by Awesome Table" it comes up as a Chrome Extension, available from the Chrome Webstore. If you enter chrome://extensions/ into your browser I expect you will see it.
If I look at my personal My Executions (removing the filtering so I see everything), I too am seeing records for Add-ons (i.e. my chrome extensions); see picture below. So I guess that this is fairly normal. Although I don't see 'container' or 'owner' information, or understand how to check the OAuth scope. So I'm not sure what you are referring to there; perhaps you could provide a screen-shot?
Thanks for your reply. At one time I did add the Awesome Table add-on, but removed it more than 18 months ago. Unlike the other add-ons that I see in the My Executions list, the Awesome Table on is clickable. Here's what I see when I do that: Advanced Summary by Awesome Table
Here is project's OAuth: OAuth Scope
And the container is this: Form
I don't own this form and I have no idea why this onOpen is is running so often by so many. It really does concern me.
Basically, my question is the same than this topic but it's now 2018. So, how can I still have ECMAScript executed on my phone (to send geolocation position) even if it is asleep? We now have Open Web Apps and Progressive Web Apps (PWA) with service workers, even Apple is jumping in, I'm sure there are ways to do that.
While we can hope that things should've changed on this, unfortunately, it has not.
This article from Google on PWA GeoLocatoin API dated Jan-2018 says clearly that this API works "only while the page is open".
Why not available yet (in my opinion)? Thinking of users privacy, it makes sense. Think of tons of wep pages we visit and for how many we tend to five permission accidentally or we intend to give for a while(until we finish some transaction/booking). Currently there is no way for us to go and check on all location permissions that we've given to web sites in a browser, like we do for Native/Hybrid apps and having option to change it.
We can expect to have tracking option for PWA when it is installed to home screen, where native app like permission handling will be possible to user.
End of the story, we are not there yet!!
Alternate option: While you can use navigator.geolocation.watchPosition to track the user when he is actively using the app, You can complement your app with a separately installed (Native) Android service to update the users location to your back end server, till PWA supports naively.
I have a google form that I am having pushed out through a Kiosk App and that google form is going to be used for the foreseeable future. Since I am not a Network Engineer or Systems Administrator in my network, the only way of getting the webview element in my App to display the Google form is to hard code it's URL because I have nowhere from which to dynamically update the URL in my App at the moment.
I am also not the Chrome Administrator and because of this I need to send my packaged Kiosk App off site to have it pushed out to my building's Chromebooks which means that for every update that I do, I need to re-package it and have the Chrome guy update it manually.
Since I and many others would prefer to not perform the task noted above on a frequent basis, I am trying to find out how long the Google Form's url will last and/or how often we can expect it to change if it does ever change.
Surely if you have any concerns over the link changing, you can just set up a redirect from a domain you control.
That way even if the kiosk form gets upgraded from Google to something else, you can just change your redirect without recompiling and redistributing your application.
At some point in the last couple of days a bug seems to have materialised in my app's Google Drive integration, despite me not having changed anything, and usage remaining fairly constant.
When you left click one of the app's documents in Drive a new about:blank tab opens showing the app's icon and the text "Sorry, an error occurred while opening this file. Please try again. [XXXXX]" where [XXXXX] is a short string that seems to be different every time. The create new works fine, and if you use the right-click menu and open with it also works fine.
All of this makes me think that there is a bug in the latest javascript update to Google Drive's main interface.
In terms of debugging, in the apiconsole the app has...
The initiate oauth2 option unchecked
The allow multiple files option unchecked
Mobile browser support checked
24 mime-types, 61 primary extensions, and 1 secondary extension registered
If it is a bug as Claudio has mentioned, I believe Google Drive SDK documentation needs to be updated too, since 'open' action is described only for "Open With" option:
https://developers.google.com/drive/integrate-open
I'm wondering how to trigger the proper action when registred mime-type can be managed by more than one installed application? Is there a way to set the default open action - or the application which created it will be used as the default? What's happen if you reach the application web by typing the url (not from UI Drive UI create action) and save the content on Drive, since you may be already authorized to do it?