Feature Request: Android Project Treble SDK

[User 7886]

Android Project Treble simplifies building custom Android ROMs.

Providing an Android Project Treble Software Development Kit (Original vendor implementation) will make the ROCK64 much more attractive on the market!

[dkryder]

Android Project Treble simplifies building custom Android ROMs.

Providing an Android Project Treble Software Development Kit (Original vendor implementation) will make the ROCK64 much more attractive on the market!

kinda curious about the crystal ball for the android market that you seem to have. first thing is the treble project is only for android 8 and above. next thing is android 8 requires a specific set of hardware in order for a device to be able to run it. there is a whole set, perhaps the majority of the current devices, that are not open to get the oreo update and so treble project don't mean jack for those devices.. does your crystal ball show that rock64 can run android 8? read this and then check back in,
https://source.android.com/compatibility...id-8.0-cdd

[eousphoros]

Android Project Treble simplifies building custom Android ROMs.

Providing an Android Project Treble Software Development Kit (Original vendor implementation) will make the ROCK64 much more attractive on the market!

kinda curious about the crystal ball for the android market that you seem to have. first thing is the treble project is only for android 8 and above. next thing is android 8 requires a specific set of hardware in order for a device to be able to run it. there is a whole set, perhaps the majority of the current devices, that are not open to get the oreo update and so treble project don't mean jack for those devices.. does your crystal ball show that rock64 can run android 8? read this and then check back in,
https://source.android.com/compatibility...id-8.0-cdd

"Specific set of hardware" "majority of current devices" "random document that is only sort of related" 

So negative. May I suggest some vitamin D? Also can the rock64 run android 8 in the future? Sure, this comes from someone who has ported android to a myriad of various devices that weren't "supported". Will it be alot of work? Yes. 

I mean even android 7.1.2 isn't fully running on the rock64 today. That doesn't mean that with effort from the community we can't get there.

[dkryder]

Android Project Treble simplifies building custom Android ROMs.

Providing an Android Project Treble Software Development Kit (Original vendor implementation) will make the ROCK64 much more attractive on the market!

kinda curious about the crystal ball for the android market that you seem to have. first thing is the treble project is only for android 8 and above. next thing is android 8 requires a specific set of hardware in order for a device to be able to run it. there is a whole set, perhaps the majority of the current devices, that are not open to get the oreo update and so treble project don't mean jack for those devices.. does your crystal ball show that rock64 can run android 8? read this and then check back in,
https://source.android.com/compatibility...id-8.0-cdd

"Specific set of hardware" "majority of current devices" "random document that is only sort of related" 

So negative. May I suggest some vitamin D? Also can the rock64 run android 8 in the future? Sure, this comes from someone who has ported android to a myriad of various devices that weren't "supported". Will it be alot of work? Yes. 

I mean even android 7.1.2 isn't fully running on the rock64 today. That doesn't mean that with effort from the community we can't get there.

not negative, just realistic. it's obvious you did not read the linked document so your comprehension is affected no doubt. but hey, let's just wait and see. oh, one last thing, the main thrust of the post was the treble project, well the treble project is based on the full build so probably little chance it relates to the rock64.

see, here is just a sample of the requirements, maybe someone can read it to you, i fully expect you to mention the rock64 is not a handheld device, perhaps, but the majority of android devices are handheld thus the requirement for the full build. if you take the not handheld track just skip down to the tv box set of requirements. now, show everyone how smart you are by quoting the whole post,
Accelerometer (Section 7.3.1)

Handheld device implementations:

[H-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
If Handheld device implementations include a 3-axis accelerometer, they:

[H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
Gyroscope (Section 7.3.4)

If Handheld device implementations include a gyroscope, they:

[H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
Proximity Sensor (Section 7.3.8 )

Handheld device implementations that can make a voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType:

SHOULD include a proximity sensor.
Pose Sensor (Section 7.3.12)

Handheld device implementations:

Are RECOMMENDED to support pose sensor with 6 degrees of freedom.
Bluetooth (Section 7.4.3)

Handheld device implementations:

SHOULD include support for Bluetooth and Bluetooth LE.
Data Saver (Section 7.4.7)

If Handheld device implementations include a metered connection, they:

[H-1-1] MUST provide the data saver mode.
Minimum Memory and Storage (Section 7.6.1)

Handheld device implementations:

[H-0-1] MUST have at least 4GB of non-volatile storage available for application private data (a.k.a. "/data" partition)
[H-0-2] MUST return “true” for ActivityManager.isLowRamDevice() when there is less than 1GB of memory available to the kernel and userspace.
If Handheld device implementations are 32-bit:

[H-1-1] The memory available to the kernel and userspace MUST be at least 512MB if any of the following densities are used:

280dpi or lower on small/normal screens*
ldpi or lower on extra large screens
mdpi or lower on large screens
[H-2-1] The memory available to the kernel and userspace MUST be at least 608MB if any of the following densities are used:

xhdpi or higher on small/normal screens*
hdpi or higher on large screens
mdpi or higher on extra large screens
[H-3-1] The memory available to the kernel and userspace MUST be at least 896MB if any of the following densities are used:

400dpi or higher on small/normal screens*
xhdpi or higher on large screens
tvdpi or higher on extra large screens
[H-4-1] The memory available to the kernel and userspace MUST be at least 1344MB if any of the following densities are used:

560dpi or higher on small/normal screens*
400dpi or higher on large screens
xhdpi or higher on extra large screens
If Handheld device implementations are 64-bit:

[H-5-1] The memory available to the kernel and userspace MUST be at least 816MB if any of the following densities are used:

280dpi or lower on small/normal screens*
ldpi or lower on extra large screens
mdpi or lower on large screens
[H-6-1] The memory available to the kernel and userspace MUST be at least 944MB if any of the following densities are used:

xhdpi or higher on small/normal screens*
hdpi or higher on large screens
mdpi or higher on extra large screens
[H-7-1] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used:

400dpi or higher on small/normal screens*
xhdpi or higher on large screens
tvdpi or higher on extra large screens
[H-8-1] The memory available to the kernel and userspace MUST be at least 1824MB if any of the following densities are used:

560dpi or higher on small/normal screens*
400dpi or higher on large screens
xhdpi or higher on extra large screens
Note that the "memory available to the kernel and userspace" above refers to the memory space provided in addition to any memory already dedicated to hardware components such as radio, video, and so on that are not under the kernel’s control on device implementations.

Application Shared Storage (Section 7.6.2)

Handheld device implementations:

[H-0-1] MUST NOT provide an application shared storage smaller than 1 GiB.
USB peripheral mode (Section 7.7.1)

Handheld device implementations:

SHOULD include a USB port supporting peripheral mode.
If handheld device implementations include a USB port supporting peripheral mode, they:

[H-1-1] MUST implement the Android Open Accessory (AOA) API.*
Microphone (Section 7.8.1)

Handheld device implementations:

[H-0-1] MUST include a microphone.
Audio Output (Section 7.8.2)

Handheld device implementations:

[H-0-1] MUST have an audio output and declare android.hardware.audio.output.
Virtual Reality Mode (Section 7.9.1)

If Handheld device implementations include support for the VR mode, they:

[H-1-1] MUST declare the android.software.vr.mode feature.*
If device implementations declare android.software.vr.mode feature, they:

[H-2-1] MUST include an application implementing android.service.vr.VrListenerService that can be enabled by VR applications via android.app.Activity#setVrModeEnabled.*
Virtual Reality High Performance (Section 7.9.2)

If Handheld device implementations are capable of meeting all the requirements to declare the android.hardware.vr.high_performance feature flag, they:

[H-1-1] MUST declare the android.hardware.vr.high_performance feature flag.*
2.2.2. Multimedia
Audio Encoding (Section 5.1.1)

Handheld device implementations MUST support the following audio encoding:

[H-0-1] AMR-NB
[H-0-2] AMR-WB
[H-0-3] MPEG-4 AAC Profile (AAC LC)
[H-0-4] MPEG-4 HE AAC Profile (AAC+)
[H-0-5] AAC ELD (enhanced low delay AAC)
Audio Decoding (Section 5.1.2)

Handheld device implementations MUST support the following audio decoding:

[H-0-1] AMR-NB
[H-0-2] AMR-WB
Video Encoding (Section 5.2)

Handheld device implementations MUST support the following video encoding and make it available to third-party applications:

[H-0-1] H.264 AVC
[H-0-2] VP8
Video Decoding (Section 5.3)

Handheld device implementations MUST support the following video decoding:

[H-0-1] H.264 AVC.
[H-0-2] H.265 HEVC.
[H-0-3] MPEG-4 SP.
[H-0-4] VP8.
[H-0-5] VP9.
2.2.3. Software
WebView Compatibility (Section 3.4.1)

Handheld device implementations:

[H-0-1] MUST provide a complete implementation of the android.webkit.Webview API.
Browser Compatibility (Section 3.4.2)

Handheld device implementations:

[H-0-1] MUST include a standalone Browser application for general user web browsing.
Launcher (Section 3.8.1)

Handheld device implementations:

[H-SR] Are STRONGLY RECOMMENDED to implement a default launcher that supports in-app pinning of shortcuts and widgets.

[H-SR] Are STRONGLY RECOMMENDED to implement a default launcher that provides quick access to the additional shortcuts provided by third-party apps through the ShortcutManager API.

[H-SR] Are STRONGLY RECOMMENDED to include a default launcher app that shows badges for the app icons.

Widgets (Section 3.8.2)

Handheld device implementations:

[H-SR] Are STRONGLY RECOMMENDED to support third-party app widgets.
Notifications (Section 3.8.3)

Handheld device implementations:

[H-0-1] MUST allow third-party apps to notify users of notable events through the Notification and NotificationManager API classes.
[H-0-2] MUST support rich notifications.
[H-0-3] MUST support heads-up notifications.
[H-0-4] MUST include a notification shade, providing the user the ability to directly control (e.g. reply, snooze, dismiss, block) the notifications through user affordance such as action buttons or the control panel as implemented in the AOSP.
Search (Section 3.8.4)

Handheld device implementations:

[H-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.
Lock Screen Media Control (Section 3.8.10)

If Android Handheld device implementations support a lock screen,they:

[H-1-1] MUST display the Lock screen Notifications including the Media Notification Template.
Device administration (Section 3.9)

If Handheld device implementations support a secure lock screen, they:

[H-1-1] MUST implement the full range of device administration policies defined in the Android SDK documentation.
Accessibility (Section 3.10)

Handheld device implementations:

[H-SR] MUST support third-party accessibility services.

[H-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the device comparable with or exceeding functionality of the Switch Access and TalkBack (for languages supported by the preloaded Text-to-speech engine) accessibility services as provided in the talkback open source project.

Text-to-Speech (Section 3.11)

Handheld device implementations:

[H-0-1] MUST support installation of third-party TTS engines.

[H-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.

Quick Settings (Section 3.13)

Handheld device implementations:

[H-SR] Are STRONGLY RECOMMENDED to include a Quick Settings UI component.
Companion Device Pairing (Section 3.15)

If Android handheld device implementations declare FEATURE_BLUETOOTH or FEATURE_WIFI support, they:

[H-1-1] MUST support the companion device pairing feature.
2.2.4. Performance and Power
User Experience Consistency (Section 8.1)

For handheld device implementations:

[H-0-1] Consistent frame latency. Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
[H-0-2] User interface latency. Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.
[H-0-3] Task switching. When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.
File I/O Access Performance (Section 8.2)

Handheld device implementations:

[H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.
[H-0-2] MUST ensure a random write performance of at least 0.5 MB/s.
[H-0-3] MUST ensure a sequential read performance of at least 15 MB/s.
[H-0-4] MUST ensure a random read performance of at least 3.5 MB/s.
Power-Saving Modes (Section 8.3)

For handheld device implementations:

[H-0-1] All Apps exempted from App Standby and Doze power-saving modes MUST be made visible to the end user.
[H-0-2] The triggering, maintenance, wakeup algorithms and the use of global system settings of App Standby and Doze power-saving modes MUST not deviate from the Android Open Source Project.
Power Consumption Accounting (Sections 8.4)

Handheld device implementations:

[H-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.
[H-0-2] MUST report all power consumption values in milliampere hours (mAh).
[H-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.
[H-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.
SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
If Handheld device implementations include a screen or video output, they:

[H-1-1] MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display a settings menu that shows this power usage.
2.2.5. Security Model
Permissions (Sections 9.1)

Handheld device implementations:

[H-0-1] MUST allow third-party apps to access the usage statistics via the android.permission.PACKAGE_USAGE_STATS permission and provide a user-accessible mechanism to grant or revoke access to such apps in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent.
2.3. Television Requirements
An Android Television device refers to an Android device implementation that is an entertainment interface for consuming digital media, movies, games, apps, and/or live TV for users sitting about ten feet away (a “lean back” or “10-foot user interface”).

Android device implementations are classified as a Television if they meet all the following criteria:

Have provided a mechanism to remotely control the rendered user interface on the display that might sit ten feet away from the user.
Have an embedded screen display with the diagonal length larger than 24 inches OR include a video output port, such as VGA, HDMI, DisplayPort or a wireless port for display.
The additional requirements in the rest of this section are specific to Android Television device implementations.

2.3.1. Hardware
Non-touch Navigation (Section 7.2.2)

Television device implementations:

[T-0-1] MUST support D-pad.
Navigation Keys (Section 7.2.3)

Television device implementations:

[T-0-1] MUST provide the Home and Back functions.
[T-0-2] MUST send both the normal and long press event of the Back function (KEYCODE_BACK) to the foreground application.
Button Mappings (Section 7.2.6.1)

Television device implementations:

[T-0-1] MUST include support for game controllers and declare the android.hardware.gamepad feature flag.
Remote Control (Section 7.2.7)

Television device implementations:

SHOULD provide a remote control from which users can access non-touch navigation and core navigation keys inputs.
Gyroscope (Section 7.3.4)

If Television device implementations include a gyroscope, they:

[T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
Bluetooth (Section 7.4.3)

Television device implementations:

[T-0-1] MUST support Bluetooth and Bluetooth LE.
Minimum Memory and Storage (Section 7.6.1)

Television device implementations:

[T-0-1] MUST have at least 4GB of non-volatile storage available for application private data (a.k.a. "/data" partition)
Microphone (Section 7.8.1)

Television device implementations:

SHOULD include a microphone.
Audio Output (Section 7.8.2)

Television device implementations:

[T-0-1] MUST have an audio output and declare android.hardware.audio.output.
2.3.2. Multimedia
Audio Encoding (Section 5.1)

Television device implementations MUST support the following audio encoding:

[T-0-1] MPEG-4 AAC Profile (AAC LC)
[T-0-2] MPEG-4 HE AAC Profile (AAC+)
[T-0-3] AAC ELD (enhanced low delay AAC)
Video Encoding (Section 5.2)

Television device implementations MUST support the following video encoding:

[T-0-1] H.264 AVC
[T-0-2] VP8
H-264 (Section 5.2.2)

Television device implementations are:

[T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p resolution videos.
[T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution video at 30 frame-per-second (fps).
Video Decoding (Section 5.3)

Television device implementations MUST support the following video decoding:

[T-0-1] H.264 AVC
[T-0-2] H.265 HEVC
[T-0-3] MPEG-4 SP
[T-0-4] VP8
[T-0-5] VP9
Television device implementations are STRONGLY RECOMMENDED to support the following video decoding:

[T-SR] MPEG-2
H.264 (Section 5.3.4)

If Television device implementations support H.264 decoders, they:

[T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps) decoding profile.
[T-1-2] MUST be capable of decoding videos with both HD profiles as indicated in the following table and encoded with either the Baseline Profile, Main Profile, or the High Profile Level 4.2
H.265 (HEVC) (Section 5.3.5)

If Television device implementations support H.265 codec and the HD 1080p decoding profile, they:

[T-1-1] MUST support the Main Profile Level 4.1 Main tier.
[T-SR] Are STRONGLY RECOMMENDED to support 60 fps video frame rate for HD 1080p.
If Television device implementations support H.265 codec and the UHD decoding profile, then:

[T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.
VP8 (Section 5.3.6)

If Television device implementations support VP8 codec, they:

[T-1-1] MUST support the HD 1080p60 decoding profile.
If Television device implementations support VP8 codec and support 720p, they:

[T-2-1] MUST support the HD 720p60 decoding profile.
VP9 (Section 5.3.7)

If Television device implementations support VP9 codec and the UHD video decoding, they:

[T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2 (10-bit).
If Television device implementations support VP9 codec, the 1080p profile and VP9 hardware decoding, they:

[T-2-1] MUST support 60 fps for 1080p.
Secure Media (Section 5.8)

If device implementations are Android Television devices and support 4K resolution, they:

[T-1-1] MUST support HDCP 2.2 for all wired external displays.
If Television device implementations don't support 4K resolution, they:

[T-2-1] MUST support HDCP 1.4 for all wired external displays.
Television device implementations:

[T-SR] Are STRONGLY RECOMMENDED to support simulataneous decoding of secure streams. At minimum, simultaneous decoding of two steams is STRONGLY RECOMMENDED.
Audio Output Volume (Section 5.5.3)

Television device implementations:

[T-0-1] MUST include support for system Master Volume and digital audio output volume attenuation on supported outputs, except for compressed audio passthrough output (where no audio decoding is done on the device).
2.3.3. Software
Television device implementations:

[T-0-1] MUST declare the features android.software.leanback and android.hardware.type.television.
WebView compatibility (Section 3.4.1)

Television device implementations:

[T-0-1] MUST provide a complete implementation of the android.webkit.Webview API.
Lock Screen Media Control (Section 3.8.10)

If Android Television device implementations support a lock screen,they:

[T-1-1] MUST display the Lock screen Notifications including the Media Notification Template.
Multi-windows (Section 3.8.14)

Television device implementations:

[T-SR] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode multi-window.
Accessibility (Section 3.10)

Television device implementations:

[T-SR] MUST support third-party accessibility services.

[T-SR] Android Television device implementations are STRONGLY RECOMMENDED to preload accessibility services on the device comparable with or exceeding functionality of the Switch Access and TalkBack (for languages supported by the preloaded Text-to-speech engine) accessibility services as provided in the talkback open source project.

Text-to-Speech (Section 3.11)

If device implementations report the feature android.hardware.audio.output, they:

[T-SR] STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.

[T-0-1] MUST support installation of third-party TTS engines.

TV Input Framework (Section 3.12)

Television device implementations:

[T-0-1] MUST support TV Input Framework.
2.3.4. Performance and Power
User Experience Consistency (Section 8.1)

For Television device implementations:

[T-0-1] Consistent frame latency. Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
File I/O Access Performance (Section 8.2)

Television device implementations:

[T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
[T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
[T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
[T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
Power-Saving Modes (Section 8.3)

For Television device implementations:

[T-0-1] All Apps exempted from App Standby and Doze power-saving modes MUST be made visible to the end user.
[T-0-2] The triggering, maintenance, wakeup algorithms and the use of global system settings of App Standby and Doze power-saving modes MUST not deviate from the Android Open Source Project.
Power Consumption Accounting (Sections 8.4)

Television device implementations:

[T-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.
[T-0-2] MUST report all power consumption values in milliampere hours (mAh).
[T-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.
SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
[T-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.

[Luke]

dkryder, please pastebin that ...

[eousphoros]

"Specific set of hardware" "majority of current devices" "random document that is only sort of related" 

So negative. May I suggest some vitamin D? Also can the rock64 run android 8 in the future? Sure, this comes from someone who has ported android to a myriad of various devices that weren't "supported". Will it be alot of work? Yes. 

I mean even android 7.1.2 isn't fully running on the rock64 today. That doesn't mean that with effort from the community we can't get there.

not negative, just realistic. it's obvious you did not read the linked document so your comprehension is affected no doubt. but hey, let's just wait and see. oh, one last thing, the main thrust of the post was the treble project, well the treble project is based on the full build so probably little chance it relates to the rock64.

see, here is just a sample of the requirements, maybe someone can read it to you,  i fully expect you to mention the rock64 is not a handheld device, perhaps, but the majority of android devices are handheld thus the requirement for the full build. if you take the not handheld track just skip down to the tv box set of requirements. now, show everyone how smart you are by quoting the whole post,

Damn son, I'm thinking something stronger maybe in order for that mood disorder. All I was trying to say was pointing out some doc and saying its impossible because of a capital "must" is silly and really not needed. 

It is truly magical what a line of code here and there can accomplish. You must believe that, else why would you be here hacking on this relatively new SBC.

That's all I will feed to the troll. Seriously though relax. You'll live longer.