Live data from Hacker News

Dalvik patch for Facebook for Android

facebook.com

61–70 of 95 posts

Re: Dalvik patch for Facebook for Android

#61

Earlier quoted context omitted.

For the longest time, I was convinced it was an abomination that Linux did not succeed on the desktop. Now, I am not so sure.

One of the advantages of open source is that things like that don't tend to happen. If a change to X breaks Y, the X maintainers don't include a horrible hack to avoid breaking it, they just submit a patch to Y. Then the package manager makes sure nobody installs new X without installing patched Y.

This may be true for X, but concerning the kernel, Linus Torvalds states very clearly that whatever change breaks existing client code is a kernel bug.

Re: Dalvik patch for Facebook for Android

#62
post #3

It's interesting to see the parallels between Android and Windows in this regard. Here's a story from my past, copied from a blog post I wrote last year: My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers’ (such a…

As soon as you mentioned "Adobe Type Manager" I remembered reading about this case some time ago. But knowing it was you that discovered this makes it all the better. If only we could create perfect APIs the first time around...

I've created more than a few and IMO there's a reasonable approximation of perfect, namely an API which is possible to explain completely in reasonable prose.

If the documentation has to go off and spend much verbiage on side cases, something's wrong. There's an imbalance in the API that's reflected in the documentation.

If the first few sentences of the documentation read like committeework, or sound like the explanation of the explanation, then something's wrong. The API is not going to be compatible with its users.

If the documentation talks more about specific use-cases instead of classes of behaviour, then something's wrong.

IF the documentation tells you to do this, then that, then that, then something's wrong. It should talk about useful, describable atoms, not things that make sense only as a sequence.

There are a few more.

All this doesn't help to improve an API before release, at least not directly. But reading the documentation makes it easy to detect API brokenness while it can still be unfucked.

Re: Dalvik patch for Facebook for Android

#63
Unfortunately TechCrunch reported incorrectly and no one at Facebook cared enough to correct them (OR thought its cool to boost 3M Methods in an app).

The limitation in older Dalvik VM's is 64K Methods and not 1 Million methods which is realistic count that a large app would hit (even decent sized app with high number of third party libraries).

This limitation is known for a while and Google Engineers talked about it multiple times.

Re: Dalvik patch for Facebook for Android

#64
post #28
post #22

This seems like it will paint the Android core developers into a corner, supporting this particular hack for years to come, like the way Microsoft had to for Windows. If I were android core developers, this would not be a good day.

This hack is specific to ancient versions of Android, and is not used on current or future versions. So there is no need to deal with it in any codebase that isn't completely dead.

> "specific to ancient versions of Android"

Ancient but still shipping. I can go into a store and pick up a Samsung Galaxy Ace running 2.3 today. A significant minority of 2.3 based phones are still being sold, especially for budget/Pay As You Go users.

This hack will need to remain in the codebase for a significant time.

Re: Dalvik patch for Facebook for Android

#65
post #3

It's interesting to see the parallels between Android and Windows in this regard. Here's a story from my past, copied from a blog post I wrote last year: My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers’ (such a…

Parallels?

> I had the WordPerfect engineer on the phone. He had given me access to the WordPerfect source code, but I couldn’t give him access to the Windows code. So we were each stepping through WordPerfect in the debugger, him in Utah and me in Bellevue. I could see what his code was doing and what Windows was doing, but he could only see disassembly for Windows.

FTA: Instead, we needed to inject our secondary dex files directly into the system class loader. This isn't normally possible, but we examined the Android source code and used Java reflection to directly modify some of its internal structures. We were certainly glad and grateful that Android is open source —otherwise, this change wouldn’t have been possible.

Facebook are not saying that Android/Dalvik has a broken API. They are saying that that due to the size of their app they hit an interna limit, this buffer limit increased between platform versions and they needed to create a robust hack to get their code working on older platforms, They were able to do this by taking advantage of the open-source nature of the platform and they did not need a Google engineer on hand to help them though they did get to use a Google test lab (which is not fair on smaller companies). Also Google have not inserted code into Android/Dalvik to deal with the Facebook trickery.

Re: Dalvik patch for Facebook for Android

#66

Earlier quoted context omitted.

One of the advantages of open source is that things like that don't tend to happen. If a change to X breaks Y, the X maintainers don't include a horrible hack to avoid breaking it, they just submit a patch to Y. Then the package manager makes sure nobody installs new X without installing patched Y.

This may be true for X, but concerning the kernel, Linus Torvalds states very clearly that whatever change breaks existing client code is a kernel bug.

That is true, but it is also true that it is very unlikely for a hack to make a single application run will be added to the Kernel in the first place.

Re: Dalvik patch for Facebook for Android

#67
post #36

Earlier quoted context omitted.

I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.

Still seems like a ridiculous number, though of course far less ridiculous especially for Java code with its legacy of setters and getters for even basic properties and FactoryOfFactoriesFactory classes.

Trivial getters and setters shouldn't be a problem because the Facebook blog said they tried using ProGuard, which can inline Java methods.

Re: Dalvik patch for Facebook for Android

#68

Earlier quoted context omitted.

This may be true for X, but concerning the kernel, Linus Torvalds states very clearly that whatever change breaks existing client code is a kernel bug.

That is true, but it is also true that it is very unlikely for a hack to make a single application run will be added to the Kernel in the first place.

Dunno - I think there was a fairly lovely hack a while back to deal with the fact that the autofs ABI for 32-bit applications on 64-bit kernels wasn't compatible with the ABI for 32-bit applications on 32-bit kernels, and this was breaking stuff. Someone inserted a hack to fix this, which then broke another application which had its own hack to work around the kernel bug.

So Linus had to add a hack to unbreak this other application's hack to work around a kernel bug that no longer existed: http://lwn.net/Articles/494993/

Re: Dalvik patch for Facebook for Android

#69
post #3

It's interesting to see the parallels between Android and Windows in this regard. Here's a story from my past, copied from a blog post I wrote last year: My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers’ (such a…

Funny, mirror-image story. In the early 1990s I was writing utility software for Macintosh, then on the 68K platform. The utility basically had to patch the OS as it was running, a common practice back then. To figure out where to place the patches, I spent lots of time looking at disassembled 68K code in MacsBug, stepping through the OS as it ran. One day, I was tracing through the OS code that handled a context swi…

I don't have any similar story to share ([un]fortunately?), but I have to say that parent and grandparent comments are what make HN that interesting and it's the reason why comments are often more valuable than the articles/stories they comment (and why I sometimes read comments without even checking the OP link at all). Thank you for sharing your tidbits, cek and tmoertel!

Re: Dalvik patch for Facebook for Android

#70
No, that is not cool, that is an admission that

1. They bloated the app so badly, they would have had to monkey patch the OS to let it run at all.

2. They actually did have the stonkingly huge arrogance to monkey patch the OS.

What they should have done is shattered it down into a constellation of related apps and background processes. This app is FB news, that app is FB messaging, and so on. Bonus: people could pick and choose the parts of the system they cared for.

But that last is what they wanted to avoid, I think. Facebook à la carte means that they can't foist unwanted "services" on you.

And so they hacked.

Post reply on HN