Add your SDK
Home / Multidex
Enjoy the best mobile SDKs news, tips & tricks, sent to you by mail

Two Years of Multidexing: Is the 65K Limit Still a Big Deal?

October 20, 2016 8:42 AM

I still remember when I saw my first multidex app. It was almost two years ago and ho so rare. It was an almost religious experience – seeing something you didn’t think could exist with your very own eyes. And yet today I’m surprised when I stumble upon an app and it only has one dex file. Seriously, it’s like finding an oasis in the Sahara. A sight for sore eyes.

Which is why I was so surprised when our saleswoman told me about a meeting she had, where the developers in question specifically asked about it. They were determined to stay single dex no matter what.

You see, silly me, I thought the 65k limit was like one of those things you read about in history books or see in old movies. But it turns out I was living in a bubble. But hey, can you really blame me? Even Android’s own new compiler – Jack – refers to it in both code and documentation as “legacy”.

Which leads me to really think – is the 65K limit in Android still a big deal?

Continue Reading

The 3 Surprises Hidden in Your App’s Start Time

April 13, 2016 2:59 PM

What more is there to say about the mobile app start time? I’ve already written about it in the past, describing our research about what makes up the time from the moment you click on an app’s icon until you get a visual feedback.

But when Samsung’s Innovation Center in Tel-Aviv offered us the chance to record a podcast, we knew it had to be about the start time. After all, listening is better than reading, right? So Ronnie Sternberg, Maya Mograbi and myself headed over to Samsung offices to embark on a conversation about the mobile app start time. And what can I tell you? It was fun!

Some interesting points were made, not all of which were covered in my original post…

SafeDK is broadcasting from TLV Samsung’s innovation center , suppprting Israeli High Tech professionals, communities, entrepreneurs and startups.

Continue Reading

Android Developer? Here is what to pay attention to when using Google Play Services

September 21, 2015 8:09 PM

Most Android developers use Google Play Services. In a survey we run at SafeDK, we found that nearly 70% of all Android apps have at least one package of Google Play implemented, and often even more than that. From ads to analytics, through support of social media, cloud and push notifications, Google Play Services offer app developers a variety of capabilities, and it’s great. Having said that…there is also a downside to all this goodness.

In order to offer such rich support, Google Play Services module is comprised of many individual packages, and contains a whopping 29,000 method count which is problematic due to the 65K limit issue.

The Unbearable Lightness of Multidexing

Interestingly enough, based on SafeDK’s big data, we found that approximately half of the Android apps out there integrate the full module of Google Play Services, but actually use very few of the packages it contains. Naturally, Android developers would want to optimize their Google Play Services selection…

I’ve written about how to deal with this issue, in a previous post where I provided some insights on how to identify the packages that are right for you. I also touched on the number of methods each package adds to your app. 

But now, Google has released a new version of Google Play Services. And while some things have changed, the bottom line has barely shifted:

  • It still adds a large number of methods to your app.
  • You still must use the large “base” package in order to use any package.
  • You still have to use the entire play services (can’t pick-and-choose) to continue using the deprecated appstate package.

Continue Reading

Solving Android’s 65K Limit (Part 2): The Lollipop Generation

June 23, 2015 3:57 PM
 

If you’ve read my previous post about breaking Android’s 65K limit (and if you hadn’t, what are you waiting for?), you’re already pretty familiar with Android’s 65K limit, why it exists and how to solve it. Which means you’ve been itching to know what the future of multidexing has in store (and what does a tooth-fairy-supporting candy-on-a-stick has to do with it).

As small recap to start with, if you will:

Since its’ inception, Android ran a virtual machine called Dalvik. The Dalvik VM ran a compiled file called dex (Dalvik Executable) which has a tiny limitation – even though the file contains the entire code for the application, its id field was limited to 4 hexadecimal digits. So when an application had over 0xffff methods (=65,536 in decimal), the dex file simply could not be created, meaning applications with so many methods could not be created.

That posed a problem as applications became more and more diverse and complex, and as many developers looked to speed their development process by not doing everything from scratch, but by using more and more third-party libraries (SDKs) that help them achieve their goals faster.

Android released a support library which helps you create an application with over 65K methods. In a nutshell, the compilation process to of Java bytecode to dex was enhanced so that once the limit is reached, a secondary dex file is created. The support library then offered a static method Multidex.install which is called when the app is being launched and tells the class loader to look for methods in places other than the one dex file is expects.

However, we’ve seen the solution is not ideal. Issues ranging from prolonged compilation time to a static process repeating every single time the app is launched made the multidex solution a workaround compromise rather than something Android developers could truly trust. What might be the most burning issue is the lack of ability to predex (compile the not-likely-to-change parts of your app to dex only once; Again, for more information, take a look at part 1).

Continue Reading

Solving Android’s 65K Limit: The Unbearable Lightness of Multidexing

June 16, 2015 7:39 PM
 

If you’ve been developing for Android for some time now, you might have encountered a little thing called “The 65K limit”. You must have at least heard about it around the water cooler. There were times were Android developers dreaded it.

You see, the Android system put an almost arbitrary limit on the number of methods an Android application can have. A limit which may have sounded reasonable in the past but is near far-fetched in today’s terms. The limit itself, which stands roughly around 65,000 methods, may sound a bit excessive. “What are the odds I’ll ever reach that?” a novice Android developer may be thinking. However, applications are using more and more third-party libraries (otherwise known as SDKs – Software Development Kits). Just imagine writing your app and wanting a library to help you parse JSON objects, wanting to connect to a social network such as Facebook, or looking to make a profit for your effort by displaying ads in your app. All of these libraries add more methods to your app, and slowly that high limit doesn’t seem so unreachable.

Adding insult to injury, Google themselves contributed massively to the problem, with their Play Services SDK containing a whopping 29,000 methods! That number is almost inconceivable – that is nearly half of the limit (In an upcoming post, I will describe how you can reduce the number of methods you get from this SDK. Stay Tuned).

Today, however, things are different and solving the limit issue is quite simple. So simple, actually, that many apps found refuge in it. Today there are apps in the Play Store with well over 80K methods!

Continue Reading