可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
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.
回答1:
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.
回答2:
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
.
回答3:
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
You can Drag & Drop needed APKs and then provide the Link for test users to download specific APK.
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
回答4:
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!
- Install and use your "old" app
- Save data via
adb pull /data/data/com.company.app $LOCALDIR
- Update to your new app version via IDE or adb
- 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
回答5:
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...
- Uninstall any current installation of your app
- Install the latest PlayStore version
- Open the app, log in, do whatever it needs to fill your database and settings
- Install the new, updated App version. This has to be signed with your release keystore or the update will fail
- 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!
回答6:
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);
}
}
}
回答7:
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!