Please enable JavaScript.

Coggle requires JavaScript to display documents.

Arbormoon Project (To build an Android-compatible mobile device, follow…

- - - - Media Codecs (section 5.1)
        
        MUST support the core media formats specified in the Android SDK documentation, except where explicitly permitted in this document.
        
        MUST support the media formats, encoders, decoders, file types, and container formats defined in the tables below and reported via MediaCodecList .
        
        MUST also be able to decode all profiles reported in its CamcorderProfile
        
        MUST be able to decode all formats it can encode. This includes all bitstreams that its
        encoders generate.
      - Raw Audio Capture (section 5.4.1)
        
        Device implementations that declare android.hardware.microphone MUST allow capture of raw audio content with the following characteristics:
        
        Format : Linear PCM, 16-bit
        Sampling rates : 8000, 11025, 16000, 44100 Channels : Mono
    - - Cameras section (7.5)
        
        If a device implementation includes at least one camera, it MUST be possible for an application to simultaneously allocate 3 RGBA_8888 bitmaps equal to the size of the images produced by the largest-resolution camera sensor on the device, while camera is open for the purpose of basic preview and still capture.
        
        Rear_Facing Camera (section 7.5.1)
        
        MUST have a resolution of at least 2 megapixels.
        
        SHOULD have either hardware auto-focus or software auto-focus implemented in the camera driver (transparent to application software).
        
        MUST report the feature flag android.hardware.camera and android.hardware.camera.any.
        
        MAY have fixed-focus or EDOF (extended depth of field) hardware.
        
        MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device’s built-in system camera application, but only to third-party applications using Camera.PreviewCallback.
        
        Front -Facing Camera section 7.5.2
        
        Device implementations MAY include a front-facing camera. If a device implementation includes at least one front-facing camera, it:
        
        MUST have a resolution of at least VGA (640x480 pixels).
        
        MUST NOT use a front-facing camera as the default for the Camera API. The camera API in Android has specific support for front-facing cameras and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the device.
        
        MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front.
        
        MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in section 7.5.1 .
        
        MUST horizontally reflect (i.e. mirror) the stream displayed by an app in a CameraPreview, as follows:
      - Display and Graphics (section 7.1)
        
        Screen Size
        
        MUST have screen size of at least 426dp x 320dp for 'small'
        
        Devices that report screen size 'normal' must have screen size of at least 480dp x 320dp
        
        Devices that report screen size 'large' must have screen size of at least 640dp x 480dp
        
        Devices that report screen size 'xlarge' must have screen size of at least 960dp x 720dp
        
        MUST report which screen orientations they support and MUST report at least one supported orientation
        
        2D and 3D graphics Acceleration
        
        MUST support OpenGL ES 1.0 and 2.0
        
        MUST support Android Renderscript
        
        MUST enable hardware acceleration by default
        
        MUST exhibit behavior constent with the Android SDK documentation
        
        MUST support the TextureView API and MUST exhibit consistent behavior with the upstream Android implemetation
        
        MUST support EGL_ANDROID_RECORDABLE extention
        
        Legacy Application Compatibility Mode
        
        MUST include support for legacy application compatibility mode as implemented by the upstream Android source code.
        
        MUST NOT alter the behavior of the compatibilty mode itself
        
        MUST NOT alter the triggers or thresholds at which compabiotlity mode us activated
      - Screen Technology
        
        MUST support displays capable of rendering 16-bit color graphics and SHOULD support displays capable if 24-bit color graphics
        
        MUST support displays capable of rendering animations
        
        MUST have a pixel aspect ratio near square(1.0) with a 10 ~ 15% tolerance.
        
        Secondary Displays
        
        MUST implement the display manager API as descibed int he Android SDK documentation
      - Input Devices
        
        Touchscreen Input
        
        MUST report the value of android.content.res.Configuration.touchscreen corresponding to the type of the specific touchscreen on the device.
        
        Accelerometer
      - Data Connectivity (section 7.4)
        
        Telephony (section 7.4.1)
        
        Number Blocking Compatibility (section 7.4.1)
        
        MUST block all calls and messages from a phone number in 'BlockedNumberProvider' without an interacting with apps
        
        MUST NOT write to the platform call log provider for a blocked call
        
        MUST fully implement Blocked NumberContract and corresponding API
        
        MUST NOT write to the Telephony provider for a blocked message
        
        MUST implement a blocked number management UI
        
        MUST NOT allow secondary users to view or edit the blocked numbers on the device.All blocking related UI must be hidden for secondary users and blocked list MUST still be respected
        
        (Wifi) IEE 802.11 7.4.2
        
        SHOULD include support for one or more forms of 802.11.If used and exposes the functionality to a third-party application it must implement the corresponding Android API and:
        
        MUST report the hardware feature flag android.hardware.wifi
        
        MUST implement the multicast API
        
        MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (22.0.0.251) at anytime of operation
        
        Wifi Direct 7.4.2.1
        
        MUST report the hardware feature android.hardware.wifi.direct
        
        MUST support regular Wi-Fi operation
        
        Bluetooth (section 7.4.3)
        
        If Bluetooth and Bluetooth Low Energy is supported MUST declare the relevant platform feature and implement the APIs
        
        If including support for Bluetooth Low Energy
        
        MUST declare the hardware feature android.hardware.bluetooth_le
        
        MUST enable the GATT )generic attribute profile) based Bluetooth APIs as described in the SDK documentation and android.bluetooth
        
        Near-Field Communications (section 7.4.4)
        
        Minimum Network Capability (section 7.4.5)
        
        MUST include at least one data standard capable of 200kbut/sec or greater. ex. EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, etc
        
        MUST include an IPv6 networking stack and support IPv6 communication using the managed APIs, java.net.Socket, and java.net.URLConnection as well as AF_INET6 sockets. The required level of IPv6 support depends om the network type as follows
        
        MUST support dual-stack and IPv6-only operation on Wi-Fi
        
        Devices that support cellular data SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on cellular data
        
        When a device is simultaneously connected to more than one network (e.g., WiFi and cellular data) it MUST simultaneously meet the requirement on each network to which it is connected
        
        IPv6 MUST be enabled by default
        
        unicast IPv6 packets sent to the device MUST NO T be dropped even when in the screen is not in an active state
        
        rate-limiting MUST NOT cause the device to lose IPv6 connectivity on any IPv6-compliant network that uses RA lifetimes of at least 180 seconds
        
        IPv6 connectivity MUST be maintained in doze mode.
        
        Sync Settings (section 7.4.6)
        
        Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns “true”.
        
        Data Saver (section 7.4.7)
        
        Device implementations with a metered connection are STRONGLY RECOMMENDED to provide the data saver mode.
        
        IF providing the data saver mode
        
        MUST support all the APIs in the ConnectivityManager class as described in the SDK
        documentation
        
        MUST provide a user interface in the settings, allowing users to add applications to or remove applications from the whitelist.
        
        If NOT providing the data saver mode
        
        MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for
        ConnectivityManager.getRestrictBackgroundStatus()
        
        MUST have an activity that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent but MAY implement it as a no-op.
        
        MUST not broadcast
        ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
      - Memory and Storage (section 7.6.1)
        
        Minimum Memory and Storage (section 7.6.1)
        
        The minimum memory values MUST be in addition to any memory space already dedicated to hardware components such as radio, video, and so on that is not under the kernel’s control.
        
        MUST return the value "true" for ActivityManager.isLowRamDevice().
        
        The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default “cache” location.
        
        Application Shared Storage (section 7.6.2)
        
        Device implementations MUST offer shared storage for applications also often referred as “shared external storage”.
        
        Device implementations MUST be configured with shared storage mounted by default, “out of the box”. If the shared storage is not mounted on the Linuxpath /sdcard, then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.
        
        Regardless of the form of shared storage used, if the device implementation has a USB port with USB peripheral mode support, it MUST provide some mechanism to access the contents of shared storage from a host computer. Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement. If the device implementation supports Media Transfer Protocol, it:
        
        SHOULD be compatible with the reference Android MTP host, Android File Transfer .
        
        SHOULD report a USB device class of 0x00.
        
        SHOULD report a USB interface name of 'MTP'.
        
        Adoptable Storage (section 7.6.3)
        
        Device implementations are STRONGLY RECOMMENDED to implement adoptable storage if the removable storage device port is in a long-term stable location, such as within the battery compartment or other protective cover.
        
        USB
        
        Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode.
        
        USB peripheral Mode (section 7.7.1)
        
        If a device implementation includes a USB port supporting peripheral mode:
        
        The port MUST be connectable to a USB host that has a standard type-A or type-C USB port.
        
        The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
        
        The port SHOULD be located on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen) so that the display draws correctly when the device is oriented with the port at the bottom. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
        
        It MUST allow a USB host connected with the Android device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol.
        
        It SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation, and if it is an Android Handheld device it MUST implement the AOA API. Device implementations implementing the AOA specification:
        
        MUST implement the USB audio class as documented in the Android SDK documentation.
        
        The USB mass storage class MUST include the string "android" at the end of the interface description iInterface string of the USB mass storage
        
        MUST declare support for the hardware feature android.hardware.usb.accessory .
        
        It SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging specification, revision 1.2 . Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
        
        Type-C devices MUST detect 1.5A and 3.0A chargers per the Type-C resistor standard and it must detect changes in the advertisement.
        
        Type-C devices also supporting USB host mode are STRONGLY RECOMMENDED to support Power Delivery for data and power role swapping.
        
        Type-C devices SHOULD support Power Delivery for high-voltage charging and support for Alternate Modes such as display out
        
        The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.
        
        Type-C devices are STRONGLY RECOMMENDED to not support proprietary charging methods that modify Vbus voltage beyond default levels, or alter sink/source roles as such may result in interoperability issues with the chargers or devices that support the standard USB Power Delivery methods. While this is called out as "STRONGLY RECOMMENDED", in future Android versions we might REQUIRE all type-C devices to support full interoperability with standard type-C chargers.
      - Audio (section 7.8)
        
        Microphone (section 7.8.1)
        
        MUST report the android.hardware.microphone feature constant.
        
        MUST meet the audio recording requirements in section 5.4 .
        
        MUST meet the audio latency requirements in section 5.6 .
        
        STRONGLY RECOMMENDED to support near-ultrasound recording as described in section 7.8.3 .
        
        Device implementations including a speaker or with an audio/multimedia output port for an audio output peripheral as a headset or an external speaker:
        
        MUST report the android.hardware.audio.output feature constant.
        
        MUST meet the audio playback requirements in section 5.5 .
        
        MUST meet the audio latency requirements in section 5.6 .
        
        STRONGLY RECOMMENDED to support near-ultrasound playback as described in section 7.8.3 .
        
        Analog Audio Ports
        
        In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug
        
        at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:
        
        MUST support audio playback to stereo headphones and stereo headsets with a microphone, and SHOULD support audio recording from stereo headsets with a microphone.
        
        MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support audio plugs with the OMTP pin-out order.
        
        MUST support the detection of microphone on the plugged in audio accessory, if the device implementation supports a microphone, and broadcast the android.intent.action.HEADSET_PLUG with the extra value microphone set as 1.
        
        MUST support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
        70 ohm or less : KEYCODE_HEADSETHOOK 210-290 Ohm : KEYCODE_VOLUME_UP 360-680 Ohm : KEYCODE_VOLUME_DOWN
        
        STRONGLY RECOMMENDED to detect and map to the keycode for the following range of equivalent impedance between the microphone and ground conductors on the audio plug:
        110-180 Ohm: KEYCODE_VOICE_ASSIST
        
        MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack.
        
        MUST be capable of driving at least 150mV ± 10% of output voltage on a 32 Ohm speaker impedance.
        
        MUST have a microphone bias voltage between 1.8V ~ 2.9V.
        
        Near-Ultrasound (section 7.8.3)
        
        Near-Ultrasound audio is the 18.5 kHz to 20 kHz band. Device implementations MUST correctly report the support of near-ultrasound audio capability via the AudioManager.getProperty API as follows:
        
        If PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND is "true", then the following requirements must be met by the VOICE_RECOGNITION and UNPROCESSED audio sources:
        
        The microphone's mean power response in the 18.5 kHz to 20 kHz band MUST be no more than 15 dB below the response at 2 kHz.
        
        The microphone's unweighted signal to noise ratio over 18.5 kHz to 20 kHz for a 19 kHz tone at -26 dBFS MUST be no lower than 50 dB.
        
        If PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND is "true", then the speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower than 40 dB below the response at 2 kHz
      - Min
        
        The main hardware platform for Android is the ARM architecture (ARMv7 and ARMv8-A architectures; formerly also ARMv5), with x86[c] and MIPS[d] architectures also officially supported in later versions of Android.(ARM, ARM 64 or x86 )
        
        List of Smart Phone and Tablet Mobile Processors
        
        MediaTek produce less heat than Qualcomm and other processors. MediaTek processors are cheaper and so is the best option for budget devices with good performance.
        
        MediaTek
        
        SoCs#ARMv8 Quad Core
    - - User Experience Consistency (section 8.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.
        
        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.
        
        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.1)
        
        Sequential write . Device implementations MUST ensure a sequential write performance of at least 5MB/s for a 256MB file using 10MB write buffer.
        
        Random write . Device implementations MUST ensure a random write performance of at least 0.5MB/s for a 256MB file using 4KB write buffer.
        
        Sequential read . Device implementations MUST ensure a sequential read performance of at least 15MB/s for a 256MB file using 10MB write buffer.
        
        Random read . Device implementations MUST ensure a random read performance of at least 3.5MB/s for a 256MB file using 4KB write buffer.
      - Power-Saving Modes(section 8.3)
        
        Apps exempted from App Standby and Doze MUST be made visible to the end user
      - Power Consumption Accounting (section 8.4)
        
        MUST be able to track hardware component power usage and attribute that power usage to specific applications. Specifically, implementation
        
        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.
        
        MUST report all power consumption values in milliampere hours (mAh).
        
        SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
        
        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.
        
        MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.
        
        MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display a settings menu that shows this power usage.
      - Consistent Performance (section 8.5)
        
        Device implementations SHOULD support Sustained Performance Mode which can provide the top foreground application a consistent level of performance for a prolonged amount of time when requested through the Window.setSustainedPerformanceMode() API method. A Device implementation MUST report the support of Sustained Performance Mode accurately through the PowerManager.isSustainedPerformanceModeSupported() API method.
        
        Device implementations with two or more CPU cores SHOULD provide at least one exclusive core that can be reserved by the top foreground application. If provided, implementations MUST meet the following requirements:
        
        Implementations MUST report through the Process.getExclusiveCores() API method the id numbers of the exclusive cores that can be reserved by the top foreground application.
        
        Device implementations MUST not allow any user space processes except the device
        drivers used by the application to run on the exclusive cores, but MAY allow some kernel processes to run as necessary.
        
        If a device implementation does not support an exclusive core, it MUST return an empty list through the Process.getExclusiveCores() API method.
    - - Phone
        
        must
        
        Touchscreen
        
        Microphone
        
        may
        
        Should
        
        Accelerometer
        
        GPS
        
        Wi-Fi
        
        Wi-Fi Direct
        
        Bluetooth
        
        Bluetooth Low Energy
        
        USB peripheral/host mode
        
        Speaker and/or Audio output ports
- - - - The entire build time is dependent on your hardware configuration. Even on a high-end CORE i7 Intel processor, it may take about 40 minutes. The option -j4 starts the parallel build using four processor cores. You can choose the number according to your computer hardware.