superandroidanalyzer / abxml-rs Goto Github PK

We are not taking advantage of the new Cargo.toml keywords, and they should be added. This is the list of keywords we should add in the [badges] section:

• travis-ci = { repository = "...", branch = "master" }: Adds Travis-CI build information.
• appveyor = { repository = "...", branch = "master", service = "github" }: Adds Appveyor Windows build information, depends on #58.
• coveralls = { repository = "...", branch = "master", service = "github" }: Adds Coveralls coverage report, but we might want to switch to Codecov, since it works much better (#59). In that case we would need to add codecov = { repository = "...", branch = "master", service = "github" }.
• is-it-maintained-issue-resolution = { repository = "..." }: Adds information about issue resolution time.
• is-it-maintained-open-issues = { repository = "..." }: Adds information about open issues.
• maintenance = { status = "..." }: Adds information about the current maintenance status. Options are actively-developed, passively-maintained, as-is, none, experimental, looking-for-maintainer and deprecated. I would propose passively-maintained, but suggestions are welcome.

We should also add the categories keyword to the [package] section.

For more information, check the Package metadata section in the Cargo documentation.

The Failure crate was created to replace error-chain. We should change the code to use it.

I get the following from get_attributes of the root element of an AndroidManifest.xml parsed with this library:

{platformBuildVersionCode: @flags:28, android:versionCode: 10042, android:versionName: 9.17.3.1, android:compileSdkVersion: 28, platformBuildVersionName: @flags:9, android:compileSdkVersionCodename: 9, package: cm.aptoide.pt}

The platformBuildVersionCode: @flags:28 and platformBuildVersionName: @flags:9 appears to be a slight mis-parse? For comparison, here is the output of the same APK file from apktool (and is matched by JADX):

<?xml version="1.0" encoding="utf-8" standalone="no"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" android:compileSdkVersion="28" android:compileSdkVersionCodename="9" package="cm.aptoide.pt" platformBuildVersionCode="28" platformBuildVersionName="9">
 ...snip...

Let me know if providing the affected APK helps. FWIW, this isn't an isolated thing and I get the same result from a bunch of APKs downloaded from apkpure.com.

We should add Windows tests in Appveyor to have a more complete CI.

Some Clippy warnings show that the correct way of implementing to_owned methods is using std::borrow::ToOwned. I think it's a good idea to implement it that way.

We are currently using Coveralls for code coverage report. This service has been unreliable in the past, and I propose to move it to CodeCov as we did with the main SUPER repository.

Seems that we get to run this code: src/apk.rs#L44 even if there is no dist folder in SUPER. What could be happening?

More info: SUPERAndroidAnalyzer/super#121 (comment)

As we did with SUPER, we should have more possible labels to indicate difficulty of issues or areas of the crate.

Now that async/await is stable, we can rewrite / extend the API using async-std to improve the performance of code using this ABXML reading library.