Live data from Hacker News

Facebook Does It Again. Cheating Dalvik

blog.mohitkanwal.com

31–40 of 66 posts

Re: Facebook Does It Again. Cheating Dalvik

#31
post #29

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, emai…

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

Re: Facebook Does It Again. Cheating Dalvik

#32
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.

Re: Facebook Does It Again. Cheating Dalvik

#33

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.

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.

Re: Facebook Does It Again. Cheating Dalvik

#35
post #5

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 h…

2^16 counts as "weird and arbitrary"?

Re: Facebook Does It Again. Cheating Dalvik

#36
post #5

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 h…

2^16 counts as "weird and arbitrary"?

Since we stopped using 16-bit CPUs, yes, it does.

Re: Facebook Does It Again. Cheating Dalvik

#38
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.

Re: Facebook Does It Again. Cheating Dalvik

#39

Earlier quoted context omitted.

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…

> by then the market share of Gingerbread should be under 15-20 percent, too According to the Android dashboard [1], among users of Google Play Gingerbread has a market share of 13.5% [1] https://developer.android.com/about/dashboards/index.html

I'd like to see what percentage of app sales come from Gingerbread. My guess is that people that are willing to buy apps are not* using a 3 year old phone. (*edited)

Re: Facebook Does It Again. Cheating Dalvik

#40

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 architect…

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