Related
I have an app with the usual Google ad and in-app-payment stuff. It's accepted into the Play Store all right. Now I'd like to make it support both GMS and HMS at the same time (based on the availability of the appropriate services, the app can decide which platform to use). The app, with the Huawei functionality built in, works just fine while testing on my own devices.
However, as soon as Huawei's libraries are bundled with the app, the Play Store Console simply refuses it. No error message, just a red exclamation point. There's no doubt about the situation, I started to remove the Huawei-related parts one by one and as soon as the last bit was removed, the bundle was automagically accepted again.
Yes, sure, I might have made some error I'm not aware of but the situation is, well, rather suspicious. If it makes any difference, I use Flutter and I try to upload an app bundle, not APKs, as per normal these days. The HMS library that seems to make it or break it is com.huawei.hms:hwid:4.0.0.300 from the maven repo at https://developer.huawei.com/repo/.
So, am I just seeing things or not?
Update:
OK, the quest goes on.
This is quite recent news: https://support.google.com/googleplay/android-developer/answer/9934569
Any existing app that is currently using an alternative billing system
will need to remove it to comply with this update. For those apps, we
are offering an extended grace period until September 30, 2021 to make
any required changes. New apps submitted after January 20, 2021 will
need to be in compliance.
No matter what the policy says, the Play Console seems to enforce it already. And as I found by looking into the app bundle, the flavor approach is just not enough. Even with the other flavor, there will remain some packages referenced by Flutter. Maybe just the referenced names, not the actual code after tree shaking, but this is already enough for the refusal.
So, at the end of the day, I really think this question needs to be sorted out and some clear guidelines found for and by ourselves, developers, if we really want to write cross-ecosystem, single source Flutter apps. As for me, I sure want to do it.
I have finally found a kind of a workaround, not automatic, but a useable approach.
Create two subpackages inside your project. They look like normal Flutter packages but reside inside your app. Basically, create two folders, gms_support and hms_support beside your usual lib. Both are packages with the usual structure:
lib
lib\Xms_support.dart
lib\src
lib\pubspec.yaml
Put all your vendor-dependent stuff into identically structured files inside the respective lib\src folders and make sure both XXX_support.dart files export them the usual way. The implementations should use the same classes and same signatures. Each pubspec.yaml refers to its own, vendor-specific Flutter plugins required for their implementation.
Your main app pubspec.yaml contains both references:
dependencies:
...
gms_support:
path: gms_support/
hms_support:
path: hms_support/
Also, add another support.dart inside your main app:
export 'package:gms_support/gms_support.dart';
export 'package:hms_support/hms_support.dart';
Wherever you need vendor-specific behavior in your app, you import and use this support.dart file.
Then, when you have to change from one flavor to another, you always have to change three things in sync:
the flavor (see the details of your IDE)
comment out the other export in support.dart
comment out the other reference in pubspec.yaml and make a pub update
Different App store has different requirements for In-App Purchase Kit. The possible cause for the Play Store Console refusing your app is that your app integrated with other IAP Kit, and it does not meet the requirements of the app store review guide. You are advised to make your project support different app packages for different channels, to adapt different app store requirements.
Supporting Multiple Flavors
If your app needs to support multiple build types or flavors, configure the agconnect-services.json configuration file downloaded from AppGallery Connect for your app to implement the function. The agconnect-services.json file provides configuration information required by various services in your AppGalleryConnect project. Therefore, if you need to use multiple flavors to release different app versions, copy the agconnect-services.json file to the folder of each flavor and configure it.
Supporting Multiple Channels
If your project needs to support different app packages for different channels, the package name needs to vary depending on the channel. Change the package name in productFlavor in the build.gradle file under the app directory.
productFlavors {
huawei{
// Unique package name.
applicationId "com.example.demo.huawei"
resValue "string", "app_name", "Huawei"
}
amazon{
applicationId "com.example.demo.amazon"
resValue "string", "app_name", "Amazon"
}
}
The preceding sample code shows different packaging configurations for different channels, Huawei and Amazon. The package names are different for the two channels. If the same agconnect-services.json file is used for the two channels, the package name verification fails.
To support multiple channels, you need to add the agconnect-services.json file to the flavor folder of only the Huawei channel and ensure that the AppGallery Connect plug-in version in the project is 1.2.1.301 or later classpath'com.huawei.agconnect:agcp:1.2.1.301'). If the plug-in version is earlier than 1.2.1.301, upgrade it to 1.2.1.301 or later.
For more information, see docs.
The Dart FakeAsync package seems to have the same functionality as quiver.testing.async inside the Quiver package so as a Flutter and Dart app developer I'm confused as to which one to use?
Is one supposed to be used over the other in particular circumstances? nothing in the documentation for either package gives any guidance on this either. Both packages also seem to be authored and maintained by members of the Google Flutter and Dart teams which makes it even more confusing.
The only thing I can see is that FakeAsync package is last updated in July 2018 while Quiver was in Nov 2019, so is FakeAsync deprecated? if so it's not labelled as such. And also a small number of core packages currently depend on FakeAsync, while a very large number of diverse package depend on quiver (though can't know if they depend on quivers testing.async).
I tried (with limited success) to dig into the muddled history.
FakeAsync was a third-party contribution to quiver, and a few months later, the author forked package:fake_async from quiver's version. I don't know what the rationale was for having two separate implementations, but I could guess that perhaps the author wanted to have more direct control over the code. (In other words, package:fake_async initially was not authored nor owned by Google.)
I asked around, and my understanding is that package:fake_async stopped being maintained, and Google's Dart team ended up taking ownership of package:fake_async so that it could be updated for Dart 2.
From package:fake_async's changelog, it does appear that it was meant to be a superset of quiver's version, but the implementations have since diverged so that it's no longer fully backward compatible.
At this point, I personally would use the quiver version: it's better maintained and is what Flutter uses, so I expect that it has much more inertia behind it.
I've also filed https://github.com/dart-lang/fake_async/issues/16 requesting that guidance be added to the documentation.
Update
I now recommend using package:fake_async. Flutter moved in the other direction and switched to using package:fake_async instead. package:fake_async has been updated to be a proper superset of of the quiver version. Also see https://github.com/google/quiver-dart/issues/590.
I want ot take copyright information of all open source components which are used for embedded system.Is there any short way to get the copyright information of OSS components?
Well, you've got your ${TMPDIR}/deploy/licences which has subdirectories for all recipes built. Those subdirectories inludes copies of both the license-files from those recipes, as well as the generic licenses for the declared licenses of those recipes.
There is also a subdirectory <image-name>-DATETIME, that includes eg a license.manifest, that lists all packages installed in the image, together with their licenses.
That very much depends on your concrete setup; which of course you completely fail to describe here. How should we know which OSS components you are using in your embedded system?!
But the general answer is: there is no detour. When your product is using OSS components, and you want to "track" that; then you have to do the tracking work.
That means:
You have to create a catalog of all OSS components that are included in your product (and the version in use). Ideally, that would be no-op, because your build / library setup already makes such a distinction.
Then you use that catalog as input, to determine the licence for each and any of these components.
Finally, depending on the specific licence, you determine the effects of using OSS component X for your product.
I have minimal exposure to RPM, Windows installer mechanics, and WIX. That said, I'm interested in making a cross-platform installer tool (Linux, Windows) that supports upgrading and downgrading (versiona and patches) of my own product. I don't believe this is a topic to be approached lightly; I would like to learn the science of the art (or the art of the science). If I succeed, and build a minimally successful installer tool, it would have these features:
does not depend on a platform-specific tool (such as Windows Installer).
reads XML or a declarative syntax to fulfill installation requirements.
attempts to minimize steps to upgrade or downgrade one of my products (rather than requiring a complete uninstall and re-install).
does not require knowledge of interim product versions, in order to jump versions (i.e. can upgrade one of my products from version 1 to version 3, without passing through version 2).
I'm convinced that "the key" to achieving this goal is by seeing versions as a "point A to point B" problem, which implies that A and B are described by two XML "version" documents that hold info about all the parts and actions (files, or platform specifics such as registry entries). My installer tool would "join" or compare the two documents and determine a minimal set of changes to transform A into B. To some extent, I believe this is precisely what Windows Installer does.
Of course there are further complexities, but that is the point of this post. Where is "the bible" of information on this topic? Remember, I want to make my own installer - not use a platform-specific one. For those who care, my products are usually written in C++ or C#.
Or perhaps I should study something like Steam which is cross-platform and has "automated game updates" as part of its capabilities. In my case, the problem of online deployment is already handled. It is just the final installation step I'm examining. Does Steam use native installers (such as an MSI)? If yes, then that is not what I'm looking for.
In short, what path should I pursue to become somewhat competent on the science of this topic?
I'm not an expert and others can give you better answers but...
Don't declaratively list steps required to install your product - You'll end up making assumptions which will eventually prove wrong. Instead, you should be looking at defining the final state of the installation and let the installer worry about how to make that happen.
Another consideration is that being downgradable may involve huge complications depending on your product - Would it have to down-grade database schemas / file formats / ??? In short, every version of your app will need to be both fully forwards- and backwards-compatible (or at least fail gracefully). Also consider the scenario where V1 of your app stores settings in a file. V2 comes along and adds more settings. You downgrade to V1 - What should it do when changing settings? preserve the V2 settings? dump them? Do some of the V2 settings change the impact/meaning of the V1 settings? Are these decisions to be made by your app or your installer?
Anyway, all that aside, I'd say you need at the least:
A central server/farm with complete files for every version of your App and some API/Web Service which allows the installer to retrieve files/filesets/??? as appropriate (You may be able to tie this into a source control system like svn)
Some way of specifying the desired post-install state of the system in an environment-agnostic way (Think install paths - /usr/??? - should the map to C:\Users\??? or C:\Program Files on windows? Also don't forget it might be a 64-bit machine so it could be C:\Program Files (x86).
A very clever installer written for multiple platforms with as much code re-use as possible (Java, Mono, ???)
The installer should do (simply):
Determine the desired version of the product.
Download/read the appropriate manifest.
Compare the desired situation with the current situation (NB: What is currently on the local system, NOT what should be on the system according to the current version's manifest)
Generate a list of steps to reconcile the two, taking into account any dependencies (can't set file permissions before you copy the file). You can make use of checksums/hashing/similar to compare existing files with desired files - thus only downloading the files actually required.
Possibly take complete backups
Download/unpack required files.
Download/unpack 3rd party dependencies - Later .Net Framework Version/Similar
Perform install steps in atomic a manner as possible (at the very least keeping a record of steps taken so they can be undone)
Potentially apply any version-jump specific changes (up/down-grade db, config files, etc.)
verify installation as much as possible (checksums again)
None of this addresses the question of what to do when the installer itself needs upgrading.
A technique I've used on Windows is that the installer executable itself is little more than a wrapper with some interfaces which loads the actual installer dynamically at runtime - thus I can move files about/unload/reload assemblies, etc... from within a fixed process that almost never changes.
As I said above, I am definitely not an expert, just a novice who's done some of this myself. I sure you can get more complete answers from others but I hope this helped a little
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've met quite a few people lately who says that 3rd party libraries doesn't belong in version control. These people haven't been able to explain to me why they shouldn't yet, so I hoped you guys could come to my rescue :)
Personally, I think that when I check the trunk of a project out, it should just work - No need to go to other sites to find libraries. More often than not, you'd end up with multiple versions of the same 3rd party lib for different developers then - and sometimes with incompatibility problems.
Is it so bad to have a libs folder up there, with "guarenteed-to-work" libraries you could reference?
In SVN, there is a pattern used to store third-party libraries called vendor branches. This same idea would work for any other SVN-like version control system. The basic idea is that you include the third-party source in its own branch and then copy that branch into your main tree so that you can easily apply new versions over your local customizations. It also cleanly keeps things separate. IMHO, it's wrong to directly include the third-party stuff in your tree, but a vendor branch strikes a nice balance.
Another reason to check in libraries to your source control which I haven't seen mentioned here is that it gives you the ability to rebuild your application from a specific snapshot or version. This allows you to recreate the exact version that someone may report a bug on. If you can't rebuild the exact version you risk not being able to reproduce/debug problems.
Yes you should (when feasible).
You should be able to take a fresh machine and build your project with as few steps as possible. For me, it's:
Install IDE (e.g. Visual Studio)
Install VCS (e.g. SVN)
Checkout
Build
Anything more has to have very good justification.
Here's an example: I have a project that uses Yahoo's YUI compressor to minify JS and CSS. The YUI .jar files go in source control into a tools directory alongside the project. The Java runtime however, does not--that has become a prereq for the project much like the IDE. Considering how popular JRE is, it seems like a reasonable requirement.
No - I don't think you should put third party libraries into source control. The clue is in the name 'source control'.
Although source control can be used for distribution and deployment, that is not its prime function. And the arguments that you should just be able to check out your project and have it work are not realistic. There are always dependencies. In a web project, they might be Apache, MySQL, the programming runtime itself, say Python 2.6. You wouldn't pile all those into your code repository.
Extra code libraries are just the same. Rather than include them in source control for easy of deployment, create a deployment/distribution mechanism that allows all dependencies to easily be obtained and installed. This makes the steps for checking out and running your software something like:
Install VCS
Sync code
Run setup script (which downloads and installs the correct version of all dependencies)
To give a specific example (and I realise this is quite web centric), a Python web application might contain a requirements.txt file which reads:
simplejson==1.2
django==1.0
otherlibrary==0.9
Run that through pip and the job is done. Then when you want to upgrade to use Django 1.1 you simply change the version number in your requirements file and re-run the setup.
The source of 3rd party software doesn't belong (except maybe as static reference), but the compiled binary do.
If your build process will compile an assembly/dll/jar/module, then only keep the 3rd party source code in source control.
If you won't compile it, then put the binary assembly/dll/jar/module into source control.
This could depend on the language and/or environment you have, but for projects I work on I place no libraries (jar files) in source control. It helps to be using a tool such as Maven which fetches the necessary libraries for you. (Each project maintains a list of required jars, Maven automatically fetches them from a common repository - http://repo1.maven.org/maven2/)
That being said, if you're not using Maven or some other means of managing and automatically fetching the necessary libraries, by all means check them into your version control system. When in doubt, be practical about it.
The way I've tended to handle this in the past is to take a pre-compiled version of 3rd party libraries and check that in to version control, along with header files. Instead of checking the source code itself into version control, we archive it off into a defined location (server hard drive).
This kind of gives you the best of both worlds: a 1 step fetch process that fetches everything you need, but it doesn't bog down your version control system with a bunch of necessary files. Also, by fetching pre-compiled binaries, you can skip that phase of compilation, which makes your builds faster.
You should definitively put 3rd party libraries under the source control. Also, you should try to avoid relying on stuff installed on individual developer's machine. Here's why:
All developers will then share the same version of the component. This is very important.
Your build environment will become much more portable. Just install source control client on a fresh machine, download your repository, build and that's it (in theory, at least :) ).
Sometimes it is difficult to obtain an old version of some library. Keeping them under your source control makes sure you won't have such problems.
However, you don't need to add 3rd party source code in your repository if you don't plan to change the code. I tend just to add binaries, but I make sure only these libraries are referenced in our code (and not the ones from Windows GAC, for example).
We do because we want to have tested an updated version of the vendor branch before we integrate it with our code. We commit changes to this when testing new versions. We have the philosophy that everything you need to run the application should be in SVN so that
You can get new developers up and running
Everyone uses the same versions of various libraries
We can know exactly what code was current at a given point in time, including third party libraries.
No, it isn't a war crime to have third-party code in your repository, but I find that to upset my sense of aesthetics. Many people here seem to be of the opinion that it's good to have your whole developement team on the same version of these dependencies; I say it is a liability. You end up dependent on a specific version of that dependency, where it is a lot harder to use a different version later. I prefer a heterogenous development environment - it forces you to decouple your code from the specific versions of dependencies.
IMHO the right place to keep the dependencies is on your tape backups, and in your escrow deposit, if you have one. If your specific project requires it (and projects are not all the same in this respect), then also keep a document under your version control system that links to these specific versions.
I like to check 3rd party binaries into a "lib" directory that contains any external dependencies. After all, you want to keep track of specific versions of those libraries right?
When I compile the binaries myself, I often check in a zipped up copy of the code along side the binaries. That makes it clear that the code is not there for compiling, manipulating, etc. I almost never need to go back and reference the zipped code, but a couple times it has been helpful.
If I can get away with it, I keep them out of my version control and out of my file system. The best case of this is jQuery where I'll use Google's AJAX Library and load it from there:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>
My next choice would be to use something like Git Submodules. And if neither of those suffice, they'll end up in version control, but at that point, its only as up to date as you are...