How to test app update on Google Play?
Asked Answered
L

8

20

Let's say I have the app in Google Play Store with version 1.0.

In the new version (1.1) I would like to upgrade the database with new columns.

Database upgrading is a common crash in my application because users in previous version (1.0) doesn't have the new columns in the database.

I have tried to use the Google Play Store's beta testing feature, but the problem is there is no effective way (or at least I haven't found one yet) to do the following:

Install a the current stable version (1.0) to the tester's device, then update the application to (1.1) - let's say we got an error during the playtest of the new updated version (1.1), I repair it (1.2) and I would like to repeat the procedure, I would like to install the 1.0 stable app to the tester's device and yet again I would like to update the app to 1.2 (with the resolved error)

The only way (as far as I concern) is to remove the beta tester from the beta testing list (could take hours to refresh in Google Play systems), re-download the 1.0 application, re-add the tester to the beta testing list, (again waiting hours) and download the new 1.2 application.

Is there a more sophisticated way to test app version updates?

Thanks in advance.

EDIT:

It would be nice if I could do this with other people testing my app. So the less programing and command prompt usage needed the solution is the better.

Legate answered 8/9, 2017 at 9:44 Comment(0)
T
4

I use Beta for painless beta distributions for iOS and Android apps.

From: Overview

You want feedback early and often throughout your development lifecycle. With Beta, you can easily send beta builds to your users. You’ll automatically get usage stats and stability metrics for all your builds, so you know when you’re ready to ship.

I find it very useful and use beta in conjunction with crashlytics for crash reporting. Below are the advantages:

  • You can automate the build with Android Automation for Continuous Delivery and has support for beta via gradle.
  • Build is available instantly to all the testers.
  • All builds are archived and can is available at anytime.
  • Dynamically add QA engineers, track progress, add QA engineers dynamically by creating and sharing the build.
  • Access to all build release notes with build(apk) and build version.
  • Further more if the build is approved by QA engineers, one can directly upload the same apk to playstore with fastlane from gradle itself.
Ticker answered 11/9, 2017 at 12:32 Comment(0)
M
9

You don't need the Play Store for testing database upgrade.
You can just use an emulator. Drag&Drop version 1.0 (this will install the app), open the app, and Drag&Drop version 1.1.

There isn't any real "upgrade" feature. It's just an install of the new version.

By the way, you can add the news columns in onUpgrade of SQLiteOpenHelper.

Malamud answered 8/9, 2017 at 9:52 Comment(0)
P
7

As I understand the main question was not related to database but for general possibility "How to check that update from version 1 to version 2 will gone fine for end user?"

I found the way to do it with Internal app sharing. This is a place where you can put your APK versions, setup emails for test users who can access your APKs.

Go to

Google Play Console > Development Tools > Internal app sharing > Upload link

enter image description here

You can Drag & Drop needed APKs and then provide the Link for test users to download specific APK.

enter image description here

It works for me exactly how I expected.

Now I can check on the Android device that next updates will be successful for my users.

0.0.9 to 0.0.11

0.0.10 to 0.0.11

Presumably answered 24/7, 2019 at 16:10 Comment(1)
Cannot find the Development tools anymorePolytechnic
T
4

I use Beta for painless beta distributions for iOS and Android apps.

From: Overview

You want feedback early and often throughout your development lifecycle. With Beta, you can easily send beta builds to your users. You’ll automatically get usage stats and stability metrics for all your builds, so you know when you’re ready to ship.

I find it very useful and use beta in conjunction with crashlytics for crash reporting. Below are the advantages:

  • You can automate the build with Android Automation for Continuous Delivery and has support for beta via gradle.
  • Build is available instantly to all the testers.
  • All builds are archived and can is available at anytime.
  • Dynamically add QA engineers, track progress, add QA engineers dynamically by creating and sharing the build.
  • Access to all build release notes with build(apk) and build version.
  • Further more if the build is approved by QA engineers, one can directly upload the same apk to playstore with fastlane from gradle itself.
Ticker answered 11/9, 2017 at 12:32 Comment(0)
B
2

You really don't need the beta channel to test app updates. You only want to use the beta channel once you are done testing and want to start receiving user feedback.

To test an app update the most basic way would be to...

  1. Uninstall any current installation of your app
  2. Install the latest PlayStore version
  3. Open the app, log in, do whatever it needs to fill your database and settings
  4. Install the new, updated App version. This has to be signed with your release keystore or the update will fail
  5. Test the app update

Fix errors and repeat.


Step 1. is to make sure you get the PlayStore version as your users would. Uninstallation is the best way to make sure the app data is cleared. Afterwards you just install the app as any user would in 2..

You have to at least open your app once, or it will not run. Populate your app with data, as a user would, so that you can properly test the update. The 3. step is to set up your test data.

In step 4. keep in mind that you only need an app that is signed with your release keystore, but it can still be debuggable. You can still attach a debugger and check what's going on in case there are more serious errors.
If you properly configured your build.gradle file you can just press the Play button in Android Studio after selecting the release build variant. You can either modify the release config to be debuggable while testing, or create a third buildType that is release signed, but debuggable.

Have fun testing.


If you're using a VCS

If you use a version control system (VCS)—which I really hope that you do—you can also just build & install a previous version before updating with your latest snapshot. The same steps apply, only that in step 2. you build and install a previous version yourself.
Compared to using release versions of your app, this might be easier in some cases, because you don't need access to the release keystore and you can just use debug signed apps without the need to change anything in your build.gradle.

This approach requires that you keep track of which version is currently released, or you might testing the wrong updates. So keep sure to tag your releases!

Borisborja answered 12/9, 2017 at 19:10 Comment(0)
T
2

I'd recommend to backup your data to easily test and tweak your migration code. This only works on the emulator or a rooted device!

  1. Install and use your "old" app
  2. Save data via adb pull /data/data/com.company.app $LOCALDIR
  3. Update to your new app version via IDE or adb
  4. Test your migration

No need to install the old app again from now on.

For retrying the migration: 1. adb push $LOCALDIR /data/data/com.company.app 2. Test your migration 3. Fix your migration code and repeat

Tintinnabulation answered 15/9, 2017 at 8:39 Comment(0)
G
0

This is quite easy and you can test it by changing the database version yourself. You don't even need to update version code in your manifest file. My answer is valid if you are using a SQLite database and SQLiteOpenHelper class.

First, increase database version inside SQLiteOpenHelper class.

public DatabaseOpenHelper(Context context) {
    super(context, DATABASE_NAME, null, DATABASE_VERSION);
}

When you update version of constructor onUpgrade() method of SQliteHelper class will be invoked. You can test it by using println or log methods.

    @Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
    this.oldVersion = oldVersion;
    this.newVersion = newVersion;

    if(oldVersion == 1 && newVersion == 2) {
          // add columns
    } else if(oldVersion == 2 && newVersion == 3) {
         // Do another stuff
   }
}

You can define your logic between updates. For example an user may have version with 1, miss version 2 and 3 and install update with version 4 of database, you should consider that too if necessary. Updating logic is unique to you.

For example, if users have old version below a certain version and you wish to create a new db or table on a specific version,all users have versions below 6 and you wish to delete database or table on version 6, you can get all values from tables to list or lists or to any data structure, then create new database and/or tables and then move new values from that list that contains objects and add null properties for new columns to new tables. Users won't notice a thing but behind the scenes you will be able to change database or tables without no problem. I use this often when i wish to add rows or recreate database.

if (oldVersion == 2 && newVersion == 3) {

        previousMeasures = dbManager.getMeasureListAnglePhoto();
        db.execSQL("DROP DATABASE dbOld.db");
        db.execSQL("DROP TABLE IF EXISTS " + TableConstants.TABLE_ANGLE_PHOTO);

       onCreate(db);

      if (previousMeasures != null) {
        for (Measure measure : previousMeasures) {
            dbManager.addMeasureAnglePhoto(measure);
        }
    }
}
Gilbertson answered 16/9, 2017 at 18:56 Comment(0)
C
0

So as some pointed out best is to find you release commit in version control check it out again and run/build app in debug mode. Then just to take build.apk from build/outputs/apk/debug and store it somewhere so you can use it to test compatibility when upgrading.

Then just simple drug drop to simulator make som changes and now you can run app over it form you latest version in debug mode and check out how it works, then again make some fixes uninstall drag and drop and run latest again to see if user experience is flawless.

When you have this debugable build for testing preserved, workflow of this testing is good otherwise there is just no clean solution for this.

Calculus answered 22/5, 2023 at 10:22 Comment(0)
S
-2

You must use a "work mode" previously provided.

Every release you compile (the one compiled in release) on androidstudio and deposits on the playstore you have to keep it locally, you have to keep track of everything you've done previously and to do this it's good to use a special tool. I personally use the "subversion" application, but one is as good as the other.

1) Manually install (without using googleplay) the old apk (the verison release NOT THE DEBUG VERSION) on the devices (taking it from the subversion application).

2) Take (always manually without using googleplay) the new version (NOT THE DEBUG VERSION) and install it ... the update will start and you can EXACTLY test what will happen on the devices.

If you are only interested in testing the update part of the database (onUpgrade to understand):

I in my app have a "button", visible only in the test phase, that launches a "restore database";

Install the apk NEW and launch the restore (from a button test) of any previous version (to do this you need to recover the database .db file of your previous version of the app) and in this way the OnUpgrade will start because you will notice that the restored database has a lower version.

This is the only way I have found to test my updates without having to go crazy with betatester, googleplay, versioncode, upload, download, etc, etc ... it works!

Seymourseys answered 12/9, 2019 at 16:14 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.