# ARCore SDK for Android: what the repository actually ships > The ARCore SDK for Android is Google's client library for motion tracking, environmental understanding and light estimation on ARCore-capable phones. This review covers what the repo contains, how to add it to a project, and where it stops being the right tool. **google-ar/arcore-android-sdk** — ARCore SDK for Android Studio - Repository: https://github.com/google-ar/arcore-android-sdk - Website: https://developers.google.com/ar - Stars: 5,242 · Forks: 1,280 - Language: C++ - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/google-ar-arcore-android-sdk ## What the ARCore SDK for Android repository is for The README states that the SDK provides APIs for motion tracking, environmental understanding and light estimation, and that these are meant to support new AR experiences or to add AR features to an existing app. That framing matters, because the repository is not the AR runtime. It is the client-side library and sample set that an Android app links against, while the actual tracking runs in Google Play Services for AR, a separate package the device installs. The target reader is an Android developer working in Android Studio, in Java, Kotlin, C or C++ through the NDK. The samples directory confirms the breadth: hello_ar_java, hello_ar_kotlin, hello_ar_c, hello_ar_vulkan_c, augmented_faces_java, augmented_image_java, augmented_image_c, cloud_anchor_java, persistent_cloud_anchor_java, geospatial_java, raw_depth_java, semantics_java, recording_playback_java, shared_camera_java, hardwarebuffer_java, hardwarebuffer_c, computervision_java, computervision_c, ml_kotlin, hello_eis_kotlin. Each one is a separate Gradle project demonstrating one capability. If you want a general-purpose AR engine that also targets iOS or the browser, this is the wrong repository, and the README does not pretend otherwise. ## How the SDK, Play Services for AR and your app fit together The layering is the part that trips people up. Your APK contains the ARCore SDK classes you compile against, but the tracking session is created through Google Play Services for AR, which is installed and updated by the Play Store independently of your app. That is why the README carries a breaking change notice about Google Play Services for AR removing support for 32-bit-only ARCore-enabled apps running on 64-bit devices. The README says support for 32-bit apps on 32-bit devices is unaffected, and that 32-bit-only apps not updated may crash when attempting to start an AR session. This is a runtime failure, not a build failure, which is the worst kind: the APK installs and the crash appears only on 64-bit hardware. The repository layout reflects the split between client code and the runtime. libraries/ holds the SDK artifacts, samples/ holds the runnable demonstrations, tools/ holds supporting scripts, and third_party/ holds vendored dependencies. The README points to two API references, one for Java and one for C, and to two quickstarts, one for Android Java and one for the NDK. There is no protocol documentation in the repository itself; the session lifecycle is documented on the developer site, and the repository assumes you read it there. ## Installing the ARCore SDK for Android and running a first sample The README does not give an install command. It points to the Quickstart for Android Java and the Quickstart for Android NDK developer guides, and the practical path for evaluating the SDK is to clone the repository and open one of the sample projects in Android Studio. The hello_ar_java sample is the smallest Java entry point. From a checkout of the repository, the Gradle wrapper in the sample directory is what you run. ## Installing the ARCore SDK for Android and running a first sample (continued) On Windows the wrapper is gradlew.bat in the same directory. The build expects a connected device or emulator with Google Play Services for AR available, and the README's own quickstart link is where the device preparation steps live. The SDK release notes are on the releases page, and the current release listed there is 1.56.0, dated 2026-09-04, with 1.54.0 before it on 2026-04-22 and 1.53.0 on 2026-03-10. If you are adding ARCore to an existing app rather than running a sample, the C and C++ path goes through the NDK quickstart and the C API reference instead, and the hello_ar_c sample is the corresponding starting point. ## The 64-bit-only failure mode and other real limits The clearest limitation is stated by the project itself. Google Play Services for AR has removed support for 32-bit-only ARCore-enabled apps on 64-bit devices, so an app that ships only armeabi-v7a native libraries can crash at session start. The README directs readers to developers.google.com/ar/64bit for the update instructions. If your build pipeline produces a single 32-bit ABI, this is a hard blocker, and it will not show up in local testing on a 32-bit device. A second limit is the deprecation policy. The README says apps built with ARCore SDK 1.12.0 or higher are covered by the Cloud Anchor API deprecation policy, while apps built with 1.11.0 or lower were unable to host or resolve Cloud Anchors beginning December 2020 because of the older Cloud Anchor service. That is a concrete example of the SDK version you compile against having a service lifetime attached to it, and it means an old APK can lose a feature without any code change. Third, the SDK is Android-only. The samples are all Android Gradle projects, and the repository contains no iOS, Unity or web client. Fourth, the licence. The repository LICENSE is classified as NOASSERTION, and the README states that by downloading the SDK you agree to the ARCore Additional Terms of Service. That is not an open source licence in the usual sense, and it is worth reading before you plan around the code. ## What you must disclose in your app The README has a user privacy requirements section that is easy to skip and expensive to ignore. It says you must disclose the use of Google Play Services for AR and how it collects and processes data, prominently in your application and easily accessible to users. It gives the exact text to place on your main menu or notice screen, naming Google LLC and pointing to the Google Privacy Policy, and links to developers.google.com/ar/develop/privacy-requirements. This is a distribution requirement rather than a technical one, but it belongs in the same checklist as the 64-bit ABI fix because both are conditions of shipping an ARCore-enabled app. ## ARCore SDK versus Unity's AR Foundation The most common alternative for teams that want the same tracking capabilities is Unity's AR Foundation, which wraps ARCore and ARKit behind one interface. The difference in approach is structural rather than cosmetic. With this repository you write Android code against the Java or C API, you own the Gradle build, and you get the platform's newest capabilities as soon as the samples and release notes cover them, which the sample list shows includes Vulkan rendering, raw depth, semantics, geospatial and shared camera. With AR Foundation you write C# against a cross-platform abstraction, and you accept that features arrive after the underlying platform exposes them and that the abstraction may not surface every ARCore-specific capability. If your product is Android-only and you need the depth, semantics or geospatial APIs directly, the native SDK is the shorter path. If you already ship on iOS as well, the cross-platform wrapper usually wins despite the lag. ## Maintenance, releases and upgrade cost The repository is not archived, and the last push was on 2026-09-04. The release cadence visible in the release list is roughly every six to eleven weeks: 1.53.0 on 2026-03-10, 1.54.0 on 2026-04-22, 1.56.0 on 2026-09-04. That cadence is the upgrade cost. Each release can carry a behaviour change delivered through Google Play Services for AR rather than through your APK, which is what the 32-bit notice demonstrates: the runtime changed under apps that had not changed. The practical consequence is that you should keep the SDK version and the device's Play Services for AR version in mind as two separate things when you debug, and you should read the release notes on the releases page before bumping. The licence situation adds a second kind of cost. The LICENSE file is classified as NOASSERTION, and the README ties use of the SDK to the ARCore Additional Terms of Service, so the terms are contractual rather than a permissive open source grant. Nothing here is legal advice, but a team that assumes Apache-2.0 because the code lives on GitHub is assuming something the repository does not state. ## Conclusion Adopt the ARCore SDK for Android if you are building a native Android AR app in Java, Kotlin or C and you accept that ARCore itself is delivered through Google Play Services for AR rather than bundled in your APK. Do not adopt it if you need iOS, Unity or WebXR, since the repository contains only Android client code and Android samples. Before committing, verify three things: that your build produces arm64-v8a native libraries as well as armeabi-v7a, that your app displays the privacy disclosure the README requires, and that the ARCore Additional Terms of Service at developers.google.com/ar/develop/terms are acceptable for your distribution. The 64-bit requirement is the one that breaks apps in production rather than at compile time. ## FAQ ### What is ARCore on Android? ARCore is the augmented reality platform the SDK targets, delivered on devices as Google Play Services for AR. The SDK itself provides APIs for motion tracking, environmental understanding and light estimation, and the README says these can be used to build new AR experiences or add AR features to existing apps. ### Which phones support ARCore? The repository does not list supported devices. The README points to the developer site at developers.google.com/ar for the quickstarts, API references and related documentation, and device support is not covered in the repository files. ### How do I check if my phone has ARCore? The README does not document a device check. It refers to Google Play Services for AR as the runtime that ARCore-enabled apps depend on, and to the developer site for the quickstart guides that cover device preparation. ### Is Google ARCore free? The repository does not state a price. It does state that downloading the ARCore SDK means agreeing to the ARCore Additional Terms of Service, and the LICENSE file is classified as NOASSERTION rather than a standard open source licence. ## Sources - [google-ar/arcore-android-sdk on GitHub](https://github.com/google-ar/arcore-android-sdk) - [Issues](https://github.com/google-ar/arcore-android-sdk/issues) - [Project website](https://developers.google.com/ar) - [README](https://github.com/google-ar/arcore-android-sdk/blob/main/README.md) - [Releases](https://github.com/google-ar/arcore-android-sdk/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-ar-arcore-android-sdk