Request for Code Review: Android XML (androidmanifest.xml) Parser in Rust

Hello Rust community,

I am working on a project that involves parsing Android's AndroidManifest.xml file. The goal is to extract useful information from the binary XML file. I have implemented a solution in Rust, and I would appreciate any feedback or suggestions for improvement.

The project is available on GitHub at the following link: GitHub - ariqa-labs/bxmlrs

Here's a brief overview of the project:

  1. The parser is designed to parse binary AndroidManifest.xml files, which are typically found inside APK files. The binary format is not officially documented.

  2. The parser does not support parsing generic binary XML documents or decoding resource identifiers. Its main purpose is to extract useful information from the AndroidManifest.xml file.

I am particularly interested in feedback on the following aspects:

  • Any potential performance improvements.
  • Suggestions for making the code more idiomatic Rust.
  • Any potential issues or edge cases that the parser might not handle correctly.

Looking forward to hearing your thoughts and suggestions!

Best regards,

1 Like

before anything, I'd just like to say, most of the library is beautiful in my opinion. you have the perfect amount of nesting, the code looks easy to maintain, and there's not too much code. that being said, there's a couple big things and small things you could do to make the project better, first, the small things:

  1. you could the data you're matching in bxmlrs/src/attributes.rs from being 0x10 => Some("foo".to_string()) into 0x10 => "foo", and then just handle the rest of the code after that. this is easy to implement and would take a couple extra kilobytes from the final executable.
  2. maybe add a readme.md file for anyone that wants to change something in the code? the code still is small, so this doesn't matter too much yet, but it's best to do it now before the code gets too big, at that point, it would take hours to create such a file.

now that i finished these small things, there's a couple big things that you could do to make the code faster and easier to read:

  1. in rust, most of the time it's best to use a third party module to solve an issue, of course, it shouldn't be at the javascript level of getting a package for checking if something is even. but still, you are parsing the xml from scratch and then parsing the actual things in AndroidManifest.xml that are different then a normal xml file. i looked up "xml parsing" on crates.io and already found xmlparser and roxmltree. i know you would probably not be able to switch to those crates because your code is already done, and replacing that code with those crates might require remaking the entire code, but still, i am almost sure xmlparser is faster then your code (you can read the crate's docs and see why). but if you ever want to update your project, then it might be better to use these crates instead
  2. for some reason, it seems to me that a lot of your code is just repetition. sometimes it does make sense, like with error handling with the thiserror crate, but other times it seems to be very obvious like with the entire bxmlrs/src/attributes.rs file. in terms of memory usage, those might be the best way to handle that memory. but if you ever need to reuse the values inside of attributes.rs for a different reason, then you'd have to change the entire file. it would be best not to copy and paste code like this, but to instead find a way to have to write as little code as possible.

btw please remember, us programmers are not people that write code, we are people that solve problems. try to write as little code as possible to solve as many issues as possible. regradless, i hope this helps you make the parser a little faster, since it looks very promising. if it keeps on being as beautiful as it currently is, then i think i would actually use it every once in a while.

2 Likes

Thanks @pretro

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.