
Facebook Does It Again. Cheating Dalvik - redDragon
http://blog.mohitkanwal.com/blog/2014/08/11/facebook-does-it-again-cheating-dalvik/
======
tinco
There's a weird and arbitrary limitation in Dalvik, and the Facebook guys
needed to work around it. The author makes it sound like it's some horrible
sin. How about shaming the Google developers who thought 65k methods was
enough for anyone? Wouldn't be good proper either, because they probably had a
good reason for it.

Software development isn't always stacking neat abstractions on top of each
other. Sometimes you have real hardware and real legacy and you just got to
deal with it, one way or another.

~~~
drzaiusapelord
I imagine the devs and management don't care much as they're going to migrate
to ART soon, which I imagine does not have Dalvik's circa 2003 design
decisions. Google hasn't been investing in Dalvik because its days are
numbered.

edit: why is this being downvoted? Do we really think ART will have these
limitations? Android has been hot to get off Dalvik for many reasons and
they're finally doing it in L. This is very good news and makes Andy Rubin-era
Android decisions, which made sense for a 2003 phone, replaced with more
modern thinking.

edit2: Apparantly, I'm wrong. Looks like the 16 bit limitation in still there
in the current version of ART. Maybe this will change in the final production
version.

~~~
shawnz
I believe ART still uses DEX as an intermediate format, so it's possible the
limitations will still exist.

~~~
krschultz
It does still exist: [http://stackoverflow.com/questions/21490382/does-the-
android...](http://stackoverflow.com/questions/21490382/does-the-android-art-
runtime-have-the-same-method-limit-limitations-as-dalvik)

------
stickydink
We have this problem. We have a large, mostly-Java game for Android. It won't
run on gingerbread, because we just have too much code.

While the official solution looks quite brief, retrofitting it is a nightmare.
Unless Facebook got around to rewriting everything again, I can understand why
they'd do it their way.

~~~
tormeh
I don't think anyone with a phone running 2.x can run games. I have an HTC One
or whatever (4 years old; got it from a friend) and I could never ever imagine
playing a game on it. Even the home screen lags!

~~~
pjmlp
If you code in C++, which most games do, the Android version is not that
important, given the little exposure of Android APIs to the NDK.

Everything that matters, besides the existing graphics, sensors and audio
APIs, can be built with standard C++ libraries.

~~~
tormeh
The problem lies with the hardware, I think. Truly, there's never a smooth
moment with my phone. Sometimes it hangs for a minute. Random shutdowns and
similar bugs in software as well.

------
jhgg
I'm a bit confused by this article, the author mentions:

    
    
        While the official standard way to to fix this problem is described in the offical Android Blog.
        Seems like Facebook missed it. What a waste.
    

However, in the post linked by facebook, they explain why they couldn't use it
(vaguely)

    
    
        After a bit of panic, we realized that we could work around this problem by breaking our app into multiple dex files, using the technique described here (http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html), which focuses on using secondary dex files for extension modules, not core parts of the app.

~~~
redDragon
Yes i sort of forgot about it, the facebook article was old, i read it a long
time ago, i rediscovered the issue when running FB on one of the Gingerbread
devices.

------
coldcode
Google early on made decisions about code size that made sense at the time,
but now seem to be a serious limitation (at least in the interim). FB's
decision on getting around this architectural limitation isn't all that bad.
What I don't understand is how their solution can affect other applications.
As an iOS dev screwing up my app is one thing but being able to screw up other
apps seems like an even worse architectural problem.

~~~
dubcanada
I'm confused on how it can screw up another application? Aren't all the
applications sandboxed?

~~~
kevb
This hack can't screw up another application, the author is wrong about that.
It's changing the local process only and has no influence on any other apps
(which are not just sandboxed into their own processes but also their own user
ids)

------
smanuel
Zuckerberg 2012: Our biggest mistake was betting too much on HTML5

Zuckerberg 2014: Our biggest mistake was betting too much on Dalvik

~~~
ProAm
Sounds like his gambling problem is the issue.

------
j_s
Below are some choice quotes from the last time this came up almost 1.5 years
ago; interesting how the peanut gallery has mellowed over time.
[https://news.ycombinator.com/item?id=5321634](https://news.ycombinator.com/item?id=5321634)

> _I can 't believe an app requires 8M RAM just for method names!_ \-
> [https://news.ycombinator.com/item?id=5323153](https://news.ycombinator.com/item?id=5323153)

> _They bloated the app so badly, they would have had to monkey patch the OS
> to let it run at all_ \--
> [https://news.ycombinator.com/item?id=5323930](https://news.ycombinator.com/item?id=5323930)

> _Basically these engineers decided to be really clever, painted themselves
> into a corner, smashed a hole in the wall so as to escape from said corner,
> and then bragged about how great they are._ \--
> [https://news.ycombinator.com/item?id=5322286](https://news.ycombinator.com/item?id=5322286)

Also, the bug that was filed was also referenced: _Dexopt fails with
"LinearAlloc exceeded" for deep interface hierarchies_
[https://code.google.com/p/android/issues/detail?id=22586](https://code.google.com/p/android/issues/detail?id=22586)

~~~
krschultz
I don't think we've mellowed, just that we have become more sympathetic to
Facebook's problem. I think the reality is that the 65k method limit problem
has turned into something Android Developers put squarely at Google's feet. At
the time I thought, what the hell is Facebook doing? Now, I've run into the
65k limit myself on an app written by 4 people over 18 months. Sure it's not a
throwaway weekend project, but that is a pretty standard app.

Google either needs to blow away the 65k method limit, or figure out a way to
make Google Play Services a lot lighter. As it stands right now, if you want
just push notifications you are giving up ~20k methods of your 65k limit for
that alone.

Just look at this post from Jake Wharton (leading Android open source
developer): [http://jakewharton.com/play-services-is-a-
monolith/](http://jakewharton.com/play-services-is-a-monolith/)

~~~
emil10001
Slimming down Play Services just punts on the problem for a while. My view is
that Google needs to do two things with this:

1) Split up the Play Services client libraries. 2) Figure out some solution
for developers hitting the 65K limit.

I'm sort of assuming that the solution would come in the form of a framework
or tooling that we'd have to implement. Such a solution should allow us to
build fully working apps with multiple dex files, with some decent
documentation. It should also work fine for debug builds without proguard, and
also without bumping build times up beyond a two minutes. What's more, we
should be able to split off pieces that are defined in the manifest into
secondary dex files, and fire intents at them.

That, to me, seems like a reasonable response to this problem by Google. The
company I work for has been hitting the limit for the last few months, and
some of our other dependencies are becoming more and more expensive with newer
releases (things that our users actually like.) So far, we've been able to
build with a stripped down Play Services jar, but I'm not terribly happy about
that approach.

Regardless, I'm not going to blame Facebook for a problem that Google caused.
If Facebook can find a solution, and tell the community how they did it, I'm
all ears.

------
robmccoll
On the 65K methods restriction, how many lines of code per method do these
projects have on average? That just seems like a lot of code. Is this a result
of the Java acessor-and-mutator-methods-for-everything approach?

For reference, Tomcat and Maven are both 1M lines of code (would be ~15 lines
of code per method @ 65K methods). Lucene is <500K.

~~~
jug6ernaut
I used to think this was a non issue. 65k methods is a lot right? Well I ran
into the 65k method limit with my one developer game I'm working on. Can't
remember if it while i was using gradle or maven(recent switched) but it would
print out all the methods for each package. Method counts add up quick when
you are importing libraries. For example google guice by it self(if memory
servers me) had ~6k methods. Thats one library. Starting adding different
Apache libraries and its possible. Granted the majority of these get stripped
out by Proguard, but having to run proguard for every build is a major pain. I
have since refactored and am now well under the limit, but this issue is a lot
more prevalent then i thought.

------
__Joker
I understand, Dalvik uses 2 bytes to select a method found in the list at the
start of the dex file and then to execute it. Is there any particular reason
it is limited to 2 bytes ?

~~~
ntlve
This is just me guessing but one of the initial goals of Dalvik was to use as
little space as possible (due to memory constraints of hardware at that time).
Perhaps they thought saving a a byte or two on method identifiers was a good
idea. This would not be a problem if it weren't for the fact that dx also
squashes all classes into one single class, meaning that instead of being 65K
methods per class you now get 65K per apk.

~~~
judk
Ah, mobile. Recapitulating all the horribly constrained hacks of the early PC
era, in handheld size containers.

------
praseodym
Note that the Facebook blog post about this hack is from 4 March 2013, i.e.
more than a year ago.

~~~
redDragon
Yes and still FB relies on this patch to run its app, and sometimes it does
fail as happened on my device.

------
lambada
I don't see how facebook cheated Dalvik 'again'? Seems like it's still just
the one 'patch'/'hack'. Am I missing something?

~~~
skrebbel
What they do "again" is pull some nice engineering feat that's also a bit of a
hack, and therefore fun to read about. I assume the author is impressed, and
likens it to some of Facebook's similar bend-the-world-to-my-turd undertakings
such as patching git to be able to deal with Facebook's single gigantic (!)
source code repository.

~~~
lambada
Oh, I see. I assumed the 'it' in the post title referred to the 'Cheating
Dalvik' that followed. Not that it referred to a more generic concept of bad-
practise.

------
yincrash
This article seems to conflate the limit on number of methods vs the amount of
memory required for one of the dexopt steps.

------
bhouston
I understand blackberry messenger also has the 65k method hack in its android
app.

------
spo81rty
I wonder if this 65k limit is part of the reason they made messenger its own
app?

~~~
jug6ernaut
I'm sure it was a consideration. Also from a team/project structure standpoint
it probably a lot easier.

------
d0vs
Mirror?

------
rurban
Maybe it would have helped missing out in the mandatory spying features, and
providing only the required customer features.

Those features really take a lot of memory:

* “Record audio with the microphone … at any time without your confirmation”

* Take videos and photos using the camera

* Access the phone’s call log

* Read data about contacts stored on the phone, “including the frequency with which you’ve called, emailed or communicated in other ways with specific individuals”

~~~
kalleboo
> * “Record audio with the microphone … at any time without your confirmation”

There's no way in Android to record audio with the microphone at only certain
times with your confirmation. Facebook needs microphone access for video and
voice calling.

> * Take videos and photos using the camera

The Facebook app lets you take photos and videos to post on your feed. How
else would they be able to do that without camera access?

I can't speak for the other two (I use iOS myself) but Androids permissions
are generally way too broad (stuff like to be able to pause music when the
user is making a call you have to ask for access to their phone number and the
phone numbers of everyone calling them) and users have to accept the kitchen
sink. The "Facebook spying" stuff is an Android bug, not Facebook.

~~~
danielweber
_The Facebook app lets you take photos and videos to post on your feed. How
else would they be able to do that without camera access?_

Isn't the point of the Android app model of breaking everything up into
Activities that you can call another Activity which does the video/photo
recording, and then you just deal with the result?

(That's not a rhetorical question; I may be misunderstanding the intent of the
design, or how people use the design in reality, or both.)

~~~
aguyhere123
Yes, you're right that activities are broken up like that. Permissions are
defined in the application manifest, and apply to all activities within the
application.

Facebook would have to break their application into a calling app and newsfeed
app to split the permissions apart. It would still request permission to
record and take videos for both, though, if they implemented video recording
on the newsfeed app.

