Closed GoogleCodeExporter closed 9 years ago
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 JesusFr...@gmail.com
on 25 Apr 2010 at 3:13
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
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 kenny@the-b.org
on 26 Apr 2010 at 2:55
@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
Original issue reported on code.google.com by
wilfredg...@gmail.com
on 25 Apr 2010 at 1:49