Google plans to ship a Pixel Tablet in 2023. First announced earlier this year, the upcoming tablet is expected to ship with Android 13 and a number of tablet-optimized apps from Google.

One thing Google didn’t tell us though? It looks like the Google Pixel Tablet could be the first Android device to ship with 64-bit only software, meaning that it won’t be able to run 32-bit apps at all.

Android source code spotted by Mishaal Rahman indicates that Google is testing a 64-bit only build of Android 13 on a device code-named “Tangor,” which is believed to be the Pixel Tablet.

Google’s been paving the way for 64-bit only builds of Android for years. The company started supporting 64-bit only configurations with Android 12, but devices shipped with that setup. And Google has been requiring developers who submit apps to the Google Play Store to include 64-bit builds since mid-2019.

In other words, some classic games and other very old Android apps that haven’t been actively maintained by developers might not be able to run on the Pixel Tablet or other hardware running a 64-bit only build of Android. But most recent or regularly-maintained apps and games in the Play Store should run without problems.

Ending support for 32-bit apps would reduce the code base required for the Pixel Tablet operating system and could cut down on memory usage.

32-bit Android apps probably aren’t going away altogether anytime soon. Rahman notes that there’s evidence that Google could be planning to require device makers to ship 64-bit only builds of Android if they want to use Google Mobile Services starting with devices that ship with Android 14. But it’s unclear whether the company will actually take that step in the next year or so.

Meanwhile, there are still an awful lot of Android phones and tablets in the wild that have processors featuring 32-bit CPU cores. And it’s unlikely Google will end support for 32-bit apps until that number dwindles in the coming years.

Support Liliputing

Liliputing's primary sources of revenue are advertising and affiliate links (if you click the "Shop" button at the top of the page and buy something on Amazon, for example, we'll get a small commission).

But there are several ways you can support the site directly even if you're using an ad blocker* and hate online shopping.

Contribute to our Patreon campaign


Contribute via PayPal

* If you are using an ad blocker like uBlock Origin and seeing a pop-up message at the bottom of the screen, we have a guide that may help you disable it.

Subscribe to Liliputing via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 9,533 other subscribers

10 replies on “Google Pixel Tablet may be the first 64-bit only Android device (32-bit apps won’t be supported)”

  1. I don’t see this as bad news.
    If anything it’s long overdue, and ARM should have removed 32-bit support completely from ARMv9.

    That should have been step one. And step two should have been a rewrite of AndroidOS from the bottom to make it less bloated, more efficient and faster performing. Many other systems like QNX, Linux Distro, macOS and iOS are leaner.

    The Cortex-A710/A715 still support it, and there’s almost no need for it worldwide besides the Domestic Chinese Market (heaps of Apps still on old API and 32bit).

  2. I doubt the effects of this will include just “32 bit apps”. It could very easily include any 64 bit app that uses a 32 bit library or is intended to emulate a 32 bit system.

  3. “Ending support for 32-bit apps would reduce the code base required for the Pixel Tablet operating system and could cut down on memory usage.” — significantly? Can’t 32-bit support be loaded as necessary — in Android?!? Operating systems should facilitate access to computers’ resources, full stop. Limiting OS’ capabilities, masking access to resources, and advertising are antithetical to their purpose. If government represented our interests, we long since could have ended all the abuse simply by smoothing the path for superior OSs (such as Linux) into the market.

    1. Linux is long gone… unfortunately. It follows the trend aka “globalization” path. Look at ubuntu and other popular and easy access linux. You say how about other distros?! Believe me they will die out cause they are aint going to have mass use. And already we can see through new kernels of linux how many features are missing…

      1. This is not correct. Google may eventually move their consumer products to their Fuchsia OS/Zircon kernel, but Linux/POSIX compat will have to remain for years to come. This may be only running Linux in KVM virtual machines hosted on Fuchsia for consumer devices, but native development on Fuchsia is simply not mature enough to remove Linux from the loop.

        Additionally, Linux is by far the dominant OS on servers, and generally even backend/frontend/fullstack developers on Windows or macOS will deploy to Linux. It’s not going anywhere.

        1. My point was not about Linux is dying out but only that Linux follows windows and macos in restricting and droping off support for old staff. At least major most popular Linux distribiutors

    2. “Ending support for 32-bit apps would reduce the code base required for the Pixel Tablet operating system and could cut down on memory usage.” — significantly?

      No. This is more likely due to some newer hardware revs of ARMv8/ARMv9 dropping support for ARMv7 32-bit compatibility, and Google’s preparing for that eventuality. 32-bit code generally and 32-bit pointers specifically are more compact than 64-bit code by definition, but for all but extremely memory-starved machines, “wider” generally means faster, so it’s not worth it to limit yourself to 32-bit.

      This has absolutely nothing to do with the government. For all intents and purposes, Android is Linux, albeit one with an odd init system, C standard library, userspace, shell, application runtime and GUI. Without 32-bit hardware support, there’s nothing the 64-bit kernel can do other than call either an in-kernel instruction set emulator (yuck) or use a userspace bridge (Qemu or similar) to Linux’s binfmt interface to run what is essentially non-native code by translating system calls on the fly.

Comments are closed.