I implemented a continuous integration pipeline using Jenkins, but as final step I want Jenkins to deploy/upload the signed APK file to Google Play Store and AndroidPit. I looked for Jenkins/Hudson plugins but only found two: one for Appaloosa and one for Zubhium.
I have a working developer account both on Google Play and on AndroidPit and can manually upload the APK that Jenkins produces. But my question is: Does anybody know a way to teach Jenkins (e.g. via a shell script?) to upload the APK to the mentioned app stores?
There is a Google Play Android Publisher plugin for Jenkins which uses the Google Play Publishing API, announced at Google I/O 2014.
Google has also released Java and Python libraries to help make use of the API.
For more info on the API, see also:
http://android-developers.blogspot.com/2014/07/grow-with-google-play-scaled-publishing.html
I can talk only for Google's Play Store. There is a way, but be warned, it isn't beautiful, you have to code your solution. I am right now writing a Bachelor Thesis to solve this problem - "Continuous Delivery for Android Applications". My solution is mine, this means I don't raise a claim to have the perfect solution, but I can say it is quite working prototype.
I found out the following:
The first Solution is none. Google offers an Play Store API, but it lacks to upload stuff. Seems that they were already thinking about to make such an API, but it only offers In-App billing control
The 2nd solution is to use Apache HttpComponents Library, which lets you implement your own Client for the Google Play Developer Console, but HttpClient lacks a JavaScript Interpreter... Several ways to implement or add one. But of course, not the easiest way.
The 3rd Solution I am working on, is to use Selenium Web Browser Automation Framework. So basically I create PageObjects from those Play Store Pages and dialogues. After that you can create some Factory to maintain "pathes" of controlling these PageObjects.
Using them you have two options as far as I can see, for instance the WebDriver Objects which uses an "invisible" browser process like FF or Chrome and another I use is ChromeDriver which uses a visible Browser process, to perform the User actions. And don't forget to have Exception Handlers, which scans the Webpage for appearing errors, while in use.
There are a lot of pitfalls, due to possible changes in the Design from Google, which lets your Software break. But there are also some ways to handle that. =) And create an XML containing all valueable information about an app, which comes in handy, when continueing to the next step.
You can create a Maven Plugin. This you can load into your Continuous Integration Server. I hope I could help you a bit.
Since Google Play released the upload API, a plugin has been made:
https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=73533143
I haven't tried it yet, but looks like it's exactly what we were looking for.
There are other plugins that claim to do the same (thanks #mdt)
https://github.com/DavidHamm/google-play-publisher 404-this page does not exist
https://github.com/orrc/google-play-android-publisher-plugin
I believe it is not included in the PlayStore API currently to reduce stress on the system and to avoid abuse.
I believe we may see this in the gradle plugin and in the IDE in the future.
While we wait for google decide to open up the API, here is a solution, that is so sill, that i just had to propose it:
If you have a GUI, use GUI automation for the last step.
Google Play Android Publisher plugin for Jenkins is a good one. However, it doesn't support uploading descriptions and screenshots (at least for now).
I found decent Gradle plugin, called Gradle Play Publisher. It supports uploading apk, updating Metadata, and uploading screenshots. And it only needs a few steps to setup.
First go to Google Play Console in a browser, open the page for your app, and look for the option to allow a new email address to upload APKs. If it's not there, it probably means you are not the administrator of that Play Store account and you need to ask the person who is the administrator to add it for you (on a per-app basis). To find out what email address to add, go to Google Developer Service Accounts and create a JSON key for any of your existing Google developer service accounts, or create a new service account with a JSON key. Note the email address associated with the service account for which you have created (or will create) the JSON key. It will most likely be something at gserviceaccount.com. This is the email address that must be given permission to upload APKs by someone who has admin access to your Play account.
After that has been done, download Madison Dickson's updated version of Marta Rodriguez's script via wget https://gist.githubusercontent.com/mix3d/665f4ab329b4482297a2f425ebba402c/raw/0949385dd6c80d0701170746b1bd5fd479303412/basic_upload_apks_service_account.py and install dependencies via pip install google-api-python-client (or sudo pip install google-api-python-client as appropriate).
Then in the automated script you can use (for example) python basic_upload_apks_service_account.py -t beta -p org.example.MyApp -s JSON_file_I_made.json -a MyApp.apk (assuming your JSON file, your APK, and basic_upload_apks_service_account.py are all in the current directory and the pip install has been done on that machine or container).
I strongly recommend uploading to beta (hence -t beta in the above) rather than directly to production. Just in case something breaks and it somehow gets as far as the APK upload. I think the final press of "rollout to production" should always be done by a human. But if you really want to do that automatically as well, you can use -t production instead.
Related
I want to release my mobile app(Flutter) freely to use it myself, but passing the application certification in AppStore and GooglePlay is so hard.
Is there any way to release my app?
For yourself, just use adb install to install via command line. For others, put the compiled apk file on a website somewhere. It can be downloaded and installed, they just need to toggle a setting that prevents outside software.
I've released 10+ app on GooglePlay, and as far as i know, if you want to publish your app there, you will need to follow all of their procedures. I personally don't think it is that difficult to fulfill all the requirements.
As an other alternative, you can simply upload your .apk file on your blog/site and tell people to download it from there.
However, using GooglePlay/AppStore as the platform to launch your app will give more credibility to your app, as people will tend to consider downloading from blog as 'not safe' (might be infiltrated by other unintended software).
My app is now in the alpha status and I would like to distribute it to a few people (QA, alpha testers...) without making the app public. I know, that google play offers a private channel to distribute apps in alpha/beta state to some people, but according to the website it takes a few hours until the application is available. However, I would like to have it available for users as soon as a new build is ready and uploaded. I thought about setting up a private android repository (e.q f-droid), but unfortunately I could not find anything in the documentation about securing the android repository - I want it to be protected somehow (key, password...).
Another possibility would be to set up a web-server and host the different build versions on that server. Then the testers have to navigate to that site and download the appropriate build version. However, from the usability point of view it isn't that nice - user have to download the version manually and install it afterwards. Also for the QA guys it would be nicer, if it is easier to switch between different android builds.
How would you solve this problem? Is there already any software out there, that is suitable for that task?
Any help is really appreciated.
I know Google says it can take a few hours, in my experience, it happens very quickly, a few minutes at most. I don't know if there are times when it takes longer.
I thought about setting up a private android repository (e.q f-droid), but unfortunately I could not find anything in the documentation about securing the android repository - I want it to be protected somehow (key, password...).
While perhaps not in the docs, F-Droid does support HTTP Authentication on its repositories. For example, if using Apache you can add a relevant .htpasswd and .htaccess file in the webroot. This will result in the webserver sending back a 401 and asking the client to authenticate. F-Droid responds by prompting with a username/password dialog.
I would suggest using Crashlytics. Crashlytics is now integrated in Fabric.
Crashlytics allows you to distrubute beta versions of your app. Testers only have to install the install the Crashlytics app, and enable installing apps from different sources. You specify which users can test the app by emailadress.
The app allows testers to switch between any version of your app, and install any possible other apps they are invited for.
You can also integrate Crashlytics in your app. If you do you get notified of errors that occured complete with stacktraces, and additional information about the device. This makes bugfixing easier.
I have to distribute Android apps within my organization. I have a google developer account. Below it tells to login to the admin console to enable private channel.
https://support.google.com/a/answer/2494992?hl=en
Problem -it does not sign me in as Google help states that
my.account#company.com, doesn't have an administrator but is instead managed by Google.
Requirement - So how can i get the administrator account.
Any help will be appreciated.
Regards
You can provide the .apk files directly to your organization.
Either you can allow to download a signed .apk file through a web site which will launch the install procedure or you can make an app market which provides a list of .apk files and installs them automatically, as Amazon's App Shop.
I'm not sure if Google account allows you to share app locally. But we use Hockeyapp to do the same. It works great. You can even integrate it to your app and upload the crashes too. Many other features. Take a look at this to know other solutions. It supports iOS as well as Android and offers a good user experience.
But you've to pay a bit for it. CashAnalytics is free. Do small research for yourself.
I have used crashlytics for this purpose in my last project.
It works great for beta distribution in development phase.
Also, it's crash reporting is excellent to guide you to the source code line causing crashes.
I realize that this is sort of a broad and perhaps vague question, but I'm looking for some common strategies for self-updating an app in android (not via Google Play, but directly from the application itself). Perhaps I could embed the actual app's APK within another APK which does the updating, but then (1) could the updater even modify itself while it's running and (2) more generally, how might one prevent another (supposedly malicious) app from modifying the updater? Any tips, links, or thoughts on the matter would be greatly appreciated!
I'm looking for some common strategies for self-updating an app in android
There is really only one strategy that I can think of:
Step #1: Determine that an update is available (e.g., monitor some URL for latest-version info)
Step #2: Download the update
Step #3: Kick off the install using ACTION_VIEW or ACTION_INSTALL_PACKAGE (latter available on API Level 14+), at some point when the user requests it, since the user will need to approve the update
could the updater even modify itself while it's running
The app being updated will have its process stopped during the update.
how might one prevent another (supposedly malicious) app from modifying the updater?
The update has to be signed by the same signing key as signed the original version, no different than via distribution through the Play Store. Hence, protect your signing key with your life (or perhaps with somebody else's life, if there's anyone around wearing a red shirt).
One thing to be aware of is that Google doesn't like this sort of behavior at all. Google bans self-updating Android apps...
Google has now changed the Google Play store polices in an apparent
attempt to avoid Facebook-like end runs around store-delivered
updates. Under the "Dangerous Products" section of the Google Play
developer policies, Google now states that "[a]n app downloaded from
Google Play may not modify, replace or update its own APK binary code
using any method other than Google Play's update mechanism." A
Droid-Life article says the language update occurred Thursday. APK
(standing for application package file) is the file format used to
install applications on Android.
I'm not sure if your app is or will ever be on Google Play, but if so I'd advise against doing this, as it could jeopardize your developer account.
Amazon's documentation is surprising lacking in information about the submitting binary process. From what I can tell, you submit an unsigned binary and they wrap it in their own code and produce a signed apk?
This leaves several questions:
Does the Amazon App Store perform a zipalign for you?
If you have your app in the Android Market (Google's) already, is it recommended to use the same package name or a different one? Does it make any difference?
I also saw elsewhere, that they offer the option to download the apk they prepare and sign it with your own key. Is it recommended to take this and then sign it with the same key you are using in the Android Market? Does it make any difference?
Are there any other considerations or pitfalls that one should know before diving into this process?
Yes. Amazon wraps your binary with code specific to their appstore that allows them to collect analytics data and enforce DRM. The app will be repackaged after that.
You should use the same package name. The Amazon distribution agreement currently has a number of provisos; e.g., that your app is not priced lower on another app store. They also do occasional checks to see whether the version of your app on the market is up to date. These checks are primarily done using the package name; changing the package name of your app could easily be viewed by them as a means to evade the terms of the agreement.
No. There may be good reasons why one would want to do this, but none that I can think of. By default, Amazon signs your apk with a signature that is specific to your Amazon developer account.
Other:
Read this. In particular, ensure that the app links correctly to the Amazon app store and not the Android market, or others. I don't have inside data, but I'd wager a fair amount that the vast majority of submissions that Amazon turn down fall afoul of that requirement.
Edit: Point 2 is no longer correct; see comment below.
Here is the reply I received from the amazon mobile app distribution team for a question concerning whether to submit signed or unsigned apk's:
"You can submit signed, or unsigned binaries to the store - we will then apply our signature to your app in either case. If you need to sign your app with a known signature (if you are using Facebook authorization for example) you can choose to upload your app using our self signing process (you will need to ask us for this to be enabled for you)."
The most straight forward way to submit an app is to export your signed apk from Eclipse (all zip aligned are ready to go), then upload via the Distribution Portal using our DRM and signature.
For the latest update of my app I just took the same signed apk I previously released to google play, and it worked well.
I have only published two little applications that sell almost nothing, but both got aproved and I followed exactly the same procedure I follow for publishing on the Android Market: I just exported the signed .apk from eclipse and also used the same package name. So far I have no problems, so I guess it's ok.
You should zipalign during every build, as a matter of practice.
I use the same exact build process for Amazon as I do before publishing to Google. Only difference is an Interface's variable to determine the market link (at build time, if/else is compiled out).