Standard Translation Framework about smali

[JesusFreke]

Comment #1 originally posted by JesusFreke on 2010-04-25T03:13:54.000Z:

Wow. Let me try to tackle this.

"Smali/BakSmali, ApkTool, and related systems need to establish a comprehensive
standard data format"

First, I have nothing to do with apktool, or with "related systems". smali and
baksmali are only concerned with processing dex files. Assembly, disassembly, deodex,
verification, etc. The "standard data format" is the .smali file. It is a well
defined grammar, although not well documented. The documentation is in effect the
code. There is of course documentation on the individual opcodes in AOSP.

"so that version dependent and host dependent issues such as android sdk failing to
be stable"

smali and baksmali do not rely on the android sdk at all. You can run smali and
baksmali without even having the android sdk installed.

"do not effect the recoverability and portability of existing and future tools."
Smali and baksmali are standard java and should run just about anywhere java runs.
You can even run dx on baksmali and run it directly on the phone. Unfortunately,
smali requires too much memory to run on a g1 at least. It might run on something
with more memory, say an N1.

"Their interdependency is obvious and should be merged/standardized,"

I'm only vaguely familiar with apktool. I don't really know what it does. But I
subscribe to the idea of writing tools that do 1 thing and 1 thing well. I have no
desire to have smali/baksmali merged with apk tool, or with the "related systems" you
mention (whatever those are). I'm quite happy with the current scope of functionality
smali and baksmali.

"but inline trace and runtime verification should be handled on-board"
huh? smali/baksmali doesn't have anything to do with tracing or runtime verification.
I don't even know what you mean be "handled on-board". On-board what?

"as should an api/interface to standard data for visualization and editing"
I'm not really sure what "standard data" you are talking about, or what kind of
visualization you want to do. As for editing, any old text editor is sufficient to
edit .smali files. I agree it would be nice to have some sort of integrated IDE type
environment for .smali files, but that's outside the core scope of smali/baksmali. A
language plugin for, say, Intellij IDEA might be useful. But it would likely be a
separate project from smali/baksmali.

"There is no reason a client wishing to use (restrict) only one application should
have anything else running or accessable on the machine".

Huh?

"full decomp-inline-rip-optimize and rewrite core with tool is an easy target for
these projects"

again, huh?

"I am more concerned with code audit and on-board compiler and system visualization
especially"

So, you're wanting to audit installed applications? And you're wanting to compile
applications on the device? Good for you - I have no idea what this has to do with
smali/baksmali.

"especially when the host changes so severely due to Google/etc's incompetence"

Again, huh? host changes? I have no idea what you are talking about.

I'm having a really hard time extracting any sort of meaning from your issue. There
are lots of words there, and they all seem to be put together correctly. But I have
no idea what changes you are requesting that I make in smali/baksmali.

If you want to explain in more concrete terms, I'll be happy to re-open the issue, or
try to consider what you're saying. As it stands, there's nothing actionable here.

[JesusFreke]

Comment #2 originally posted by JesusFreke on 2010-04-25T08:52:10.000Z:

He added exactly the same issue in my 2 projects and I really don't know, what does
he mean ;-) I decided to reply here.

"Smali/BakSmali, ApkTool, and related systems need to establish a comprehensive
standard data format"

(bak)smali and apktool "cooperation" is fine. JF doesn't care about apktool, but
smali is mature and stable project, so I don't have problems with integrating its
newer versions into apktool.

"so that version dependent and host dependent issues such as android sdk failing to
be stable"

Send your "standard data format" suggestions to AOSP. Android resources system is SDK
version dependent, so how could apktool be not?

"Smali and baksmali are standard java and should run just about anywhere java runs."

Same for apktool.

"Their interdependency is obvious and should be merged/standardized,"

There is no interdependency, there is one-way dependency. And this is normal that one
library/tool uses another, right?

Rest of your words are just "WTF do you mean? O_o" for me. I have a feeling, that you
saw this:

http://www.youtube.com/watch?v=P_Zyf7jFbx4#t=6m09s

, but misinterpreted some things.

[JesusFreke]

Comment #3 originally posted by JesusFreke on 2010-04-26T14:55:29.000Z:

If ApkTool and Smali/BakSmali could leverage their synergies and create a core competency and save unit cost, it
would create organic growth where users could hit the ground running and be an overall win-win. Just having a
boilerplate, state-of-the-art client-centric best practice in place for the users seems like a low-hanging fruit.
Using fuzzy logic in this application should allow us to leap the digital divide to the next generation mobile
mashup. I like how this project's visibility has increased quarter-over-quarter and gained mindshare. It has
cemented it as a mission critical brand in which the tail risk has been minimized by pure unadulterated
modularity.

[JesusFreke]

Comment #4 originally posted by JesusFreke on 2010-04-26T15:44:28.000Z:

@kenny
Hah, marketing bullshit generator :-D I thought about such tool too when I was reading
wilfredguerin's comment ;-)