SmartSDK

Hello,

This new kit has a bug fix which was resolved for a customer "Office of the Attorney General " and hence require maintenance signature.

Bug Fix:  Modify display name for Original Sides Options in Scan Settings dialog. So, fixed it. 

New Version: 1.9 (prior version is 1.8)

I generated unsigned kit which can be downloaded from the following link: 

https://fileservices.uplandsoftware.com/public/file/LCdp2uPNZEu_EJ-P5uzZYg/OmtoolPanelApp-v1.9.zip

 I also ran ssdkpkg_checker.exe against the zip and verified for no errors. Please let me know if you need more information.

Regards

Niranjini

Hello,

We would like to ask for a maintenance signature for Smartshare Android embedded solution.

• stability improvements and error handling

King regards

Anderson 

Just wanted to check if there are regional validation limitations? We're presuming that our app, once validated can be installed on any device worldwide?

Thanks.

test stuff

stuff and things

Hello,

We would like to ask for a maintenance signature for Smartshare Android embedded solution.

• stability improvements and bug fixes

King regards

Anderson 

Hello,

We would like to ask for a maintenance signature for Smartshare Android embedded solution.

• stability improvements and bug fixes

King regards

Anderson 

Hi RIDP,

We had some discussions about enabling card swipes from sleep (swipe to wakeup and login). We have implemented this as mentioned in this Ricoh ticket https://ricoh-ridp.com/ridp/support-system/incident/ricoh-americas-corp-technology-center/1515115084/1268767928/2400 that suggests to keep the PANEL_STATE set to 2(sleep)

“Please use Lock Panel Display State API (@see the attached file). Application can reject panel power mode to going to Sleep mode by using this function. This MFP behavior from lock panel display state(sleep) until unlock panel display state is same as "Screen Device always connection" mode.”

We also go the following instruction from you

https://ricoh-ridp.com/ridp/faqs/should-i-turn-screen-device-always-connection-setting-support-usb-swipe-and-wake-device:  This RIDP article suggests that we implement a lock for the display state from our application.  It seems to accomplish the same thing, to prevent the panel from going into the SLEEP state, but either way, it is better because we could implement this without a Ricoh tech visit.

I cannot access the above link with my RIDP account, Can you fix that?

Can you also see below and confirm that we are doing the correct thing to achieve "swipe from sleep" ?

1. If the card reader is attached, send the intent  "jp. co. ricoh. isdk. sdkservice. panel. LOCK_PANEL_STATE" with PANEL_STATE = 2
2. Keep it locked during the operation as long as the card reader is attached.
3. Unlock it once the reader is detached
4. Always check on reboot if a reader is attached, if yes, lock the panel state as above

We found that this approach works in general. But we want to check with you if anything else is to be done.

Thanks.

Dear Ricoh Support Team,

We are experiencing a critical issue with the PullPrint function in our Ricoh SOP application. The printing function suddenly stopped working for all PullPrint jobs. Below is a detailed report of the behavior and findings:

Issue Summary

• PullPrint jobs are not being printed.

• The job transitions directly from STATE_JOB_PENDING to STATE_JOB_COMPLETED without entering the STATE_JOB_PROCESSING state.

• No output is observed from the printer, despite a successful job lifecycle from the API/log perspective.

Device Behavior Observed

• Scanning and copying operations work correctly.

• Printing from the Ricoh built-in Print App (non-PullPrint) works as expected.

• Only PullPrint jobs are affected.

Log Evidence

less

CopyEdit

08-06 15:31:41.444 I/UPConnector: service:PrintStMcn:#evtp :CHANGE_JOB_STATE_COMPLETED state:STATE_JOB_PENDING > STATE_JOB_COMPLETED

Documentation Insight

As per the Ricoh Developer Guide:

"Pending → Completed" transition may occur if the "pull (obtain file)" operation is not completed normally.

Additional Notes

• The files being printed are previously tested and have worked multiple times — URL and file validity is not in question.

• The issue began suddenly, without any updates or configuration changes on our side.

• We're not using any custom authentication.

• Multiple different PullPrint jobs (files) have been tested — all show the same issue.

Request for Support

We kindly request your help to:

1. Identify what could cause this behavior in PullPrint.

2. Provide any logs or diagnostic steps we should collect to assist further.

3. Confirm if this is a known issue or firmware-level behavior change.

Please advise on the next steps at your earliest convenience.

Hi,

Please find attached version 3.2.11 of the PaperCut MF application for a maintenance signature.

The changes are described as follows:

• Fixed an issue where it caused application to crash when using advanced scan

Thanks