Facebook Does It Again. Cheating Dalvik

The bug they hit isn't the 65k limit, but the smaller LinearAlloc buffer size on older versions of the OS.

2^16 counts as "weird and arbitrary"?

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.

This limitation is not "weird or arbitrary" but based on the technical capabilities of Android phones in these days.

And those limits were later changed and will surely be changed in the future as smartphones get more powerful.

All kinds of limitations are in place both on Android and iOS, particularly when it's about the amount of memory an application can access or the amount of background processing an app can make.

If you don't have these limitations, then apps could affect not only the functioning of other apps, by grabbing and keeping all available memory, but also that of the phone itself, by draining the battery in 1 hour.

That's not something that the average smartphone user would expect or desire his phone to do.

Edit: I'd also like to add, that almost anything a developer creates is usually created with some limit, or at least some expectancy of costs in mind.

For example I couldn't imagine that someone creates a memory cache, where the limit = infinite without a really good reason. Or an API where the request limit/sec for any client = infinite.

You usually develop something in a way, that reduces the cost of some computation as far as possible, and when it still causes problem - introduce hard limits. Especially when it's a whole ecosystem where many companies/developers participate.

If it's too much of a hassle to make your app work on Gingerbread, just don't bother with it anymore. I bet Google themselves will end all support for Gingerbread next year when version M comes out (as they should). It just doesn't make sense to support it longer than that, and by then the market share of Gingerbread should be under 15-20 percent, too. Gingerbread is the XP of Android - an old popular version, right before major architectural changes.

Android L seems to be the next major architectural change, but I don't think KitKat will be the new Gingerbread, because Google is now requiring OEMs to only launch devices that are 2 versions and/or 9 months old, which will soon mean (going by the new release cycle) just 1 version behind. So the transition for new versions should happen a lot smoother in the future.

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!

There is a way: https://github.com/creativepsyco/secondary-dex-gradle

The new gradle build system really simplifies a lot of things in terms of the build cycle

I'm in the end stages of developing my first Android app. Throughout development I used the Android compatibility libraries to get it working on Gingerbread. However, now that I'm almost finished, I realize that many Gingerbread devices have a hard limit on the number of simultaneous active MediaPlayer objects that means my app will not (and cannot) function properly. (All devices tested on ICS++ seem to work fine). It works on some Gingerbread devices (and, annoyingly, all emulated Gingerbread devices I've tried) but not all. So now I'm in the awkward position of either changing the minimum API level of my app to exclude all Gingerbread devices (even though it works on some) or annoying some Gingerbread users by getting them to download my (large) apk only to give them a "sorry, your device is not supported" message when they first open it.

I know nothing about iOS development, but I'm envious of the narrow range of hardware and software in that ecosystem.

Consider switching to Xamarin + MonoGame. You will have to pay, but features might be worth it (better yet familiar language more mainstream in gamedev, decent cross-platform support). Alternatively try using Unity3d if you don't mind scripting instead of programming.

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.

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

Sounds like his gambling problem is the issue.

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/

I think it's quite common for developers to expect restrictions on APIs to ease as the API matures. I've also heard, anecdotally, about more developers hitting this method limit since facebook first talked about it.

Personally, I think it's silly that Android apps work one way up to 65k methods, and then require you to re-think how your app is architected due to packing limits. I think Google is just as guilty as Facebook of selfish engineering choices.

Its almost as if requirements went up over time. Google Play Services has also made the problem worse over that time.

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.

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.

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

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.

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

They made Messenger its own app and made the separate app required for messaging on iOS first, and later on Android. So it really doesn't make sense if any significant part of the motivation was working around an Android platform issue.

> * “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.