I used to access different versions submitted to Google Play's closed test track using their sharable URLs:
https://play.google.com/apps/test/{package_name}/{version_code}
Now it's not working and I'm only seeing the latest version which is available to testers on Google Play. What's going on?
Related
we've got an app that's not on the market yet and we are struggling with the testing version that testers download. We're trying to set the v1.0.1 but Google Play redirects them to v1.0.0 which is not up to date. We even tried to deactivate that branch but the issue still insists.
I do a lot of test deployments for multiple test groups.
Google supports 3 separate types of test groups: Open, Closed, Internal.
Open Testing is literally open to anyone who wants to opt in and they can join via a link you can copy from the developer console. Open testing requires the app go thru review before being rolled out.
Closed Testing is similar to Open but you explicitly define who has access with a list of email addresses. Closed testing must also pass through a basic Google review before being rolled out.
Internal Testing is similar to Closed testing but it never goes through a review process. Again, this is controlled via a list of email addresses.
I routinely publish different versions where Internal has the latest bleeding edge.
You don't state which channel you are using (Open, Closed, Internal), but I would carefully review each channel and the email addresses associated. Then I would click on the Publishing Overview button on the console to see if there's something you haven't finished.
This question already has an answer here:
Security Considerations - ChromeDriver - Webdriver for Chrome
(1 answer)
Closed 2 years ago.
I need to use chrome driver to automate web navigation using selenium.
However, the work computer that I use did not like it, I had to bypass a couple of security blocks. When I dowloaded chrome driver I tried to run it in the cmd terminal which threw up a link and a recommendation that I should read its contents. the link was the following:
https://chromedriver.chromium.org/security-considerations
The link's web page contained a series of warnings about running chrome driver on a computer that has privileged access to information. My computer happens to have just that.
I need to find a way of automating website navigation with or without chrome driver, what should I do??
This is probably because it can do stuff like access websites that you might not want to access, either because its private data or because its a site that you arent allowed to access by law. Pretty sure that, as long as you dont run scripts from others, and know what you are doing yourself you arent taking a risk. The main problem is, that you might not be able to cancel it anymore if it runs once. If you rather do it in another way, you can use the geckodriver from firefox, i have not had such a warning yet but i assume the risk is the same
I was trying to publish a new version of an Add-on that was already created, but when I tried to publish it, in the Developer Dashboard and on the top of the page a warning message was shown:
As of November 21st, 2016, all newly published packaged or hosted apps are restricted to Chrome OS, and are not available to users on Windows, Mac or Linux. Existing apps will continue to be available on all major platforms and will continue to receive updates. - More Info
Note: This change does not apply to Google Drive Apps or Add-Ons for Google Apps.
So if you click on the "More Info" button you will see more additional information.
So all of this should be a problem to me because I have important applications that I need everyday, so I wonder if there is any other alternative way to keep working with add-ons.
Thank you!
AFAIK, this change (if Google decides to proceed with it) would only apply to Chrome Apps (see my answer here).
In the Chromium Blogpost (also the link for More Info in your post), it mentioned:
In the second half of 2017, the Chrome Web Store will no longer show Chrome apps on Windows, Mac, and Linux, but will continue to surface extensions and themes.
Add-ons weren't specifically mentioned, but as already included in your post, Add-ons that are for Google Drive Apps or any Google Apps in general (e.g. Docs, Sheets, etc.) are the exception.
If you're add-on is associated with a non-Google App, it is possible that you will be affected with the change. Seeing as the Chrome App will be removed, the associated Add-ons would follow.
You probably already know the differences between a Chrome App, an Extension, and an Add-on, but for future readers that are not familiar, might as well post this link to a YouTube video that explains Apps vs Extensions vs Add-ons.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are planning to built cross platform desktop application. We found that Node-Webkit is a perfect choice for us. But GitHub developed their own framework called Electron instead of using Node-Webkit.
What is the difference between them?
Electron has a page explaining the differences with nwjs.
Like NW.js, Electron provides a platform to write desktop applications
with web technologies. Both platforms enable developers to utilize
HTML, JavaScript, and Node.js. On the surface, they seem very similar.
There are however fundamental differences between the two projects
that make Electron a completely separate product from NW.js.
Entry of Application In NW.js, the main entry point of an
application can be an HTML web page. In that case, NW.js will open the
given entry point in a browser window.
In Electron, the entry point is always a JavaScript script. Instead of
providing a URL directly, you manually create a browser window and
load an HTML file using the API. You also need to listen to window
events to decide when to quit the application.
Electron works more like the Node.js runtime. Electron's APIs are
lower level so you can use it for browser testing in place of
PhantomJS.
Node Integration In NW.js, the Node integration in web pages
requires patching Chromium to work, while in Electron we chose a
different way to integrate the libuv loop with each platform's message
loop to avoid hacking Chromium. See the node_bindings code for how
that was done.
JavaScript Contexts If you are an experienced NW.js user, you
should be familiar with the concept of Node context and web context.
These concepts were invented because of how NW.js was implemented.
By using the multi-context feature of Node, Electron doesn't introduce
a new JavaScript context in web pages.
Note: NW.js has optionally supported multi-context since 0.13.
Legacy Support NW.js still offers a "legacy release" that supports
Windows XP. It doesn't receive security updates.
Given that hardware manufacturers, Microsoft, Chromium, and Node.js
haven't released even critical security updates for that system, we
have to warn you that using Windows XP is wildly insecure and outright
irresponsible.
However, we understand that requirements outside our wildest
imagination may exist, so if you're looking for something like
Electron that runs on Windows XP, the NW.js legacy release might be
the right fit for you.
Features There are numerous differences in the amount of supported
features. Electron has a bigger community, more production apps using
it, and a large amount of userland modules available on npm.
As an example, Electron has built-in support for automatic updates and
countless tools that make the creation of installers easier. As an
example in favor of NW.js, NW.js supports more Chrome.* APIs for the
development of Chrome Apps.
Naturally, we believe that Electron is the better platform for
polished production applications built with web technologies (like
Visual Studio Code, Slack, or Facebook Messenger); however, we want to
be fair to our web technology friends. If you have feature needs that
Electron does not meet, you might want to try NW.js.
Keep in mind this may be biased- it is from Electron's wiki page.
Electron doesn't introduce
a new JavaScript context in web pages.
Source code protection
Electron is packaging its applications with asar, which contains the applications' unprotected source code. This makes it possible for application 1 to extract application 2 and inject vulnerable scripts, without the user knowing it. You can checkout this project on GitHub to see an example of how to manipulate the Slack app for an example. As for now, the Electron team don't have any plans to implement support for source code protection.
NW.js has built in support for compiling your source code to protected binaries.
This question already has answers here:
What's the best way to test cross-browser compatibility?
(4 answers)
Closed 9 years ago.
when we develop any website then it looks good at our end but client may view the page with different browser then he/she face problem. i search for tool or way by which i can view my pages from my local machine using different browser and different version. i found few web site provide this facility and saw they very slow and they are giving image of my page which i do not want rather i want to view my page in browser. so i want a tool which allow me to select browser and version and then show my page in that browser with specific version. i may change version and page should refresh for changing browser or version. i hope there must be many tool available but unfortunately i not getting right single one. can anyone guide me. thanks
Adobe shut down BrowserLab a few weeks ago, but provided some guidance for other services that you can use on this page. There there are the Spoon.net browser sandboxes, but it installs the VM on your computer and I never liked that.
I personally use VMWare virtual machines with olders versions of IE on Windows, and Safari on a Mac VM. A little more effort to set this up, but I find it works best.