I wish to carry out pre release testing of my current Android Application.
My requirements for this testing are:-
My Application must not appear in the Google Play Store or...
Only invited testers can see the Applications Play Store Page
Only invited users can participate in testing.
Testers do not have to have a gmail account.
Total number of testers < 10,000.
Testers are automatically contacted with download link.
From what I have read (Chatted) on Google sites my choice is between Alpha or Beta testing.
for Beta testing
Open beta
Use an open beta when you want any user who has the link to be able to join your beta with just one click.
One of the advantages of an open beta is that it allows you to scale to a large number of testers.
However, you can also limit the maximum number of users who can join.
Closed beta
Using email addresses – If you want to restrict which users can access your beta, you have a new option:
you can now set up a closed beta using lists of individual email addresses which you can add individually
or upload as a .csv file. These users will be able to join your beta via a one-click opt-in link.
Closed beta
with Google+ community or Google Group – This is the option that you’ve been using today, and you can continue
to use betas with Google+ communities or Google Groups. You will also be able to move to an open beta
while maintaining your existing testers.
Beta satisfies almost all of my requirements however I cannot allow my application to be searchable on the Play Store and I do not want to require my testers to have/use a gmail account so Beta testing is out.
So my only choice is Alpha.
I am still not clear on the "flavours" of Alpha testing available.
If I have to manually distribute the Alpha app link why do I upload a list of emails?
What purpose does the uploaded list of emails have?
Is the list of uploaded emails used to control access to the Alpha apk?
Can I run Alpha test groups of 1000's of testers.
As far as I know, it is not possible to invite a user to test without a Google account (but a Google account can be created without a GMail address). Besides, alpha (internal) testing is only available for 100 people, and closed beta testing is only available for 2,000 people. Therefore, I think it is not possible to do a closed testing for 10,000 users with arbitrary email addresses.
Take a look at this Google support answer for more details.
Hope this helps,
Xavi
Related
I recently asked this question and user's #DalmTo and #Sergio NH they gave me an exhaustive answer for which I thank them very much.
Moving forward to question, we started publishing the application, and its verification was not required, since no scope was added (here it is a little unclear why the requests worked in an application with a test mode in which these scope were not added (google drive, google sheet and google ads)).
However, this time the application in the "In Production" mode began to give us an "Unverified app screen" (see Unverified app screen). We decided that we still need to add scope to the list, and, of course, that the scope list (their list is described above) requires verification by Google.
We started filling in the necessary fields, while studying the Google documentation at the same time, and came across the following information (see block Verification process -> What are the requirements for verification?):
Apps not applicable for verification
Apps for internal use only
(single domain use) Apps for personal use only Apps that are Gmail
SMTP plugins for WordPress Apps that are in development or
staging/testing
Apps for personal use only
And this is just our case: we have already received permission from Google Ads and are just generating simple reports that we want to integrate with Google Sheet. I.e., this is an elementary script that works within this account (however, we still need to request the first concert screen, even for this developer account) and cannot be distributed to any other accounts.
But when adding our scope, Google requires us to pass verification, forcing us to fill in the required fields, in the form of domains and their verification via the Search Console (we have already done this and this stage does not cause difficulties) and links to Youtube videos - where we must show how scope is used.
And just this stage is not clear. We do not allow other people's accounts to connect to this application, and the software does not have any interface, it is just a script that receives data from Google Ads and saves it to Google Sheet (creating a file via Google Drive). We have described all this in the scope usage description field. But the link to the Youtube video is require field, and we sincerely do not understand why (considering our case) we should record something, and most importantly, what exactly we should record in this case. If the documentation itself says that in our case we do not even need a verification.
Maybe we did not understand something and now we are doing it wrong? We will be glad to receive any tips from experts working with Google Cloud Console and apologize in advance for broken English.
We also apologize in advance to the StackOverflow community that we have to publish such elementary (which we are absolutely sure of from our side) questions here. We come here from Google Cloud Console - > Support - > Community support, and we must first try to publish posts in the Google Groups specified there, but they simply do not answer us, apparently considering our questions too elementary and not worthy of attention (however, these same questions in Google Groups are moderated) (for example, the previous question). And we are no longer able to contact any other support. Once again, we apologize for having to ask about this here.
It is true that if your app is a single use app then you do not need to be verified.
However if you don't get your app verified then there will be some restrictions.
you will see the unverified app screen
your refresh tokens will probably only be good for two weeks.
In the case of the YouTube api uploaded videos will be suck private.
If you can live with those points then you don't need to verify your app and you can continue as is.
If on the other hand you don't want to see the unverified app screen and you want a refresh token that will last longer then two weeks. You will need to verify your app. Yes, Even if your app is a console application running as a job some where you still show the consent screen. This is the YouTube video you will need to show Google. Show the consent screen popping up show the URL bar and then show your script running. You also need to set up the homepage and privacy policy screens. Yes i 100% agree with you that this is silly.
When you go though the process. Explain to google that this is a single use script running as a job some where.
Unfortunately when Google changed it so that Refresh tokens expire for unverified apps they pretty much tied the hands of all developers who are running such single user scripts. We now have to get our apps verified if we don't want to have to request a new refresh token every two weeks.
If your program needs to access the requested scopes of the Google account privacy, even though the user is yourself, you also need to provide a youtube video to demonstrate how you use this program. The auditor cannot guarantee whether you will make this program public.
I'm trying to implement Google pay on the web by this example: https://developers.google.com/pay/api/web/guides/paymentrequest/tutorial.
When I remove "PAN_ONLY" from the example code, the button becomes invisible on my PC and on smartphone.
Under what conditions with the authentication method "CRYPTOGRAM_3DS" payment will be available?
I'm using the latest version of Google Chrome.
Tokenized cards are only available from your Android device today, where there are the means to securely authenticate the transaction and store sensitive information related to your forms of payment.
There are initiatives in the industry aiming at adding means of security and second factors to the web. These are expected to help the utilization of tokenization on the Web too.
I successfully published my first skill in US and DE. While extending to more regions I run into account linking problems that I cannot reproduce in DE.
Is there any best practice of efficient testing in multiple countries before triggering the certification.
So far I read that you should change the language setting of the amazon account - which seems very unconvenient if you have to test for 6+ countries. I am seeing two possibilities which both have flaws:
Note: My developer account is also my private family account which is also used by my wife.
If I create a new Amazon-Account just for testing, I cannot access the dev stage skill since the owner is the private family account, right?
If I change the country settings on the private family account, my wife loses the link to the Kinde library and can't use any of the remaining shopping services, right? Furthermore it is tedious to change these settings multiple times a day during development...
How are you testing?
Is there anything else available for testing and debugging that I just do not know about, yet?
Thanks in advance!
To test the skill, you can use the Alexa Simulator from the Alexa Developer Website. Use the "Test" tab to switch between regions / languages and use the text box or microphone button to test the skill.
For account linking, and in particular, using new Amazon accounts. You can use the Beta Test functionality to invite your new account to test the skill. This can be found under the "Manage Beta Test" and will let you invite people by email to test the skill. This will let you resolve your first issue.
This is in reference to:
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
which asks to post questions on stack overflow under #google-oauth.
Two questions from the developer of an email app for Android.
There are users who have more than one Gmail account, and they don't want to have to add all of them into system Settings.
For accounts which are present in system Settings, I use Google Play Services, it works almost every time, so that's not the scenario I'm discussing.
For accounts not present there, I currently use a WebView to open https://accounts.google.com/o/oauth2/auth and it just goes from there.
1:
Can someone please clarify what "new OAuth clients" means here?
New installs of existing apps (using WebView)?
Or brand new apps?
What are those "user facing notices" going to look like?
2:
What about Android devices that don't have Chrome installed?
Not all do, and I believe it needs Android 4.1 whereas my app runs on 4.0.3+.
Does this mean the owners of these devices are now going to be out of luck?
I today get Instagram api and add my website live,
I see write:
Client Status: Sandbox Mode GO LIVE
I can't click on ''GO LIVE'' button why ?
You would need to start a submission for approval to go live, though:
Feeds for websites won't be approved; these will remain in sandbox mode and be limited to 500 requests per hour and 20 images. This doesn't sound like much especially for large clients, but if you cache your responses, it's not a problem.
The main confusion is because they have made it sound like every app/feed has to be approved and out of sandbox mode to work, where as the reality is that only fully functioning apps for phones, or a widget plugin really ever need to be.
You will no longer be able to display feeds based on hashtags, only a users own photo's. By getting a client to be a sandbox user, is how you can access their feed without their login information.
Older apps/feeds will need to be updated to use the new code before June or they may stop working.
It's mainly to stop apps hammering instagram's servers for unlimited requests on any hashtag/users they like.
Here is an example of how to fetch and cache images using WordPress's 'set_transient' - you will need to use a loop to output the data.
WordPress Instagram Gist
Here is the relevant piece of information in the dev docs:
Here are some examples of scenarios that will not be approved:
To display content for a personal website. If you are a developer and you want to showcase Instagram content on a website, then you do not need to submit your app for review. By using a client in sandbox mode, you will still be able to access the last 20 media of any sandbox user that grants you permission.
One-off projects. If you are an agency building websites or other integrations, note that we don't grant permissions to clients created for one-off projects. If you are interested in building a product, platform, or widget that will be used as a service across multiple projects, then you may submit a single client_id that you can use across multiple projects.
To use a widget. If you are installing a widget for your website, then you do not need to submit for review. Some widgets may ask you to create a new client id, but you do not need to submit it for review for the widget to work. Your client can remain in sandbox mode and the widget will have access to your last 20 media.
Hope that helps clear some confusion.