AndroidX 란 무엇입니까

AndroidX 란 무엇입니까

---

Android의 방 라이브러리에 대해 읽고 있습니다. 패키지가 android로 변경되었습니다 androidx. 난 이해 못 했어. 누군가 설명해주세요.

implementation "androidx.room:room-runtime:$room_version"
annotationProcessor "androidx.room:room-compiler:$room_version"

이것도 android패키지 와 함께 사용할 수 있습니다.

implementation "android.arch.persistence.room:runtime:$room_version"
annotationProcessor "android.arch.persistence.room:compiler:$room_version"

• androidx대신 새로운 지원 라이브러리를 패키징해야하는 것 android.
• 유스 케이스 및 기존 프로젝트의 요인에 영향을줍니다.

---

AndroidX-Android 확장 라이브러리

에서 AndroidX 문서

Android 운영 체제와 함께 제공되는 패키지와 앱의 APK와 함께 제공되는 패키지를보다 명확하게하기 위해 새로운 패키지 구조를 출시하고 있습니다. 앞으로 android. * 패키지 계층은 운영 체제와 함께 제공되는 Android 패키지 용으로 예약됩니다. 다른 패키지는 AndroidX 라이브러리의 일부로 새로운 androidx. * 패키지 계층에서 발행됩니다.

AndroidX의 필요

AndroidX는 패키지 이름을보다 명확하게하기 위해 새롭게 디자인 된 라이브러리입니다. 이제부터 안드로이드 계층 구조는 안드로이드 운영 체제와 함께 제공되는 안드로이드 기본 클래스에만 적용되며 다른 라이브러리 / 종속성은 androidx의 일부가 됩니다 (더 의미가 있습니다). 이제부터 모든 새로운 개발이 androidx에서 업데이트 될 것입니다.

com.android.support. ** : androidx.
com.android.support:appcompat-v7 : androidx.appcompat : appcompat com.android.support:recyclerview-v7 : androidx.recyclerview : recyclerview com.android.support:design : com.google.android.material : material

AndroidX 패키지에 대한 완전한 아티팩트 맵핑

AndroidX는 시맨틱 버전을 사용합니다.

이전 support library에는 SDK 버전을 사용했지만 AndroidX는을 사용합니다 Semantic-version. 28.0.0 → 1.0.0에서 버전이 변경됩니다.

현재 프로젝트를 마이그레이션하는 방법

Android Studio 3.2 (2018 년 9 월)에는 기존 프로젝트를로 마이그레이션하는 직접 옵션이 있습니다 AndroidX. 이것은 모든 패키지를 자동으로 리팩토링합니다.

마이그레이션하기 전에 프로젝트를 백업하는 것이 좋습니다.

기존 프로젝트

• Android Studio> 리 팩터 메뉴> AndroidX로 마이그레이션 ...
• Refractor 윈도우를 분석하고 하단에 엽니 다. 수행 할 변경을 승인하십시오.

새로운 프로젝트

이 깃발을 당신의 gradle.properties

android.enableJetifier=true
android.useAndroidX=true

동일한 AndroidX 패키지에 대한 @Library 맵핑을 확인하십시오 .

AndroidX로 마이그레이션 @ 공식 페이지 확인

Jetifier 란 무엇입니까?

이주의 벌레

• 앱을 빌드하고 마이그레이션 후 일부 오류를 발견하면 사소한 오류를 수정해야합니다. 쉽게 고칠 수 있기 때문에 거기에 갇히지 않을 것입니다.
• 3 자 라이브러리 디렉토리에 AndroidX로 변환되지 않습니다,하지만 그들은에 의해 실행시에 변환됩니다 Jetifier 때문에 컴파일시 오류에 대한 걱정을하지, 앱 완벽하게 실행됩니다.

지원 28.0.0은 마지막 릴리스입니까?

에서 안드로이드 지원 개정 28.0.0

This will be the last feature release under the android.support packaging, and developers are encouraged to migrate to AndroidX 1.0.0

So go with AndroidX, because Android will update only androidx package from now.

Further Reading

https://developer.android.com/topic/libraries/support-library/androidx-overview

https://android-developers.googleblog.com/2018/05/hello-world-androidx.html

---

Based on the documentation:

androidx is new package structure to make it clearer which packages are bundled with the Android operating system, and which are packaged with your app's APK. Going forward, the android.* package hierarchy will be reserved for Android packages that ship with the operating system; other packages will be issued in the new androidx.* package hierarchy.

The re-designed package structure is to encourage smaller and more focused libraries. You find details regarding the artifact mappings here.

There are support libraries (containing component and packages for backward compatibility) named "v7" when the minimal SDK level supported is 14, the new naming makes it clear to understand the division between APIs bundled with platform and the libraries for app developers which are used on different versions of android. You can refer to official announcement for more details.

---

AndroidX is the open-source project that the Android team uses to develop, test, package, version and release libraries within Jetpack.

AndroidX is a major improvement to the original Android Support Library. Like the Support Library, AndroidX ships separately from the Android OS and provides backwards-compatibility across Android releases. AndroidX fully replaces the Support Library by providing feature parity and new libraries.

AndroidX includes the following features:

• All packages in AndroidX live in a consistent namespace starting with the string androidx. The Support Library packages have been mapped into corresponding androidx.* packages. For a full mapping of all the old classes and build artifacts to the new ones, see the Package Refactoring page.

• Unlike the Support Library, AndroidX packages are separately maintained and updated. The androidx packages use strict Semantic Versioning starting with version 1.0.0. You can update AndroidX libraries in your project independently.

• All new Support Library development will occur in the AndroidX library. This includes maintenance of the original Support Library artifacts and introduction of new Jetpack components.

Using AndroidX

See Migrating to AndroidX to learn how to migrate an existing project.

If you want to use AndroidX in a new project, you need to set the compile SDK to Android 9.0 (API level 28) or higher and set both of the following Android Gradle plugin flags to true in your gradle.properties file.

• android.useAndroidX: When set to true, the Android plugin uses the appropriate AndroidX library instead of a Support Library. The flag is false by default if it is not specified.

• android.enableJetifier: When set to true, the Android plugin automatically migrates existing third-party libraries to use AndroidX by rewriting their binaries. The flag is false by default if it is not specified.

For Artifact mappings see this

---

This article Android Jetpack: What do the recent announcements mean for Android’s Support Library? explains it well

Today, many consider the Support Library an essential part of Android app development, to the point where it’s used by 99 percent of apps in the Google Play store. However ,as the Support Library has grown, inconsistencies have crept in surrounding the library’s naming convention.

Initially, the name of each package indicated the minimum API level supported by that package, for example support-v4. However, version 26.0.0 of the Support Library increased the minimum API to 14, so today many of the package names have nothing to do with the minimum supported API level. When support-v4 and the support-v7 packages both have a minimum API of 14, it’s easy to see why people get confused!

To clear up this confusion, Google is currently refactoring the Support Library into a new Android extension library (AndroidX) package structure. AndroidX will feature simplified package names, as well as Maven groupIds and artifactIds that better reflect each package’s content, and its supported API levels.

With the current naming convention, it also isn’t clear which packages are bundled with the Android operating system, and which are packaged with your application’s APK (Android Package Kit). To clear up this confusion, all the unbundled libraries will be moved to AndroidX’s androidx.* namespace, while the android.* package hierarchy will be reserved for packages that ship with the Android operating system.

---

Just some bits addition from my side to all available answers

Need of AndroidX

1. As said in amazing answer by @KhemRaj,

With the current naming convention, it isn’t clear which packages are bundled with the Android operating system, and which are packaged with your application’s APK (Android Package Kit). To clear up this confusion, all the unbundled libraries will be moved to AndroidX’s androidx.* namespace, while the android.* package hierarchy will be reserved for packages that ship with the Android operating system.

2. Other than this,

   Initially, the name of each package indicated the minimum API level supported by that package, for example support-v4. However, version 26.0.0 of the Support Library increased the minimum API to 14, so today many of the package names have nothing to do with the minimum supported API level. When support-v4 and the support-v7 packages both have a minimum API of 14, it’s easy to see why people get confused!. So now with AndroidX, there is no dependence on the API level.

Another important change is that the AndroidX artifacts will update independently, so you’ll be able to update individual AndroidX libraries in your project, rather than having to change every dependency at once. Those frustrating “All com.android.support libraries must use the exact same version specification” messages should become a thing of the past!

---

It is the same as AppCompat versions of support but it has less mess of v4 and v7 versions so it is much help from Using the different components of android XML elements.

---

AndroidX is the open-source project that the Android team uses to develop, test, package, version and release libraries within Jetpack.

After hours of struggling, I solved it by including the following within app/build.gradle:

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

Put these flags in your gradle.properties

android.enableJetifier=true
android.useAndroidX=true
Changes in Manifest:

implementation 'androidx.appcompat:appcompat:1.0.2'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'androidx.legacy:legacy-support-v4:1.0.0'
implementation 'com.google.android.material:material:1.1.0-alpha04'

참조 : https://developer.android.com/jetpack/androidx/migrate

참고 URL : https://stackoverflow.com/questions/51280090/what-is-androidx