Pocket Edition v0.7.0

This is a sub-page of Proto:Minecraft (Bedrock).

'This page or section details content from theFebruary 2026 Minecraft Leak.'''

This needs some investigation. Discuss ideas and findings on the talk page. Specifically: Hoo boy. Figure out how to get the Android and Raspberry Pi projects to build. Currently, the only platform that works is the Windows project. Investigate further into bits of commented out code and figure out what they do.

On February 28, 2026, the source code for development versions of the Legacy Console Edition, Pi Edition, and Pocket Edition were leaked onto 4chan. Amongst the leaks is the work-in-progress source code for alpha 0.7.0 dated February 8, 2013, which can be compiled to produce a development build. It features a work-in-progress revamp of the settings screen and some debugging features not present in officially released builds. Being a very early build, it's very similar to alpha 0.6.1 and still labels itself as such. This leak contains code written after the release of Pi Edition v0.1.1 (which was itself released after Pocket Edition v0.6.1). However, some Pi Edition-specific code was never merged back into Mojang's repository and is therefore not included in this leak.

Differences#

New Options Menu#

This build introduces an early version of the new options menu which replaces the original menu that used native Android/iOS pop-ups. However, the menu in its current state is very bare-bones as it lacks practically every option except an option with an unlocalized name for sensitivity. Given the state of the menu and the fact that the commented out code tries to call methods with arguments that aren't actually valid, it stands to reason that the options and the menu were being refactored at the time of development. Re-adding the options that are still present reveals that most options don't have localized strings. An earlier version of this menu is present in Pi Edition v0.1.1. In that version, the commented-out code was enabled. Notably, the game fails to read the options.txt file because it is opened in write-only mode.

Developer Johan Bernhardsson previously posted a mock-up of the new menu layout on February 4, 2013 on Twitter. The code for recreating the mock-up is present in the code, but it's completely commented out and the methods they call are also commented out.

Johan Bernhardsson Mock-up	Development Build	Alpha 0.7.0

Smooth Lighting#

This build introduces an early implementation of Smooth Lighting, which can be toggled on the fly in Windows builds by pressing the O key. The code was technically included since the very first version of Pocket Edition, but was not toggle-able until v0.7.0.

Oddities#

• Melon seeds do not have a localized name.

Disabled Content#

The source code is rich with content that had been manually disabled at the time of development by commenting them out entirely.

Based on scripts like JConvert.py, it can be speculated that a lot of this code was generated by directly transforming the corresponding code from Java Edition. As such, it is probable that rather than being actively disabled, a lot of this commented-out code was just never implemented in the first place. This would explain why many mentioned classes like `BucketItem` show no signs of ever existing.

Items#

Present within Item.cpp and Item.h are commented out definitions for various items in the game which are either pointless to craft or haven't yet been implemented.

Blocks#

Tile.cpp contains a reference to Soul Sand on line 236. While it references a class that doesn't exist, defining it as a variable and setting it as a generic block reveals that it does at least have a texture.

World Generation Features#

This needs some investigation. Discuss ideas and findings on the talk page. Specifically: Investigate other world generation features and figure out what they did.

The source code contains commented out world generation features in various parts of RandomLavaSource.cpp. They can be restored by uncommenting them and making necessary fixes where necessary. Many of these would later make it into newer versions of the game.

• Lava lakes and underground water pools are implemented in LakeFeature.h, but the code for generating them is commented out in the postProcess method.
• Underground caves are implemented in LargeCaveFeature.h, but the code for generating them is commented out in the PerformanceTestChunkSource::create and RandomLevelSource::getChunk methods. They wouldn't make it into a released version of the game until alpha 0.9.0, and even then they required a world with the Infinite world type to generate.
• Random tall grass placement is implemented in TallgrassFeature.h, but the code for generating them is commented out in the postProcess method.
• In CanyonFeature.h and CanyonFeature.cpp there's commented out unfinished code for the generation of early ravines. Fixing some of the code and adding CanyonFeature into RandomLevelSource::getChunk reveals a fully functional ravine feature, noticeably the same one found unused in the Java Edition Beta 1.2 Dev Build. Ravines would be added into Pocket Edition 4 years later in the Better Together Update, making this a noticeably early implementation.

Miscellaneous or Broken Features#

• MobSpawner.cpp contains commented out code in MobSpawner::finalizeMobSettings for spawning Spider Jockeys, seemingly directly ported from Java Edition. Even if restored to use the correct syntax, the game lacks logic to check for riding making this check useless.
• RandomLevelSource.cpp contains several blocks of commented out code. The first one is a block of code responsible for spawning MonsterRoomFeature presumably dungeons, but there are no files relating to MonsterRoomFeature leftover in the source code.
• RandomLevelSource.cpp also contains code to spawn pumpkins randomly using PumpkinFeature but just like MonsterRoomFeature, files for this feature are not present in the source code alongside pumpkins being disabled in the game's code, not seeing light until Alpha 0.8.0.
• Recipes.cpp contains a huge amount of commented out recipes that call for items that did not exist in the game yet or had no function or were disabled.

Pi Edition#

The leaked code was ostensibly written after Pi Edition's release. However, that does not mean that the leak fully contains Pi Edition's source code. Many changes were seemingly never merged into the main Mojang repository. Notably, this makes building Pi Edition from the unmodified source code impossible.

This is a list of the differences from Pi Edition to the leaked source code:

• Two classes are included in Pi Edition but not the leak:
  • MouseUnlockedScreen is a bare-bones screen that include a button that says Close in the top-right corner and nothing else. It is never used. Notably, while it is not included in the leak, it is referenced in the Pi Edition Makefile.
  • An unknown class which interacts with the Raspberry Pi's GPU's "mailbox" communication interface. It includes methods for retrieving the firmware versions, and getting/setting the over-scan. This class is never mentioned in the leak. And because it does not have a VTable, its true name is unknown. Similar code can be found here.
• Options changes:
  • Pi Edition does not include some of the newer options GUI changes from the leak.
  • Notably, it does not use the localization API and the commented-out code in the leak is fully active.
• Other changes:
  • In the official build, Pi Edition's API contains the world.getBlockWithData command. The leak's implementation of CommandServer does not.
  • When KeyboardInput::releaseAllKeys is called, the official binary sets the jumping property to false. This (presumably) bug-fix is not included in the leaked code.
• The build system is totally broken:
  • Pi Edition consists of two Makefile: one for RakNet and one for the game itself.
  • By default, the RakNet one produces libRakNet.so with the option of also producing libRaknet.a (and remember, Linux is case-sensitive).
  • However, the game's Makefile expects a file named libRakNet_static_O1.a. This file also searches for the library in an incorrect directory.
  • RakNet's Makefile uses wildcard to retrieve the list of source files. Notably on older versions of Make, this produces a non-deterministic order. This makes the RakNet build non-deterministic, which in turn makes the game's build non-deterministic.
  • The game's Makefile also searches for the Raspberry Pi's libraries in hard-coded locations, which may have changed since 2013.

Platform Specific Differences#

The source code contains a bunch of differences which alter the game's behavior depending on the platform it was built for.

Touchscreen Mode#

The game has two different versions of some screens for both touchscreens and non-touchscreen devices. The game chooses which version to use depending on the environment the game was compiled and run on. This is accomplished by a combination of compiler flags, a function in the platform abstraction layer, and even in-game options. In Minecraft.cpp, the method useTouchscreen determines whether to use touchscreen controls by checking both the option useTouchScreen and whether the platform supports touchscreens in the first place by calling the supportsTouchscreen method in its abstraction layer during startup. If either of those are the case, the game enables touchscreen mode¹.

This behavior is slightly platform-specific and done in a rather weird fashion.

• If compiled for the Raspberry Pi, Minecraft.cpp's useTouchscreen method is hardcoded to always return false, disabling touchscreen mode and any baggage it carries entirely.
• If compiled for Windows, touchscreen is always enabled by default by overriding the default implementation of supportsTouchscreen to return true. This is strange, because the default implementation does the exact same thing.
• If compiled for Android, the game calls a native method within the operating system to determine whether the device itself supports it. Most standard Android devices will return true, but some devices like the Xperia Play will return false since they have their own built-in gamepad.
• Otherwise, the game assumes that touchscreen controls are supported and returns true.

Aside from the additional versions of existing screens, the game also displays an extra hotbar slot in the in-game HUD when touchscreen mode is disabled.

Title Screen#

The title screen has several minor differences.

• If compiled for the Raspberry Pi, the game tweaks the title screen to hardcode the version string to v0.1.1 alpha, replace its branding with Pi Edition branding, removes the options button, moves the Join Game button down by a few pixels, and adds the Raknet logo in the bottom left corner.
• If compiled for versions of Android prior to 2.3, the game appends j to the end of the version string.
• If compiled for iOS while the flag for demo mode is set, the game appends (Lite) to the end of the version string. Otherwise, it appends (Demo) instead.

Non-Pi Builds with Touchscreen Mode Disabled	Pi Builds

World Selection Screen#

The Create World button in the world selection screen behaves differently depending on the platform.

• If compiled for the Raspberry Pi, the game automatically creates a Creative Mode world with certain settings depending on if touchscreen-mode is enabled. When it is disabled (the default) it will create a world called world with the seed set to the current Unix time. However, when the touchscreen mode is disabled, it will create a world named perf with the same seed logic (commented-out code exists for setting the seed to /r/Minecraft).
• If compiled for Windows, the game prompts the user to choose a gamemode using the gamemode selection screen from the demo. Once chosen, the game creates a world with the chosen gamemode named perf.
• Otherwise, the game defaults to showing the regular world creation menu.

Debugging Windows#

This needs some investigation. Discuss ideas and findings on the talk page.

If compiled for Windows, upon running the executable the game opens up two additional windows alongside the main game window.

Debug Keybinds#

If compiled for Windows, the game offers a bunch of extra keybinds for use in debugging.

If the game was compiled with the OPENGL_ES flag disabled, pressing the P key would toggle a wireframe rendering mode. This restriction is due to OpenGL ES v1.1 not supporting wireframe rendering. This is platform-agnostic.

Inventory#

If the game was compiled for Windows, any worlds created in Survival Mode will automatically give players 98 iron ingots, 1 stonecutter bench, 1 crafting table, 1 furnace, 54 wooden planks, 14 sticks, 31 coal, 6 sand, and 23 purple dye.

Anti-Piracy#

Every time the game ticks at the title screen, it performs an anti-piracy check by calling a function in the platform abstraction layer called checkLicense and checking if the result is either 0 or 1. If it is, then it enables the buttons in the title screen and moves on. If it isn't, it throws up a licensing related error and prompts the user to purchase the game.

While this code is universal across all platforms (including the Pi edition), it turns out that the checkLicense function behaves differently between platforms:

• If compiled for Windows, the game sets an integer with a value of 0, decrements it, and then checks to see if it's less than 0. If so, it returns 0, indicating a success. Otherwise, it returns -2. Since the integer is always going to be -1 at the end every time, it will always return a success.
• If compiled for iOS, the game for some reason immediately returns 0, indicating a success. Despite this, there is extra code afterwards which would cause the anti-piracy checks to fail if it wasn't for the immediate return.
• If compiled for Android, the game calls a native function within Android which does all the checking for it. This is the only time the anti-piracy check actually works correctly.
• Otherwise, the game returns 0, indicating a success.

Dedicated Server#

The leak also contains an implementation of a basic dedicated server. It automatically creates a Creative Mode world with the seed set to the current Unix time. The world's name and directory are set by command-line arguments. It contains references to the ability to set a "server key" for API calls, but this is not implemented.

Mojang did not release an official dedicated server until Bedrock Edition 1.6.1 (almost five years newer than the contents of this leak). Previously, players were forced to use third-party software like PocketMine-MP, which often lacked critical features like Survival Mode.

Footnotes#