Profile cover photo
Profile photo
YOUNG HO CHA
795 followers -
Digging android platform
Digging android platform

795 followers
About
Posts

Post has attachment
My nougat devices
Photo

2008년에 구입해서 사용하던 Onkyo TX-SR606가 제기능을 상실한지 반년 가까이 되었는데, 벼르고 벼르다가 이번기회에 Yamaha RX-V381 로 갈아탔습니다.

기존에 사용하던 Onkyo의 경우에는 구입할 당시만 해도 중간급 사양이었는데, 이번에 구입한 야마하 리시버는 완전 초급용입니다. 하지만 8년의 세월이 흐르면서 중간급 사양에만 들어갔던 기능들이 이제는 초급용 리시버에 몽땅 흡수가 되어버렸네요.

기존에 사용하던 리시버와 기능별로 다른 점은 다음과 같습니다.

추가된 기능
* usb mp3 플레이 기능 추가
* bluetooth 연결 기능 추가
* hdmi 1.3a 대응 -> hdmi 2.0 대응 (4k@60Hz)
* HDMI CEC Remote Control Passthrough 지원 추가. (리시버의 리모콘으로 PS4나 Android TV의 컨텐츠 재생 제어 및 커서 키 제어 가능)
* HDMI CEC Device OSD Name Transfer 지원 추가. (HDMI로 연결된 미디어 소스 기기이름이 자동으로 표시됨)

다운그레이드
* component 및 s-video 출력 안됨
* 7.1 채널 -> 5.1 채널 (어차피 스피커를 5.1조로 가지고 있어서 ;; )
* Zone 2 출력 기능 안됨


그리고 이놈보다 더 좋은 사양으로 가면 이런 기능이 추가가 되네요.
* Wifi, Ethernet 연결 (스마트폰을 이용한 제어기능, Apple AirPlay, Spotify 등등)
* 3D Audio 포맷 (Dolby Atmos, DTS-X) 지원
* 펌웨어 업데이트
* HDMI upscaling

이런 기능들은 저한테는 유용하지 않을 것 같아서 구매할 때 고려사항에서 제외했습니다.

이번에 구입하고 나서 매우 큰 만족감을 준 기능은 HDMI-CEC입니다. 덕분에 리시버의 리모콘 하나로 대부분의 기기 기능을 사용할 수 있게 되었습니다.
단점은 아직 Power Off컨트롤을 HDMI-CEC로만 할 수 없다는 것인데, 사용하고 있는 TV가 구형이라 어쩔수가 없네요.

이제 이놈 덕분에 다시 편안한 AV감상 및 게이밍 라이프를 즐길 수 있게 되었습니다.

간만에 지름 후기였습니다..(..)

Post has attachment
얼마전에 Google Camera 앱이 3.1로 업데이트 되었습니다.
롤리팝부터 지원하던 Camera 2 api[1](Camera 3.2 Hal[2])를 전면적으로 수용한 것으로 보이는데요, 원래 넥서스 5x/6p 에 포함되어 배포되었던 것을 전체 넥서스기기에 확장 적용시켰나봅니다.

제가 만들고 있는 짝퉁 넥서스4 롬에도 잘 굴러가겠거니 싶어서 후딱 설치하고 돌려봤는데, UI가 바뀐 것 말고는 기능 자체는 틀릴것이 보이지 않았습니다. (어차피 하드웨어에서 지원하는 기능만 제공될테니, 딴건 바라지 말아야;; )

그런데 이것저것 살펴보던 중 캠코더 모드로 전환하면 카메라앱이 카메라에 연결하지 못했다는 다이얼로그와 함께 강제종료되는 현상을 발견했습니다.

로그를 유심히 살펴보니, camera 앱에서 preview 화면을 캠코더의 기본 해상도와 동일한 1920x1080을 요구하는 것으로 보입니다. 그런데 넥서스 4의 해상도는 720p 수준이기 때문에 그것보다 더 큰 preview 화면 해상도를 제공하지 않습니다. (휴대폰의 카메라에 대한 자세한 정보는 adb 연결 후, "adb shell dumpsys media.camera" 명령을 이용하면 알 수 있습니다.)

reddit의 글타래[3]에서, android 6.0이 정식으로 지원되는 Android One 기기에서도 동일한 현상이 나타나는데, 해상도를 줄이면 정상 동작한다는 이야기가 있는 것으로 봐서는 작은 해상도를 가진 기기에서는 동일하게 발생하는 카메라 앱 자체의 버그로 보였습니다.

그래서 아쉽게도 Camera 3.1 에서는 비디오 녹화 기능을 720p로만 사용할 수 밖에 없을 것 같습니다.

그.런.데, 720p로 설정한 후에도 여전히 캠코더 전환에서 오류가 발생하고 있어서 살펴보니, 이전 것과 다른 오류 메세지가 발생합니다.
Camera Preview 화면을 렌더링할 Texture Surface가 잘못되었다라고 나오는데요. 그냥 저렇게 나오는 메세지 만으로는 원인 분석이 힘들어 보입니다.
그래서 카메라 관련 디버깅 메세지를 모두 켜봤는데요. 카메라 관련 api의 소스에 정의된 DEBUG[4] 라는 상수들의 값을 변경후 롬을 빌드하면 온갖 자잘한 디버깅 메세지가 같이 출력됩니다.

이렇게 디버깅 메세지를 켜놓고 살펴본 결과, 해당 문제는 camera 에서 camcoder 모드로 전환할 때 camera preview 를 출력하는 texture surface 도 교체하면서 발생하는 것으로 보였습니다.

카메라 앱 안에서 캠코더 모드로 진입하려면 무조건 카메라 모드 전환이 이루어지기 때문에, 카메라 앱을 강제로 종료하고, am 명령[5]을 이용해 바로 캠코더 모드로 진입하도록 해봤습니다.
역시 예측대로 캠코더 모드로 오류없이 동작하는 것을 확인했습니다.
즉 문제는 camera 모드에서 camcoder 모드로 전환하면서, texture surface 를 교체하는 타이밍 이라는 것입니다.
그래서 모드 전환에 필요한 camera api(capture 중지 요청)를 호출하면 중간에 살짝 쉬게(sleep 호출)해주니 아무 오류없이 멀쩡하게 동작합니다.
사실 이러한 부분을 제대로 처리하려면 camera의 하드웨어 추상 계층(hal)에서 해줘야 합니다만, 여기까지 알아내는데 거의 6시간을 소비해서 (빌드 - 부팅 - 확인 - 리빌드 의 연속) 더 이상 진행하기 힘들었기 때문에 그냥 땜빵으로;; 마무리 했습니다.

그리고 캠코더 모드에서 화면의 방향이 엉뚱하게 설정되는 현상도 자주 발생하는데, 이걸 잡는 것은 다음 주로 미뤄야겠습니다. (일단 camera service에서 화면 돌리는 api는 수행을 했는데, surface flinger에서는 해당 texture surface에 rotation이 적용되지 않은 것 까지 확인)

일단 위 현상에 대한 땜빵 수정과 함께 이것 저것 업데이트 한 짝퉁 넥서스 4용 롬은 xda developers 의 thread 에 올려두었습니다.[6]

#ghackfair #삽질의종말은언제나허무하다 #으어내주말

[1]: https://d.android.com/reference/android/hardware/camera2/package-summary.html
[2]: http://s.android.com/devices/camera/camera3.html
[3]: https://www.reddit.com/r/Android/comments/3tbcoh/google_camera_31021_242880830_arm_android_60/cx4qw05https://www.reddit.com/r/Android/comments/3tbcoh/google_camera_31021_242880830_arm_android_60/cx4qw05
[4]: https://github.com/android/platform_frameworks_base/blob/master/core/java/android/hardware/camera2/impl/CameraCaptureSessionImpl.java#L42
[5]: https://developer.android.com/tools/help/shell.html#am
[6]: http://forum.xda-developers.com/nexus-4/development/fake-nexus-rom-nexus-4-t3230268

지난 포스팅[1]에서 Stub앱에 대해서 간략하게 이야기했었습니다.

기능 자체는 아주 간단한데요. 지난 포스트를 인용하면 다음과 같습니다.

* 앱의 아이콘
* 런쳐에서 표시할 앱의 이름
* 아주 작은 dalvik bytecode (시작되면 Play Store로 전달해줌)

그리고 빼먹은게 있었는데, 바로 앱이 어떠한 동작에 대해서 구동되는지 결정하는 Intent filter 인데요.

Android에서 앱 동작은 Intent[1] 에 의해서 정의가 되고, 앱에서는 Intent Filter 를 구성해서, 자기가 어떤 일을 할 수 있는지 OS에게 알려줍니다.

보통은 기본 동작임을 알리는 ACTION_MAIN 과 런쳐에서 표시할 수 있도록 하는 CATEGORY_LAUNCHER 의 조합이 많이 사용되긴 합니다만, 이 외에도 여러가지 동작에 대해 정의를 내릴 수 있습니다.
예를 들면,  ACTION_SEND[2] 같은 Intent를 이용해 공유 동작을 구현할 수도 있습니다.

Stub 앱의 경우, 동작 자체는 Play Store를 수행하고 끝내는 간단한 앱이지만, 원래 앱이 가지고 있던 Intent Filter를 모두 등록하면, 아직 실제 앱이 설치가 되어있지 않더라도 동일한 동작에 대해 해당 앱을 추가적으로 설치할 수 있도록 유도할 수 있어서 유용해 보입니다.

하지만 만들어야할 앱 개수도 상당히 많고, 앱에 포함된 intent filter 도 아주 다양해서 일일이 만들어 나가는 것은 그렇게 괜찮은 방법이 아닐 것 같았습니다.
더군다나 앱의 아이콘과 런쳐에 표시되는 앱의 이름도 언어별로 일일이 만들어 줘야 하는 것도  더더욱 큰일입니다.

그래서 Stub 앱 작성을 직접 하지않고, AndroidManfiest 및 resource를 기존의 apk를 분석해 생성(generation)하는 방법을 찾아보기로 햇습니다.

apk 분석 도구 중에서 유명한 것은 apktool[4]과 androguard[5]가 있습니다.
그 중 , 저한테 익숙한 python 기반의 라이브러리인 androguard를 이용했습니다.
(그리고 apktool은 아직 marshmallow용으로 빌드한 바이너리에 대해서 정상동작하지 않습니다.)

androguard를 이용하면, apk에 포함된 AndroidManifest.xml 을 python 표준 dom 으로 접근이 가능합니다.
이를 이용해 다음 정보를 추출했습니다.

* package 이름
* 해당 Application 및 Activity의 표시 이름과 아이콘
* 포함된 Activity 목록
* 해당 Activity를 구동할 Intent Filter

그리고 위 정보를 포함하는 dom element를 이용해,  모든 Activity에 대해 Play Store로 돌리는 역할을 하는 Activity와 alias 를 걸어주는 AndroidManifest.xml 을 구성하는 python 스크립트를 작성했습니다.

즉 원래 apk 에 포함된 AndroidManifest의 activity element가 아래와 같이 정의가 되어있으면...

<activity android:name="MusicBrowserActivity" >
    <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.LAUNCHER" />
     </intent-filter>
</activity>

dom 을 가공해 아래와 같이 AndroidManifest 을 생성하도록 합니다.

<activity   android:launchMode="singleTask"
            android:name="com.google.android.stub.PlayStoreRedirectActivity"
            android:noHistory="true"
            android:theme="@android:style/Theme.NoDisplay"/>

<activity-alias android:name="MusicBrowserActivity"
  android:targetActivity="com.google.android.stub.PlayStoreRedirectActivity" >
    <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.LAUNCHER" />
     </intent-filter>
</activity>

Activity의 표시 이름과 아이콘은 일반적으로 resource를 참조하도록 하는데, 바이너리 내에서는 컴파일되어서 resource id값으로 해석이 된 채로 포함되어 있습니다.
따라서 resource id를 이용해 원래 resource 이름 (string/app_name또는 drawable/ic_launcher 과 같은 형태)를 찾도록 했습니다.

그리고 위 작업과 함께 Stub을 현재 Android Platform 의 빌드환경을 이용해 apk를 생성할 수 있도록 Android.mk 파일도 생성[6]한 후, 곧바로 apk를 빌드[7]하고, 원래 앱 apk 파일의 public certificate key를 추출해 교체[8]하도록 했습니다.

이렇게 Stub App 작성 스크립트를 사용해 10개의 stub app을 작성하여,  약 150mb 가량의 공간을 절약할 수 있었습니다.

#ghackfair #이렇게작업은산으로가고

[1]: https://plus.google.com/+YoungHoCha/posts/YdnoGbVX3X3
[2]: https://developer.android.com/guide/components/intents-filters.html
[3]: https://developer.android.com/reference/android/content/Intent.html#ACTION_SEND
[4]: https://ibotpeaches.github.io/Apktool/
[5]: https://github.com/androguard/androguard
[6]: https://goo.gl/OOPkSL
[7]: https://goo.gl/riH0yj
[8]: https://goo.gl/FwzIYL

넥서스용 롬을 만들면서 제일 어려웠던 부분은 롬의 크기 관리였습니다.
넥서스4의 OS용량으로 배정된 크기는 840Mb 인데, 구글의 모든 서비스를 포함하기에는 너무나도 작았습니다.

최근 출시된 넥서스5x/6p의 경우 OS에 할당된 3Gb 저장소 중 2Gb가량을 사용하고 있습니다. 물론 64bit 환경으로 바뀌면서, 32bit 및 64bit 용 바이너리가 모두 포함되어야 하기 때문에 용량이 커진 것도 있습니다만, 구글의 모바일용 앱의 종류와 크기도 그만큼 커져버렸습니다.

현재 구글에서 배포하고 있는 기본 모바일용 앱들의 크기를 모두 합하면 700M가 넘어가며, 즉 기본앱은 아주 일부를 제외하고는 기본탑재가 불가능한 상태입니다.

그런데 이러한 상황은 넥서스4 뿐만 아니라  넥서스5도 마찬가지입니다. 넥서스5에서 OS에 배정된 저장장소 용량은  1Gb 이며, Nexus4 보다 여유가 있는 편이기는 합니다만, 용량이 부족합니다.

하지만 이번에 Android 6.0에 정식으로 지원하는 Nexus 5의 경우에는 용량부족을 해결해서 출시를 해버렸고, 그 흉내를 내보기로 했습니다.

Nexus 5의 팩토리 롬에는 PrebuiltKeepStub.apk 이라는 이름의 앱이 미리 탑재 되어있는데,  이름을 보면 눈치챘겠지만 Google Keep 앱의 껍데기(?)입니다.

Google Keep의 경우 12mb 가량 됩니다만, Nexus 5에 포함된 녀석은 40kb 밖에 되지 않습니다. aapt 로 확인해보면 apk 내부에 다음과 같은 정보만 포함되어 있는 것을 알 수 있습니다.

* 앱의 아이콘
* 런쳐에서 표시할 앱의 이름
* 아주 작은 dalvik bytecode

dexdump라고하는 dalvik bytecode 해석기를 통해서 포함된 bytecode를 표시하면 다음과 같은 내용을 볼 수 있습니다.

https://gist.github.com/ganadist/28f676079e1fe40ee49b

dalvik의 표현방식이라서 약간 생소할 수 있지만, 동일한 부분을 자바 코드로 표현하면 다음과 같습니다. (클래스 이름은 임의로 변경했습니다.)

https://github.com/ganadist/gms_addon/blob/android-6.0.0_r1/src/stubs/src/com/google/android/stub/PlayStoreRedirectActivity.java

해당 앱이 시작되면, Play Store에 있는 앱의 안내페이지로 돌려버리고 종료하는 간단한 코드입니다. 또한 Play Store의 자동업데이트 기능으로 인해,  최신 앱으로 업데이트가 될 수 있습니다.

Nexus 5의 경우, Keep뿐만 아니라 Google Doc, Sheet, Slide, Messenger, Newsstand 등의 앱이 실제 앱 대신 크기가 작은 Stub 앱으로 교체되어 있었습니다.

그러면 Nexus5 보다 여유공간이 적은 Nexus 4의 경우에는 더 많은 앱들에 대해서 Stub형식으로 교체하면 용량문제를 해결할 수 있을 것 같습니다.

하지만 여기에 큰 장벽이 있는데, Stub 앱은 해당 앱의 제작사만이 만들 수 있습니다.
출시되는 앱에는 제작사가 자기가 만들었다고 증명할 수 있는 public certificate key 와 apk에 포함된 파일에 대한 변조가 포함되어 있는지 확인할 수 있는 sign이 포함되어 있는데,  명백하게 타인인 저로서는 그러한 정보를 포함하는 apk를 만들 수가 없었습니다.

하지만 위 기능도 어차피 OS에서 제공을 하니,  OS에서 임의로 동작형식을 바꾸면 해결할 수 있을 것 같아서 수정해보았습니다.

OS에서는 먼저 포함된 파일의 sign이 올바른지 확인한 후, 처음 설치시에는 certificate key를 os에서 저장하고, 업그레이드 될 때에는 이전에 설치되었던  저장했던 key와 새로 설치된 apk내의 key가 동일한지 살펴봅니다.

즉 예전에(또는 OS에 미리) 설치된 앱의 경우 public certificate key만 변조되지 않았다고 착각하게 만들면 상관이 없어지게 됩니다.

Android에서는 PackageParser 라는 class의 collectCertificates라는 메소드[1]에서 StrictJarFile 인스턴스 생성 시 sign이 올바른지 확인하고, 그 후 certificate key를 추출 및 비교를 하게 됩니다.

이 부분에서 sign 검증하는 부분을 제외시켜 버리고, certificate key만 추출해 강제로 적용되도록 임의로 변경[2]했습니다.

또한 임의로 저 기능을 계속 활성화 시켜두면, 보안에 치명적인 약점이 될 수 있기 때문에, 해당 동작은 OS에 미리 설치된 앱(apk의 경로가 /system 으로 시작)에 한해서만 적용되도록 했습니다.

그리고 임의의 Stub앱을 작성한 후,  원래 앱에서 추출한 public certificate key(apk파일안에 META-INF/CERT.RSA 라는 이름으로 존재)를 StubApp에 포함하게 하면, 원래 구글에서 배포한 앱인 것처럼 동작하는 것을 확인할 수 있었습니다.

그리고 이 기능을 적용하면서 뜻하지 않게 얻을 수 있는 잇점이 생겼는데요.

바로 구글에서 배포하는 OS에서 *직접 업그레이드가 가능*해졌다는 것입니다.

일반적으로 커스텀 롬을 설치할 때에는 factory reset을 해야만 정상적으로 동작하게 됩니다.
Android에서는 앱 뿐만 아니라 OS에도 동일하게 public certificate key를 비교하게 되는데, 이미 OS에 포함되어 있기 때문에 설치 실패는 발생하지 않습니다만, 해당 앱이 가지고 있던 모든 permission이 무효화 되기 때문에 OS가 오동작하게 됩니다.

하지만 OS에 내장된 모든 apk에 대해서 인증서만 수집해서 강제로 적용하기 때문에,  위와 같은 현상이 발생되는 것을 피할 수 있었습니다.

#ghackfair #업그레이드도되는신기방기한놈

[1]: https://goo.gl/vbA9KA
[2]: https://goo.gl/8AdsOM

Post has attachment
11월 3일에 android 11월 보안패치와 함께 올해 출시한 nexus 5x/6p 용 소스도 함께 공개되었습니다.
그런데 기존의 안드로이드 기기의 소스(marshmallow-release)와 다르게 올해 나온 기기를 위한 별도의 브랜치(marshmallow-dr-release)가 생성되었습니다.
(개발버젼인 master 는 marshmallow-dr-release 가 merge[1] 되었으므로, 해당 브랜치가 앞으로 안드로이드 OS개발의 기준점이 될 것입니다.)

기존의 다른 기기를 위한 브랜치와 다른게 뭐가 있을까 싶어서 살짝 뒤벼봤는데, 별로 바뀐게 없는 듯 하면서 은근히 여기저기가 수정되어 있습니다. (메모리 릭 수정, 인터넷 전화기능 보강, 기타 등등)

하지만, 하드웨어와 연계되는 부분인 HAL(Hardware Abstraction Layer, [2], [3])은 변경된 부분이 거의 없으므로, 다른 기기(이 경우에는 넥서스4)에서도 역시 Nexus 5x/6p 용 OS를 문제없이 구동 시킬수 있을 것 같습니다.

일단 아무 생각없이 소스를 받고, 기존의 빌드 스크립트를 이용해 빌드 후 부팅을 해보았습니다.
겉 보기에는 멀쩡하게 보였는데, 전화 관련된 기능들이 조금씩 오동작을 하고 있었습니다.

일단 dialer 아이콘이 사라져서 전화를 걸 수 없는 휴대폰이 되어버렸습니다. 그런데 자세히 살펴보니 문자앱 등에 있는 전화 아이콘으로 전화를 걸 수 있는 것을 확인했습니다.
즉 런쳐에서만 사라져있고 전화를 거는 기능은 살아있는 것이었습니다. 일반적으로 android에서는 각종 컴포넌트(activity, service, provider, broadcast receiver, application)등은 package manager[4]를 통하거나 AndroidManifest.xml에서 해당 컴포넌트 정의 내에 android:enabled 속성을 이용해서 사용하지 못하도록 설정을 할 수가 있습니다.
확인해보니, 전화가 가능하다는 것을 뜻하는 상수인 bool/config_voice_capable[5]의 값을 이용해 dialer 활성화를 결정하는데, marshmallow-dr-release 소스에서는 리소스가 추가되면서 해당 값의 resource id 가 밀려서 엉뚱한 값을 참조하고 있었고, 그 엉뚱한 값을 AndroidManifest.xml에서 참조하고 있었습니다.

일단 package manager의 api 를 이용해 강제로 enable 하도록 해서 수정하였습니다. [6]

그리고 전화 통화를 시작하면 음성통화 소리가 들리지 않는 버그도 있었습니다.
로그를 열어서 살펴보니 android의 audio, camera, 및 media를 처리하는 mediaserver 가 계속해서 crash 가 발생하고 있었습니다.
열심히 디버깅 해보니, 퀄컴의 audio hal 을 수정[7]하면서, 예전 기기(n4, n5, n7)에 대해서는 상수를 정의하지 않아서, 오디오 장치의 초기화가 올바르게 되지 않고 있었습니다.

일단 n4에 대해서 상수를 정의하도록[8] 하니 올바르게 동작하는 것을 확인했습니다.

이렇게 해서 Nexus 4에 Nexus 5x/6p 의 OS를 우여곡절끝에 구동시켰습니다.

#ghackfair   #이미넥서스5x를쓰는느낌  

[1]: https://goo.gl/hvujVK (소스 릴리즈 공지)
[2]: https://goo.gl/LPZgLN (HAL 인터페이스가 정의된 c header들)
[3]: http://s.android.com/devices/index.html (구글에서 제공하는 android hal 기술 문서)
[4]: https://goo.gl/g8e68F (Package Manager에서 컴포넌트의 이용 가능 상태를 제어하는 api)
[5]: https://goo.gl/rOuu0t
[6]: https://goo.gl/ASysdh (dialer를 강제로 enable하는 땜빵코드)
[7]: https://goo.gl/cGHB7v
[8]: https://android-review.googlesource.com/181076

Post has attachment
어제(11월 3일) 안드로이드6.0에 대한 11월 보안패치 버젼이 출시되었습니다.

아침에 화장실에서 뉴스사이트를 뒤벼보다가 소스가 올라온 걸 확인한 후, 5분만에 소스를 내려받고 10분만에 넥서스4용 업데이트 빌드를 완료했습니다.

넥서스4 관련 커스텀롬 중에서는 유일하게 실시간으로 업데이트를 완료해버렸네요. (그만큼 쓰는 사람들이 없다는게 함정1, 실제 장치에서 업데이트 하는데는 cpu가 느려서 30분 가량 걸렸다는게 함정2)

일단 11월 보안패치 버젼에 맞게 브랜치(릴리즈 정책이 aosp 업스트림과 좀 달라서 tag이름을 브랜치 이름으로 사용하고, 계속 찔끔찔끔 수정하고 있습니다.)를 따서 수정한 내역을 올려놨습니다.

#ghackfair  #넥서스4로넥서스5x를만드는연금술 

http://forum.xda-developers.com/nexus-4/development/fake-nexus-rom-nexus-4-t3230268

Post has attachment
MRA58V[1] (Nov Security patch, android-6.0.0_r5 for flo: Nexus 7 2013) is released on AOSP (but manifest.xml is not released yet.)
And I am preparing to apply my rom.
Stay tune.

#ghackfair #‎넥서스4로넥서스5x를구해보자

[1]: https://android.googlesource.com/platform/build/+/android-6.0.0_r5

Post has attachment
요새 취미생활(?)로 넥서스 4용 롬[1]을 깎고 있는데.
이걸로 핵페어[2] 신청을 보냈습니다.

GDG Android Korea에서 썰[3]도 한번 풀었고, 어려울 꺼라고 생각했던 롬 사용량 줄이기도 저번 주[4]에 끝내버리서, 제 마음대로의 milestone(이전 버젼에 포함되었던 기능을 모두 포함하면서, OS버젼 업데이트 하기)까지는 도달했다고 생각합니다.

앞으로 핵페어가 열리기 전까지 남아있는 일을 정리하자면 다음과 같습니다.


1. 11월에 올라올 보안 업데이트기반의 새로운 롬 릴리즈 및 업데이트 대응 롬 제작시 불편한 점 개선하기

2. 사용하다가 발견하는 자잘한 버그들 수정 및, 가능하면 upstream에 올리기. (그런데 의외로 버그가 안보이네요. OTL )

3. 다른 사람이 fork해서 쉽게 자기만의 롬을 만들 수 있도록 문서 작성및 (일일이 문서화 하기 귀찮으니) 빌드에 도움이 되는 스크립트를 정리

4. 팩토리 이미지에서 빌려온(?) 바이너리들에 대한 copyright 명시;;;;

 남은 제일 큰 난제는 프로젝트 데모(홍보?) 영상을 만드는 건데.. 도저히 감이 잡히지 않네요. OTL
그냥 구글 포토 어시스턴트가 만들어주는 걸 올려버릴까;;

#ghackfair #‎넥서스4로넥서스5x를구해보자‬

[1]: http://forum.xda-developers.com/nexus-4/development/fake-nexus-rom-nexus-4-t3230268
[2]: http://googledevkr.blogspot.kr/2015/10/hack.html
[3]: https://goo.gl/4c5O1c
[4]: https://goo.gl/dIvjjp

Post has shared content
구글의 넥서스 팀에서 AMA(Ask Me Anything: 무엇이든 물어보세요)를 진행했습니다.
재미있어 보이는 질답을 요약해보겠습니다.

Q: 5X와 6P는 뭘 뜻하나요?
A: neXus 의 X(정중앙.. 또는 핵심임을 강조)와 Premium의 P 입니다.

Q: 5X와 6P의 카메라는 어떻게 다른가요?
A: 6P는 240fps지원(5X는 120fps)하고, 6P에서만 smartbust와 EIS(Image Stablization)이 동작합니다. 5X에 포함된 Snapdragon 808에서는 해당기능을 동작하기에 cpu와 gpu가 딸립니다.

Q: 6P의 AMOLED는 어떤 물건인가요?
A: 최신(latest gen) 삼성 AMOLED입니다. (미사여구 잔뜩)

Q: 지문정보는 안전하게 암호화 되나요? 그리고 어디에 저장이 되나요?
A: 지문 정보는 TrustZone(OS와 별개의 영역)에 저장되고, 기기에만 저장됩니다. 구글과 공유되지는 않습니다.

Q: QI(무선충전)기능은 왜 빠졌나요?
A: 애초에 무선충전을 넣었던 이유는 충전이 불편해서 입니다.(usb2 포트 및 긴 충전시간) 이제는 usb3 c type을 지원하고 훨씬 짧아진 충전시간 때문에 그러한 불편함이 없어졌습니다. 또한 QI를 빼면 더 얇아집니다.

Q: Nexus 5X는 usb 3.1을 지원하나요?
A: 5X와 6P는 모두 usb 2.0을 지원합니다.

Q: 6P의 내장 저장 메모리는 UFS 2.0을 사용하나요?
A: 5X와 6P는 모두 EMMC 5.0을 사용합니다.
(UFS 2.0과 EMMC 5.0의 속도차이는 http://www.androidauthority.com/samsung-memory-comparison-…/ 를 참고)

Q: 5X와 6P는 HDMI출력이 지원되나요?
A: 아뇨. 외부출력을 쓰려면 어제 새로 나온 ChromeCast를 사용하세요 :P
Wait while more posts are being loaded