Standard Translation Framework

[GoogleCodeExporter]

Standard Translation Framework

[GoogleCodeExporter]

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.

Original comment by [email protected] on 25 Apr 2010 at 3:13

• Changed state: Invalid
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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.

Original comment by Brut.alll on 25 Apr 2010 at 8:52

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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.

Original comment by [email protected] on 26 Apr 2010 at 2:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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

Original comment by Brut.alll on 26 Apr 2010 at 3:44

• Added labels: ****
• Removed labels: ****